[Ach] StartSSL for Business Sysadmins

[Tobias Dussa (SCC)]

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

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

Cool.

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

A rather black-and-white of a gray world, but yes, fundamentally this is
correct, of course.

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

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

Sounds about right, I'd say.  And yes, it is necessary to look at all sides of
the story to make a reasonable decision.

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

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

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

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

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

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

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

> >> 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.
All I'm saying is we should measure by the same standards.

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

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

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

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

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

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

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

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

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

Doubtful as a general statement IMHO.

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

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

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

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

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

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

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

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

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

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

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

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

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

> > 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.
 + "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."  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.)
 + Phishing is an attack that explicitly sidesteps SSL.  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.

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

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

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

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

Fine with me. -:)

Cheers,
Toby.
-- 
A Sig Sauer always beats a Royal Flush!

----

Karlsruhe Institute of Technology (KIT)
Steinbuch Centre for Computing (SCC)
KIT-CERT

Tobias Dussa
CERT Manager, CA Manager

Zirkel 2
Building 20.21
76131 Karlsruhe, Germany

Phone: +49 721 608-42479
Fax: +49 721 608-9-42479
Email: tobias.dussa at kit.edu
Web: http://www.kit.edu/

KIT – University of the State of Baden-Wuerttemberg and
National Laboratory of the Helmholtz Association