[Ach] StartSSL for Business Sysadmins

[ianG]

Que tal, Tobias!


On 15/01/14 02:14 AM, Tobias Dussa (SCC) wrote:
> Ola,
> 
> On Tue, Jan 14, 2014 at 03:13:29PM +0300, ianG wrote:
>>>> I see we are dragging into a PKI discussion :)  There must be a law to
>>>> predict this...
>>> Is there an Ian's Law already? ;-)
>> Not till I'm dead ;-)
>> http://iang.org/ssl/hn_hypotheses_in_secure_protocol_design.html
> 
> The Simpsons managed to break the iron rule that nobody gets their own USPS
> stamp while still on the air...  There's always a first. -:))

Ha.  I hope to outlast the USPS, but not the Simpsons...


...
>> Warning:  7 parts, hours and hours to read:
>> http://financialcryptography.com/mt/archives/001126.html
>> The "doing it right" model only works if we get 100% compliance.
> 
> Yes, within a given domain.  Which is exactly why such a model has its use
> cases.

With caution, yes.


....
>> Well.  I would say that is a cryptographic focus, and too narrow to
>> encapsulate what is meant by trust.  If for example we assumed that
>> trust can be delivered with crypto keys, and that it was necessary for
>> each key to be chained, and etc etc, then we could work at that level.
>> Problem is, keys can't deliver trust.  Humans deliver trust, and if
>> you're talking about CAs and PKI, where's the human?
> 
> I don't follow, sorry.  In the end, the question is, who does the user believe
> to do The Right Thing[tm].  There's technical means to establish certain
> assertions, and people use those means.


Yes, this is the business proposition of the CA.  "We will do the right
thing, therefore you must trust us."

The problem with this is the 'must' part.  The browsers expose the users
to mandated chains of permission.  The sites must gain permission from
the CAs to use SSL, the CAs must gain permission from the browsers, and
the browsers rule over all (except they don't...).

Now compare this to the word trust.  Trust, at least in the English
language is a concept that goes from Alice the trusting party to Bob the
trusted party.  Alice trusts Bob.  Implicit in this concept is that
Alice chooses to trust Bob, she does so from her own information and she
can withdraw that trust any time.

So, trust looks like this:

      Alice --> Bob.

But the CA business looks like this:

      Alice ---> Browser <-- CA <-- site

And permission vectors look like this:

      Alice ===> Browser ===> CA ===> site

See the switch?  There is no trust in the CA business as far as the user
is concerned.  And Alice, at the bottom of her heart, knows this.  She
accepts the mandated permission concept, because she has no choice.  She
cannot actually do anything about it;  she gives permission to the
browser to carry on, her only choice is to stop using the browser.

(Yes, I am totally ignoring the ability to verify the chain herself,
read the CP/CPS, and modify the root list.  To say otherwise is sophistry.)

So, back to the above.  Keys can deliver permission.  That's possible,
and permission can be considered to be authorisation and authentication.

But trust?  No, never.  Keys cannot be vectors of trust.  Trust is
strictly in the domain of humans, not crypto.


> Comparing the situation to, say, a physical document.  Say every entity has a
> physical rubber stamp that cannot be forged.  Then in the gpg world, having that
> stamp on a document doesn't say much.  In the X.509 world, a stamp by itself
> doesn't mean much either, of course, but a given CA also has CP/CPS, which for
> example state that a stamp means some aspect or other of the document has been
> verified.  This may not be much, and I'd still have to trust the CA to stick to
> its CP/CPS, but it is better than nothing.


Right, but your mistake here is to conflate GPG's CP/CPS with the user's
practices.  The GPG world has no CP/CPS.  However, individuals have
their own practices which are not written down.  The reason that GPG
works and works well enough in certain circles is that everyone has a
view as to what the unwritten CP/CPS is, and that view is sufficiently
reliable as to permit the trade to continue.

Yes, it's making an assumption that is anathema to the x.509/pki/CA
world.  But that's their failing, to be caught by their own assumptions.


> Of course, this works reasonably
> only if the number of CAs is relatively small, but I personally generally have a
> certain degree of faith in a document that, say, bears a stamp of a German (or
> UK or French) notary officer.  Yes, it can be faked, which is why under certain
> circumstances it is not sufficient, and yes, some people are not able to tell
> the difference between a German and a French stamp, but even so, it still bears
> some meaning.


Exactly -- because you know what a German notary is, you can imply
certain things ("CP/CPS") into the notary stamp.  The same goes for GPG.
 When you meet a German, you can likely imply how they treat their
signing keys.

Or you can ask them, the WoT does allow that (again in contrast to
typical x.509/CA/PKI, where you can't typically ask anything... CAcert
excepted and perhaps the CAs you know).


>>> From a fundamentalistic point of view, yes, it is.  Note that the PGP trust
>>> model is much worse in that respect; there is nothing at all to help you decide
>>> on whether to bestow trust on a given signature at all.
>> Correct, and I'm happy someone's spotted it.  On the one hand we have
>> PGP's signature statement, which is non-existent, and on the other hand
>> we have the CA/PKI's signature statement which is worthless.
>> It's not really a battle about quality :)
> 
> Never said it was.  I also never said X.509 was the answer to everything.  I
> would just like to see sensible advise on its use included in our document,
> that's all.


Sure.  I sense your frustration.  All I can suggest is:  write it, and
subject it to the bar:  is it sensible, is it concise, and will it make
a difference.


>>>>> So in what world are GPG and SSH better concepts?
>>>> In the economic and effective world.  They provide security for quite
>>>> minimal cost.  SSH's realworld, measurable cost-effectiveness is very
>>>> high, and leaves SSL/certs looking like a joke.
>>> That's not quite the case IMHO.  SSL certificates don't have to come at a high
>>> cost (it certainly does not follow as a necessary consequence of the
>>> hierarchical PKI setup; see DFN-PKI),
>> SSL certificates do not have a high cost *as they leave the CA* but they
>> have a very high cost to the user -- the sysadm that has to deploy it.
> 
> O(1).  Please.  That's not a high cost.


Ivory tower?  I can't count the number of times sysadms have come to me
and told me their sob stories about getting certs going.  I can deploy
HTML websites by the dozen, myself, but when it comes to SSL, I hit
brick wall after brick wall.


> Besides, if you don't want any serious
> certification, then your Apache install script will happily generate a bogus SSL
> certificate for you.  For all practical purposes except one this is EXACTLY as
> SSH is usually deployed.  The one difference is that usually the user is told by
> her software that that certificate is self-rolled and of indefinite validity.
> This is exactly the same as with SSH, but for some reason, you seem to think
> that ACKing a new and unknown SSH host key is reasonable while adding a
> permanent exception to your web browser (which does essentially the same thing)
> is evil.


No, I think that is precisely what should be done.  Roll a new key,
install, go.  Tell the user to ack this key in the browser.  Every
website should be set up like this, bar none.

Then, later on, drop in a CA-signed key.  If that's valuable.

>> Of course, the CA ignores this cost entirely, as a marketing
>> requirement.  I would do the same, if I sold certs or used cars or houses.
> 
> Again, that is not true in general.


What is true is that there is a face cost -- paid for the cert.  Then
there is a business cost, incurred by the business.  This is true
because it is true of all trade between parties.

I am not sure that the ratio of face cost to business cost has ever been
scientifically measured.  That would make an interesting experiment.
I'd put it at about 1:5, but that's just a guess.  Someone should do a
study.


>> For the relying party, depending on who we're talking to, certs are
>> either free (browsers insist you use them, nothing to do, but you also
>> get little or nothing) or they are very expensive (granny has to consult
>> her lawyer about this CP/CPS/hidden contract, and what does she get for
>> her consultation fee?  She's told she is essentially on her own).
> 
> Again, and this is the last time I'll be repeating this, you get exactly the
> same as for SSH at the very least.


No.  Granny doesn't know the CA nor the site.  In SSH, the sysadm knows
the machine, or the user knows the sysadm.  Different domain, so the
approach works for SSH.

The business matters -- the business should drive the crypto, not the
other way around.


>> I don't know anything about DFN-PKI, quick look showed German site.  If
>> there were an english explanation of your point... but remember, this
>> argument isn't solved by showing one CA doing it right,
> 
> Not so.  I was offering a counter-example for a general statement.
> 
>> it's about how
>> to improve the lot for everyone.  How does ACH advise users to do better
>> PKI?
> 
> See my other mail.
> 
>>> and SSH deployment by itself does nothing
>>> to improve security in terms of preventing MITM attacks and such.
>> Of course, that's the beauty.  That's why it works.  It is security
>> aimed at the real security problem, not a product aimed at a problem
>> that is manufactured for the product.
> 
> Yes.  It addresses a large part of the problem.
> 
>>> How does SSL force verification any more than SSH?  That is usually one of the
>>> criticism points laid at the feet of SSL: Users are effectively trained to click
>>> away any browser complaints about problems with verification, which in
>>> particular means that obviously verification can be ignored, and that users tend
>>> to do that if in doubt.
>> The sysadm has to get verified by the CA.  That is a cost.
> 
> The last time I checked my installer script deployed a self-signed SSL
> certificate even without asking me.  That is NO cost.


Ah, well that is a significant improvement.  That is happy news.  Does
it create an SSL website for the standard HTTP website as yet?  Or are
we still in TLS/SNI waiting mode?


>> In the end, you are correct, the verification is wasted because of
>> click-thru syndrome.  But the cost is still there... and what was this
>> about reading the CP/CPS?  Is that a cost, or aren't we serious?
> 
> And again, if you are happy with the fuzzy feeling that your connection is
> (probably) encrypted


Which is what brought us here today:  NSA revelations of mass surveillance.

> and you are talking to somebody who is (probably) the one
> you think you are talking to --- which may be a very valid point of view,
> economically speaking ---, then there is no need to read the CP/CPS.  We need to
> compare apples with apples here; if we are aiming for encryption only, then
> things get much simpler on all ends.


Yes.  So what was SSL aiming at?  Well, that is also a topic of much
debate, more later.


>>>> In contrast, with SSL, the cost is imposed.  So it creates a drag on
>>>> economics.
>>> What cost is imposed?
>> The cost that the company/sysadm has to carry to get the SSL cert up and
>> going.  Which cost in comparison to SSH is .. zero?
> 
> And yet again, not true.
> 
>>>> And for what purpose?  Most of the benefit of crypto is
>>>> found without verification.
>>> Same goes for SSL.
>> Right.  So if you stripped out the verification from SSL, we'd all be
>> winners, right?
> 
> Nope.  You're the one who's claiming we don't need verification in real life.


It's not so black and white.  It's economic.  The question is whether we
can afford verification for all needs, or whether we can be more
flexible about it.


> All I'm saying is we should measure by the same standards.


Yes, you're imposing the business domainand therefore the standards,
which is unfair.

The thing is, SSL is a very different business domain to SSH.  Which is
why the latter works;  it works within its narrow business domain.

SSL is designed to allow granny to go to a site she's never heard of
with a browser configured by someone she doesn't know.  The whole
ecommerce thing.

This is one of the things that surprises me about the PKI people.  They
say that the SSH thing is evil, as is PGP.  What they should say is that
the environment isn't compatible, and SSL can handle ecommerce, whereas
SSH and PGP can't.  Apples and oranges.

(Of course, as soon as they admit that there are different plausible
models, they're in deep trouble... :)


>> Except, we'd be vulnerable to MITM.  Now, that's another story.  But if
>> you look at that objectively, it isn't an unhappy story.  It is only if
>> you assume it -- FUD -- that unhappiness ensues.
> 
> Well, yes, obviously.  If you choose to ignore a risk, then you don't need to
> think about a solution to that risk, and you are happier if you don't have that
> solution.  That's undisputed.


Indeed, and the reverse.  If you choose to cover a risk, and do so, then
you don't need to worry about it.  The problem with both sides to this
choice is that we have not integrated the cost into the choice.


>>> (Besides, I might add, the more hardcore guys will readily
>>> get in your face declaring that any crypto without authenticity verification is
>>> snake oil, and thus inherently worthless.)
>> Yes, it's called marketing, and FUD.  They are wrong, and they are
>> marking themselves as inherently worthless as security people.
> 
> I'd say it strongly depends on the circumstances (in particular, what threats
> you are facing).  Saying they're flat wrong is just about as naive as saying
> they're always right IMHO.

I'm saying that if they say it is *inherently worthless*, then they are
flat wrong.  Because inherently worthless is to ignore circumstances.

If they were to modify their dogmaticism to entertaining that it is
appropriate in some circumstances and not in others, then we'd be able
to have a conversation.

It is going to be curious how these banner-leaders cope with the NSA
revelations.  The use of unauthenticated/unverified encryption will
knock out the NSA's mass surveillance (by forcing them to use targetted
and expensive active attacks, which they won't do).

Is that worthless?  The PKI people are going to be facing a fair bit of
cognitive dissonance on this one, and their role in promoting only
authenticated verified crypto has a part to play in the NSA's success.


>> PKI is full of people who say that crypto without authenticity
>> verification is worthless.  I can't help that.
> 
> Interesting.  Most people I have met are using that as an argument AGAINST PKI
> saying that PKI cannot deliver 100% reliably.


It can't, true.  That's another argument against it.  But again, we have
to draw in economics to show why.  This is best seen with the European
digital signature project, which shows much wordage and little progress.
 Alice is not stupid, she recognises that putting that much power in
such a little smart card token is not in her best interests.


>> SSH correctly aligns with the real world threat -- attempts to hack into
>> machines via the credentials of the sysadm.  It kills this threat dead.
>> SSL does not, it aims at the MITM, of which there is practically no
>> evidence.
> 
> I beg your pardon?  SSL also enciphers connections the last time I checked.


The point being that the environment does not permit, and fights
against, encrypted but unauthenticated connections.

(But, curiously, the environment only promotes auth in one direction,
the other direction lies fallow.)


> And the last time I checked, SSH also went out of its way to get the user to
> check the host key.  People just apply the SSH equivalent of Click-Thru: Typing
> YES whenever they see a new SSH host key.  I honestly fail to see how one is
> better or worse than the other in that respect.


SSH can put up with click-thru syndrome because of its narrow domain.
It works, because the user is the sysadm or knows the sysadm, and can
ask when a click-thru is appropraite.

SSL however cannot;  it totally breaks the security model, and leaves it
wide open to the anticipated threat model -- MITM, aka phishing.

Yes, the technology is highly similar, and has converged to a large
extent.  But the business proposition is a world apart.


>> In order to defeat the MITM, it imposes the cost of certificates.  This
>> is very high.  So high in fact that SSL only reaches 1% of the market,
>> thus leaving 99% of the market unprotected (http being totally unprotected).
>> Now, do the maths:
>> SSL protection:   1%, high cost.
>> SSH protection:  100%, low cost.
> 
> This may not be an inherent SSL problem.


Right.  What it is, is a business problem.  The business problem of
credit cards was imposed on the crypto, and then switched across to
online banking (in short words).

The point being that SSH correctly delivered to its business problem, it
never lost sight of it.  SSL and secure browsing failed in that.


> I think there are a number of other
> factors as well that play a (I suspect) substantial role.  Consider these
> thoughts (in no particular order):
> 
>  + Practically nobody has an SSH server, while everybody and his brother has a
>    web server.  For technologically savvy users, this obviously is not the case,
>    but then again, technologically savvy users are probably more likely to use
>    SSL for their websites as well.


Actually, there are many SSL sites as there are SSH sites, more or less
(the distinction being Microsoft servers versus Linux servers).

But yes, there are many more websites than SSH sites.  There are o(100m)
websites and o(1m) servers from memory, very rough.  And then there's
Facebook...


>  + Generally, web sites that merely deliver public content don't have a real
>    need for security in these terms anyway.  Contrast against login shells,
>    which almost always deal with credentials, which inherently require
>    protection.


This is an assumption that is driven by the model, so it is somewhat and
mostly circular.

If you were to talk to a Librarian, would they be happy to report all
your book titles to the security services?  It's just public info,
right?  No need for privacy.


>  + A substantial number of web servers are service-hosted, and the hosters
>    obviously have no particular interest in having their customers' sites
>    protected.  Indeed, at least for almost all such hosting offers I came
>    across, even interactive access is done via FTP, which is unprotected.


Right.  What happens is a marketing phenomena known as 'discrimination'.
 The desire for better security is used as a way to charge more money.


> So I think the maths are not all that obviously convincing.  In fact, I suspect
> that the prevalence of SSH-based shell access and the relative rarity of
> SSL-secured web pages are more likely to be caused by the above factors.


They are, agreed.  But the above factors are caused by the attitude of
the SSL/secure browsing/PKI community.  A classical case is TLS/SNI.
How long did that take?  Why?  Because the community didn't see the need.

So, how do you run multiple SSL servers on your home site with only one
IP#?  Well, you can't.  Why?  Because the community doesn't see that you
need to.  Why not?  Because the community has decided that only large
ecommerce sites need SSL.  And they can pay for it.

Do you see how every factor you list comes back to a business model that
the PKI has created as a community, and you are promoting as the way to
do this?

The next step is to surface that business model, and change it.


> I am
> fairly certain that, given a decent infrastructure, admins are actually quite
> willing to use SSL.  At KIT, we are hosting on the order of 600 web presences,
> as far as I can tell, and close to 100 % of those web presences are accessible
> by HTTPS as well.

OK, a question out of curiosity:  TLS/SNI or separate IP#s?

Another question, from snarkiness :) :  Do you charge extra for this?


> Those instances that actually DO require privacy and
> protection (say, for login purposes) are accessible ONLY via SSL.  This is in
> my opinion a direct benefit of the fact that the DFN PKI (which is a cost-free
> PKI structure coordinated by the German NREN and offered to all academic
> institutions in .de) allows us to run a very well-functioning and low-effort CA.


Ah, super, so I'm guessing the second question is NO. This is good.

> Again, this shows that it indeed CAN be implemented somewhat reasonably so
> securing your web server in a reasonably secure way does not imply prohibitive
> costs.  (Of course, this is neither to say that the same approach works for
> everybody nor that it is entirely cost-free in terms of effort.)


I'm all for it.  Don't get me wrong, I would wish that the world pushed
CA-signed certs to all sites, every one of them.  Why ever not?

It's not moral, it's security:  When phishing ripped the guts out of
ecommerce and made SSL and CAs into a joke, I then spent about a decade,
from 2003 to 2012, trying to fix it.  Failed totally.


>> X.509-style schemes are too expensive, for what they deliver.
> 
> Doubtful as a general statement IMHO.


:)  Deliver a solution to phishing and I'm happy, I'll look at the cost
and we can debate it.


>>> I beg your pardon?  I was arguing that both GPG and SSH trust models are not
>>> quite that good in real life.  I was not addressing cryptographic protection at
>>> all.
>> You were arguing that a trust model had to exist,
> 
> No.  I am sorry if I left that impression.  I didn't mean to say that a trust
> model necessarily must exist, I meant to say exactly what I wrote above: That
> the trust models of both SSH and PGP are not all that great in practical terms.
> Whether that is a problem or, if so, how serious it is depends on the
> circumstances.


Well, the thing is, the trust model for SSH is great for its
environment.  The sysadm, the direct known users who get ssh access, the
machine, etc.  Tight.

For PGP the trust model is less adept but also it migrated in
environment from the early 1990s to now.  In essence the trust model (to
put it in PKI terms) is one of users-agree-informally.  This works to a
good enough extent that it has survived without much question.

The better (politer) way to put the trust model in PGP is that PGP
deliberately left it out of the technology and allowed it to be a layer
above.  This is very smart, because it totally avoided the mistakes of
the x.509/PKI world.  It is however rather begging for someone to come
along and actually create that trust model ... (speaking as someone
who's done it) ... and nobody has done that for the world, so it is easy
to assume that the absence of a trust model in the technology is the
complete absence of a trust model.

So, long and short:  if you assume a hammer (PKI trust model) then the
nails of PGP and SSH look rather ... like thumbtacks or pins.


>> and it is made up of
>> procedures and so forth.  Without procedures, a trust model doesn't
>> exist, in PKI terms.
> 
> That is not the case IMHO.  The trust model per se has nothing to do with
> procedures.  I am saying that CAs have the potential to make life easier for
> everybody by drafting and publishing sensible CP/CPS.


I agree that this theoretically exists :)  But I'd also say it's never
going to happen.


> This may be as simple as
> for CAcert, where the assertion for a user certificate is basically "the owner
> of this certificate has shown that she can access the inbox of the mail address
> in this certificate."  This may or may not be a useful assertion, depending on
> what you want to do.


Ah, excellent example.  The assurance statement is below;  It has been a
momentous task to get people to understand it, and simplify it in text.
 I wish someone could make it simpler!



1.1.The Assurance Statement

The Assurance Statement makes the following claims about a person:

    The person is a bona fide Member. In other words, the person is a
member of the CAcert Community as defined by the CAcert Community
Agreement (CCA);

    The Member has a (login) account with CAcert's on-line registration
and service system;

    The Member can be determined from any CAcert certificate issued by
the Account;

    The Member is bound into CAcert's Arbitration as defined by the
CAcert Community Agreement;

    Some personal details of the Member are known to CAcert: the
individual Name(s), primary and other listed individual email
address(es), secondary distinguishing feature (e.g. DoB).

The confidence level of the Assurance Statement is expressed by the
Assurance Points.

http://www.cacert.org/policy/AssurancePolicy.php



It generally takes about three goes for people to understand it.


>> I'm talking about protection, how it is delivered, and whether it is
>> delivered.
> 
> Okay.  That changes the subject, and the discussion on this will be over rather
> quickly, I suppose, because we are in agreement there, as I see below.
> 
>> We can talk about trust models, but that's only a precursor to protection.
> 
> Yep.  Absolutely (in our context).
> 
>>> Again, as does SSL.  You are mixing up providing encryption with the (much
>>> different and in many respects also much harder) problem of establishing trust.
>>> We were discussing trust models.
>> Your thesis that PGP has no useful trust model, whereas PKI does.
> 
> Nope.  I was saying that PGP has no defined way of providing assistance for
> trust assignment, but that CAs can (and do) provide such assistance (not all of
> them do, obviously, and not all are equally useful, obviously).


I saw this hint earlier and found it tantalising.  Other than CAcert, I
did not know of any CA that provided any followup on what you're calling
the 'trust assignment'.

What does your CA do here?


>> My thesis is that PKI does not deliver a trust model that works, for
>> ordinary people.  So I'm not sure why we would even want to compare.
> 
> I don't want to compare.  You keep saying that SSH is so much better than SSL
> because SSL does things in terms of validation that you don't quite see fit,


Yes, SSH is aligned to its business model.  SSL/PKI imposes too much
cost for what it delivers, it drifted from the real business case and
imposed something else.


> which is all well, and in particular you were arguing to leave SSL out of ACH as
> a consequence.  That last bit is the part I am not happy with.


Right.  My thesis is that I don't think it is possible to help, in any
simple short terms that fits in the terms of the guide.

It's my thesis, I'd love to be proven wrong.  Don't spend time arguing
with me, write it :)


>>> The encryption parts of SSL and SSH are
>>> essentially the same.
>> Sure, the crypto is the same.
> 
> Cool, so about that part we are in agreement then.  Let me rephrase what
> immediately follows then, because it seems to me to be important: Both SSL and
> SSH offer the same level of protection in terms of encryption of connections.


Yes, agreed.  At the level of encryption, yes, and their tech, which is
almost the same.

(Not however at the level of MITM.)

But, if we understand that they are separate businesses, we're part the
way there to understanding that the crypto being the same is actually a
red herring.  And potentially a red flag.

>>> Again, we were discussing trust models.  Don't change the subject, please.
>> Trust models are not a be-all and end-all.  They exist for a reason, and
>> they have to deliver on that.
> 
> Yep, sure.
> 
>> What I'm saying here is that SSH gets by without a trust model.  Smart.
> 
> Neither true nor necessarily smart.  Of course SSH has a trust model, and
> everybody and his brother is trying hard to get people to actually pay attention
> to host keys and such.


mmm... Remember, when I see the term 'trust model' it is for me
something invented by x.509/PKI for their purposes.  So, the term always
carries that baggage with it.

Yes, you can analogize it in other systems.  But that is taking PKI
theory to places where it was not needed / wanted / appreciated.

We think differently in those other places, so when we talk at the PKI
trust model concept, it is always trying to speak in another culture's
language.

SSH doesn't have a trust model as such, it has a security model, with
elements you might call trust.  In that security model, only trusted
people with a need for SSH access get access.  Yes, it's a trust model,
but it's really a security model.


> Now whether it is smart to ignore host key validity is
> neither for me to decide nor generally trivial to determine, but it certainly is
> not what the SSH designers want you to do.


Well.  The attention to SSH server key changes has increased over time.
 This is probably as a response to the increasing threat environment.
It's also to some extent as a response to loud criticism from outside...

I think most in the SSH community understand the model, intuitively, and
the risks.  I don't think the SSH designers are naive to what the model
says.


>>  x.509 PKI struggles to sell a trust model, and fails to deliver trust.
> 
> Again, I don't subscribe to that statement in its universality.


Sure.  I mean, that's undoubted for anyone who is pressing the case of
the CAs.  Nobody wants to work in a field were trust has been broken.

In precise terms, have a look at the Alice trust vectors above and the
discussion of what 'trust' is re-imposed to mean.

In particular, what happens with a root list when there is a rogue CA?
The whole equation breaks down, and the imposition of permission to
access over Alice becomes dis-trust, where before it was not-trust.


>>  Not smart, but honestly, it isn't worth arguing about.
> 
> True in this context.
> 
>> The real key here is:  why does SSH survive without a trust model?
> 
> Answer: It doesn't.  You just ignore it, and many (most?) people live fine
> without doing hard key verification.


:) It survives because its business environment has something better:  a
tight security model.  Few sysadms grant shell / SSH access to just
anyone.  Sysadms trust their users, if you like.

Websites do grant access to anyone, and they don't trust them at all.

Chalk and cheese?  How can the verification of the key be compared?


> This is not a very good argument IMHO.  This is essentially saying, "look,
> nothing has ever happened here in the past, so there is no need to worry about
> it."  Not true in general, and certainly not a very convincing line of
> reasoning, at least not for me.  Might work, might even work in 99% of the
> cases, but it is bound to fail eventually.


Au contraire!  It is a great argument, it is representative of real
life.  It's economic.  It's backed by history.  It's the bedrock of the
insurance industry.  It's what real people do:  base their choices on
their experiences and knowledge, and they do not listen to doomsayers
with silvery toungues.

It is only the IT Security industry that has found itself in such a
complicated space that has drifted into FUD as routine:  it might
happen, I heard from a friend of a friend that it is dangerous, so we
must do something about it...


>>> Yes.  X.509 PKIs are all about establishing trust.  This has nothing to do with
>>> what you are getting at with the encryption of stuff.
>> Right.  Add, that trust has to deliver.  Are CAs trusted?  Answer:  No.
> 
> Answer: Depends.  Why do you keep insisting that because you don't trust any CA
> there is no CA that can ever be trusted?
> I DO trust our CA very much, thank you.


Yes, I might too.  I trust my CA.

But do I trust CAs, plural?  No, because I know too much.

Does Alice trust CAs, plural?  No, she is not permitted to, she has them
imposed on her.  She has no room for trust, and no trust can therefore
develop.  Alice cannot trust CAs by the very definition of the word, trust.

Granted, she might come to trust my CA, or yours.  But that is a
process.  (We call that process membership and assurance.)


>> One might ask, why are they used?  Easy answer:  because browsers insist
>> that is the only way.  CAs aren't trusted, you have no choice but to
>> trust them.  Which is not trust, it's compulsion.
> 
> You can very well choose which CAs to trust, and I for one do.  I am not saying
> it is easy, I am not saying it is for everybody, but it can be done.


Precisely.  It is not easy, it takes real technical and business skill,
and as a practical matter it is out of reach to 99.99% of browser users.

We're here for them, right?  We're not here for the 0.001%.


>> Trust comes from the user and is proven when she makes a choice to
>> proceed.  She has no choice in connecting to her online bank, she has to
>> proceed with whatever is done.  That isn't trust, that's force.
> 
> True.  So shame on the bank that it requires the user to use a secured web
> connection instead of a plaintext HTTP one?


Bank doesn't have much of a choice either.  But, yes, the system works
for the context of online banking to the extent that it delivers them a
security proposal.

Albeit, with holes in it that hackers drive trucks through.  Therein
lies the rub.  The banks bought into the whole thing hook-line&sinker,
and every time they get stuck in court because some poor granny got
raided, nobody has a clue what went wrong.

The answer is here:  SSL was sold as a perfect model, but it got breached.



(BTW, I use SSL to be synonymous with secure browsing, because that is
what it is for.  I talk about TLS when talking about the more protocol
aspects.)


>> It's a common criticism of the marketing of PKI that they took the word
>> of 'trust' and reversed its meaning.
> 
> Interesting, I've heard many complaints about PKI in my time, but that never
> came along.


OK, maybe not so common, and isn't popular with CAs :)


>>> Nope, I still beg to differ, and have given a number of counter-examples.
>> It's not enough to show a counter-example.  That just says the world
>> could be different.  You have to actually show that the costs aren't there.
> 
> No.  You are making a general statement, which is not true, as shown by
> counter-example.  In contrast, I am not saying that PKIs cannot be run in such a
> way as to be braindead or overly costly or so.  In fact, I would agree that
> there are many CAs out there that do just that.  But that is not a feature that
> is inherently part of a PKI, that's all I'm saying.


My general statement(s,many) are about the world of PKI/CAs in their
plurality.  Granted, any particular CA can break ranks.  But this
changes nothing, because of the dymamics.  For Alice, and granny, they
are still faced with the plurality, the combined effect.


>>> Good one.  That is exactly the point.  Nobody actually does that.  If you accept
>>> that nobody ever actually verifies SSH host keys, then the security level of SSH
>>> takes a serious dent
>> No, it has a feature or a foible.  The security would take a dent if
>> hackers actually started doing MITMs *and* SSH couldn't defend.  They
>> don't, it can, so we're not that worried.
>> In contrast, SSL's security level isn't just dented, it's shattered.
>> One word:  Phishing.  They did, SSL couldn't, and it broke.
> 
> Alrighty, you are confusing things on a number of levels here.  Let's sort it
> out.
>  + SSH cannot defend against MITM if host keys are not checked.  So, assuming
>    that that is not the case (as you are), then SSH is indeed not capable of
>    alleviating MITM.


Host keys are checkable by SSH users, and they can be checked easily
enough, because SSH pins it, and prints out the differences.  These days
it even forces the user to reset, if differences are spotted.)



(Actually, that isn't true, really or at all.  The niggle here is that
the user doesn't know the host key because the fingerprint isn't easily
discernable, and to get the comparable fingerpring requires (a) loggign
into the server, and (b) uttering magical incantations.  But this is a
subtlety lost to most ... it's funny that SSH survives all this time
when in fact users cannot check the host keys..., they can only respond
to the suggestions... :) )


>  + "You haven't seen any MITM attacks" is not quite the same as "they don't
>    happen" or "they are so insignificant that the risk can be ignored."


In risk analysis, it is.  Short words.  We can go for longer words.

http://www.metzdowd.com/pipermail/cryptography/2014-January/019556.html

Be very careful about proposing that an attack with no evidence is an
attack that has to be addressed.  There be dragons.

Remember Iraq?  Same problem.


>    I am
>    quite worried about SSH MITM attacks when it comes to certain (very few)
>    systems, but I agree, for most systems, I am somewhat less concerned.  I DO
>    get nervous, though, when an SSH host key changes unexpectedly, which goes to
>    show that I am, in fact, sufficiently worried about MITM that I disregard the
>    (more likely) cause of a simple careless system reinitialization, which
>    wouldn't worry me at all, in favor of the more worrisome MITM scenario.  The
>    reason is simple:  It is better to err on the side of caution, and a single
>    successful MITM would be catastrophic on very many machines that I use.  (It
>    also goes to show that apparently the simple check of SSH host key change
>    detection is sufficient for me to sleep well at night, so indeed in most
>    cases it does not require something like an entire PKI to do the job.)


Right.


>  + Phishing is an attack that explicitly sidesteps SSL.


Right.  So Phishing is a bypass attack, or a downgrade attack (remember
the complaint about 99% of websites?).

But it's also an MITM -- which is rather hilarious.

The main point here is that SSL is in place within secure browsing for
the sole purpose of securing access of the user to her bank or ecommerce
site.  Phishing breaches that.

SSL was re-designed for this goal:  to stop the MITM.  That's what SSLv2
was all about, adding PKI.

In its flagship use case, it failed to stop the MITM.


>    In fact, it is another
>    example of what to tell users to look out for.  SSL can indeed help avoid
>    being phished if people paid a little more attention to the information their
>    browsers give them on an SSL-secured connection.


Defenders on the SSL side will say:  oh that's not us that's them.
Defenders on the browser side will say, oh that's the mailer's fault.
Mailer devs will say that's the user's fault, and the browser needs to
tel the user who she is talking to.

I say, they're all FoS.

SSL failed, and they, all of them, did nothing nix nada zip *nothing*
about it.  Therefore, as PKI/CA/certs is the answer to the MITM, that
whole thing has failed too.

It did not deliver, when it had to deliver.  It is only a historical
curiosity for us security geeks to find out why.



Compare that to SSH?  It delivered.  When the password crunching started
up, there were changes.  It's responsive.


>>> (see above; I know quite a few hard-core security guys that
>>> will argue that running SSH without checking fingerprints is snake oil).
>> Yes, and they are irrelevant.  Here is the thing:  security is always
>> about the threats in reality, not the theory in someone's mind.
> 
> Yes, certainly.
> 
>> Do you have meteor protection?  Do you wear body armour when going to
>> the shops?  Do you watch for cars when you are on the pavement?
>> The answer is no, yet these threats exist. Same with the MITM, it
>> exists, but the frequency and likelihood is so low, you are economically
>> better off ignoring it.
> 
> Quite possible for many cases, but I doubt this is the case in general.
> Do you wear a bicycle helmet?  I don't, but I am aware that I'm running a risk
> there.  Given my cycling habits, I'm fairly confident that this risk is
> acceptably low, but the consequences of failing to wear a helmet are often
> catastrophic for the few cases it is actually needed.  Do I feel the risk is
> negligible for me?  Obviously I do, but that doesn't mean I think it is
> negligible for everybody else as well.  And certainly the fact that I have so
> far never observed a single incident in which a bicycle helmet would have done
> me any good is a very very weak argument for my position of not wearing one.
> Yes, I may well be economically better off not having one: it costs money, it is
> an additional burden, in my personal opinion, most helmets look ridiculous, but
> all things considered, my gut feeling tells me that I can run the risk.  And
> guess what, next week I just might find out I was wrong.


Right -- so you have a choice!  Very important.

Now, the real, key, scientific difference between bicycle helmets and
meteor umbrellas is this:  history.

We have scientifically validated numbers on the effect of bicycle
helmets.  The hospitals see enough cases that they can use statistics to
say what good they do and what good they don't do.

We don't have that for meteors [1].

And, guess what:  we don't have it for MITMs.  So you are in a world of
(politely) judgement or (impolitely) FUD.



> I am indeed very
> impressed; I would have a real hard time proclaiming that MITM attacks are so
> unbelievably unlikely that they don't matter at all, particularly for
> juicier systems.


Absence of evidence is no evidence of absence :)

But actually, in risk analysis, we can say that.  If we have no
evidence, and no plausible economic model of an attack, then it isn't
worth mitigating.

We don't say they don't happen.  We do say, we'll pay for them as they
happen.  And we'll win.


>> Until that economic assessment is understood, there will be no
>> understanding of the SSL v. SSH debate.  Sadly for PKI, users understand
>> it far better than us geeks.
> 
> Doubtful IMHO, to be honest.


They do;  users are naturals at risk analysis.  It's what they do every
day, all day.  It is us geeks that have to unlearn.


>>> Exactly right.  The question is, do we want to pretend that if we ignore X.509
>>> completely, all the security problems related to it will magically vanish, or do
>>> we want to help make stuff a little better?  I am in favor of the latter,
>>> because I, for one, don't have the luxury to ignore X.509.
>> All the security problems with x.509 remain.  I'm not saying they vanish.
> 
> Yet you suggest that we don't even bother to explain them to people.


Yes, not bother, but save our resources.  Unless you can make a
difference, don't waste your time.  My time is precious.  I hope yours
is.  All these people here are working like slaves to prepare a good
guide, their time will soon be over.  They can only sustain this level
of output for a time.

Then, what they have done counts much more than what they tried and
failed to do.

(In economics, this is called opportunity cost.)


>> I guess we should leave the final vote to others :)
> 
> Fine with me. -:)




:)

iang





[1] As a surprising fact, we actually do have about 1 person per year
being struck by meteors.  So we could do the maths...  But for the
analogy, the falsity of my statement still serves, nobody gets hit by
meteors so we ignore it.