[Ach] StartSSL for Business Sysadmins

[Tobias Dussa (SCC)]

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

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

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

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

> > 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), and SSH deployment by itself does nothing
to improve security in terms of preventing MITM attacks and such.

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

> In contrast, with SSL, the cost is imposed.  So it creates a drag on
> economics.

What cost is imposed?

> And for what purpose?  Most of the benefit of crypto is
> found without verification.

Same goes for SSL.  (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.)

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

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

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

> (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.  The encryption parts of SSL and SSH are
essentially 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.

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

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

> > 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 (see above; I know quite a few hard-core security guys that
will argue that running SSH without checking fingerprints is snake oil).

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

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.

Just my €.02.

Cheers,
Toby.
-- 
Real Users hate Real Programmers.

----

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