[Ach] StartSSL for Business Sysadmins

[ianG]

On 14/01/14 13:16 PM, Tobias Dussa (SCC) wrote:
> Hi,
> 
> On Tue, Jan 14, 2014 at 11:34:34AM +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

>>>> Physical security may be nice in general, but its beside the point. All
>>>> your steel doors with two locks and stuff won't help if a) your software
>>>> is faulty (please show me the CA that has its root cert completely and
>>>> utterly offline, some HSM doesn't count)
>>> That's easy: http://www.gridka.de/ca for starters.  And while I'm not entirely
>>> certain, I do believe that all EUGridPMA-accredited CAs have to be strictly
>>> offline.
>> So, IMHO, it turns out that the whole offline/online thing is not so
>> reliable.
> 
> The point taken above was "oh, well, there's no CA that REALLY uses offline root
> certs anyway," and I have given an example of a quite active CA that does just
> that.  What you are getting at is an entirely different problem.


Oh I grant that you can show me a CA that does it "properly" assuming we
can agree on that.

But, can a user see that?  This is one of the philosophical problems
with audit.  If there are 20% that aren't, then there is no reliability
in this question.  And the user is correct to assume so.

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.


>> You can't trust the audits and you can't trust the
>> pronouncements.  Nor can you actually trust the notion.  The CAs
>> regularly do one thing and say another.  They have their techniques for
>> dealing with the costs and conundrums and the audit.  They're not
>> published, just shared hand-to-hand.
> 
> Certainly.  That's beside the point though.  Anyone worth her money will tell
> you that for security, it always boils down to who you trust in the end.


Indeed, well maybe. It's a context.  Anyone who markets PKI will tell
you it is about trust.  Anyone who's in physical security will tell you
it is all 3G - guns, guards and gates.  Also canines.  Anyone who's a
mother will tell you it's about the children!

They are all right, and all... blinkered?  Not sure of the right word here.


> The
> entire point of PKIs (both in the hierarchical sense of X.509 and the GPG sense)
> is that you do NOT want to have to manually inspect every single key.  If you
> are fine with doing that, cool, off you go, but in that case, neither the PGP
> trust model nor X.509-style PKIs are for you.


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?


>> This is just one area where the whole compliance thing is smoke & mirrors.
> 
> 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 :)


>>> 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.
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.

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).

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, it's about how
to improve the lot for everyone.  How does ACH advise users to do better
PKI?


> 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, they do provide the user
>>> the theoretical possibility to do key verification in a more sensible way.  That
>>> doesn't mean that people actually do that.
>> That is exactly why SSH wins over SSL.  It provides the possibility for
>> verification, but it does not force it on users.  So the cost is optional.
> 
> I beg your pardon?  It is better because it does not force verification?  Srsly?


Seriously.

> 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.

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?


>> 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 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?

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.


> (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.

PKI is full of people who say that crypto without authenticity
verification is worthless.  I can't help that.


>> The numbers are stark -- we're talking like 99.99% of the benefit is
>> accrued if you don't verify, because nobody does MITMs.
> 
> So you are arguing that X.509-style hierarchical PKI schemes are crappy because
> so far you have not seen many MITM attacks on SSH?  I fail to see how that is
> related, honestly.


No, it's economics, or maths.

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.

(OK, there are a couple of them here:
http://wiki.cacert.org/Risk/History )

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.

X.509-style schemes are too expensive, for what they deliver.


>>> In fact, at this point, I'd say that
>>> the vast majority of serious GPG users are somewhat concerned about their
>>> privacy, certainly more so than the average, and even THESE people don't always
>>> verify stuff properly.
>> You are confusing procedures with protection.
> 
> 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, and it is made up of
procedures and so forth.  Without procedures, a trust model doesn't
exist, in PKI terms.  Example:  PGP has no procedure to establish the
meaning of a sig.


>> Measurable protection is
>> provided by SSH because it keeps servers secure.  The attacks on servers
>> through rsh and telnet before SSH were quite severe, now they are pretty
>> much eliminated, and have been since around 1998.
> 
> Those attacks were aimed at the fact that telnet and rsh are plaintext
> protocols.  Neither SSL nor SSH by itself guarantees that encryption is used,
> much less that sensible encryption is used.
> On the other hand, if implemented properly, BOTH SSL and SSH DO offer protection
> by encryption.  How is that related to the underlying trust model?


I'm talking about protection, how it is delivered, and whether it is
delivered.

We can talk about trust models, but that's only a precursor to protection.

>> (OK, there are still
>> password attacks, but easily solved, and SSH should just turn off
>> password authentication and be done with it).
> 
> True.  Different problem though.
> 
>> Meanwhile, you can talk procedures all you like, but at the end of the
>> day, you have to establish protection, to users, not procedures.  The
>> reason that SSH and GPG people do not follow the procedures so much is
>> that they don't need to -- they get the protection without the procedures.
> 
> 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.

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.


> The encryption parts of SSL and SSH are
> essentially the same.


Sure, the crypto is the same.


>>> Some do, and I certainly almost always do decent GPG key
>>> verification (though there have been occasions when I was reasonably certain
>>> that a given GPG key was authentic and the information to be passed was not
>>> sufficiently important but time was critical, so I felt that was good enough for
>>> the occasion), but SSH host key verification?  C'mon, who are you trying to
>>> fool?  And I'm not even considering Joe R. Loser here as target audience, who
>>> probably neither sufficiently grasps the concept nor gives a shit.
>> Wrong.  SSH host key verification isn't typically done because the most
>> part of the protection is provided.
> 
> 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.

What I'm saying here is that SSH gets by without a trust model.  Smart.
 x.509 PKI struggles to sell a trust model, and fails to deliver trust.
 Not smart, but honestly, it isn't worth arguing about.

The real key here is:  why does SSH survive without a trust model?


>> PKI on the other hand is a business that sells itself on the procedures:
>>  verifications, audits, compliance, physical security, etc etc, long
>> list taken from documents.
> 
> 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.

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.

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.

It's a common criticism of the marketing of PKI that they took the word
of 'trust' and reversed its meaning.


>> It delivers long on procedures, but fails to deliver protection at a
>> cost-effective rate.
> [...]
>> If you're talking about the different business spaces here, sure.  The
>> SSL world declines to provide cost-effective security.  Oh well.
> 
> 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.


>>> The fact is that in the real world, there are trade-offs to be made between
>>> valid security goals, usability, effort required (financial and otherwise), and
>>> user acceptance.
>> Right.  And the tradeoff of SSH is pretty nigh perfect.  You get most of
>> it for free.  If you're under MITM attack, then check the server
>> fingerprint too.
> 
> 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.


> (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.

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.

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.


>>> In the end, fundamentalistic lines of reasoning are necessary
>>> to create awareness and keep an audience, but at the end of the day those
>>> simplistic views don't do anything to help improve security in practical terms,
>>> which is what this project is about.
>> The point stands:  how do you advise people to improve security with PKI
>> in practical terms?
> 
> See above (or other mail? I forget).
> 
>> At the end of the day, it is all and only about economics.  What gets
>> good enough security for the user at the lowest cost?
> 
> 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.


> I am perfectly happy with your point of view, and it is also perfectly alright
> with me if you decide not to contribute in this area.  Fair enough.  But you
> are arguing that the entire X.509 domain should be left out of ACH, and with
> that I don't agree.  If we agree that X.509 should not be addressed, fine with
> me as well, I don't mean to impose, but I do think we should not ignore it.


I guess we should leave the final vote to others :)



iang