[Ach] StartSSL for Business Sysadmins

Alexander Wuerstlein arw at cs.fau.de
Tue Jan 14 17:25:37 CET 2014


On 14-01-14 09:09, Tobias Dussa (SCC) <tobias.dussa at kit.edu> wrote:
> Hi,
> 
> On Mon, Jan 13, 2014 at 03:26:00PM +0100, Alexander Wuerstlein wrote:
> > 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.

Interesting, didn't know that one, and I'm a physicist[0] :)
But that is usually not the case for commercial CAs, where quite a few
certificates are signed each day in a more or less automated process.
And maybe 'root' is a bit imprecise, I meant 'the CA certificate in
their chain they use for signing all customers' certificates'.

> > For everything else there are more trustworthy, systematically better
> > alternatives like ssh- and GPG-keys. Or private, organisation-wide CAs,
> > but with those there are still the generally weird problems with X.509
> > itself.
> 
> So in what world are GPG and SSH better concepts?  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.
> 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.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)

GPG has a somewhat more flexible model of trust than X.509, which is
usually modelled along the lines of personal trust. Of course client
software could always be improved to display those relations in a more
meaningful way, currently its horrible. There are even things akin to
CAs in that model. The important difference is, an end user can define
his immediate circle of trust, something which he is familiar with from
day-to-day life. From that, he can automatically display non-immediate
trust relations via others who, in a way, vouch for the identity of
remote users.

The important difference is that the trust anchors in GPG are people you
know and trust in real life. In X.509 its a database delivered by your
software vendor or admin. There is a fundamental difference in the level
of trustworthiness involved.

> but SSH host key verification?  C'mon, who are you trying to
> fool?

Nobody, I don't verify all those SSH host keys either. But other than
the X.509 concept of "you just trust all the CAs in your database", SSH
provides a practical way to be sure that I am notified if something
changes. SSH provides, in that sense, a usable way for general
certificate pinning, which in X.509 is just a specialty for a few
browser implementations and certificates, nothing that could be used in
practice for everything out there. That such a functionality is
necessary for all X.509 clients should be obvious from the published
incidents with *.google.com-certificates. There are some browser
extensions that do something like that, but they are far from widespread
use.

> And I'm not even considering Joe R. Loser here as target audience, who
> probably neither sufficiently grasps the concept nor gives a shit.  For those
> people, SSH and GPG are simply worthless in terms of the security problems that
> are being laid at X.509's feet.

Yes, but in those cases X.509 is also worthless because of Joe R. Loser
clicking "ignore and accept" everywhere. Users who simply don't care are
beyond help. Additionally X.509 brings a lot of baggage others simply
don't have like underspecified meanings and interpretations of various
fields in certificates, byzantine standards and the generally bad
implementation of ASN.1 parsers.

You are right that none of all those systems is perfect and each has its
weaknesses in certain areas. But unfortunately for X.509 all those CAs
are usually more part of the problem than of the solution. What is
rather needed is a very strict standard for the behaviour of clients
when interpreting and reacting to certificates, and a more flexible way
of dealing with trust than the current binary model with an almost
unchangable set of authorities.

A better solution would involve not selecting a subset of CAs that is
unconditionally accepted as valid, but providing better clients that
allow easy certificate pinning, signatures by multiple entities that may
be other CAs, previous replaced certificates and other users and
web-of-trust like configuration and display of trust relations for
certificates. Similarly, additional means of specifying expected
certificates or CAs for a server operator are necessary, e.g. DANE. That
way it is easier for users to trust or distrust CAs and certificates
based on geography ("I don't trust those Elbonians and their
government-mandated CA!"), appropriateness ("why is that certificate for
foobar.something.com from a different CA than www.something.com or than DNS
specifies"), historical conditions ("why has that certificate changed
before its end of life and why isn't it signed by its predecessor?").
All of those are changes in the protocol away from the current model of
binary, fixed CA trust because that model is faulty in itself and needs
to be changed.



Ciao,

Alexander Wuerstlein.

[0] btw, https://www.gridka.de delivers a certificate that is only valid
    for web-kit.gridka.de.
[1] http://www.heise.de/security/meldung/Mail-Verschluesselung-Mittwochs-PGP-Schluessel-zertifizieren-bei-Heise-2077038.html



More information about the Ach mailing list