[Ach] StartSSL for Business Sysadmins

Tobias Dussa (SCC) tobias.dussa at kit.edu
Tue Jan 14 21:46:41 CET 2014


Hi,

On Tue, Jan 14, 2014 at 05:25:37PM +0100, Alexander Wuerstlein wrote:
> > 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] :)

Of the right kind?  As in, experimental particle research? ;-))

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

Oh, yes.  Absolutely.  I do realize and admit that many, if not most CAs are not
exactly well-run in that respect.

> And maybe 'root' is a bit imprecise, I meant 'the CA certificate in
> their chain they use for signing all customers' certificates'.

Yep, I figured that.

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

Yes.  At the expense of "the user needs to take care of it."  May very well be
acceptable, may not be.

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

Again, absolutely correct (though I would again argue that the fact that there
is a more-or-less sensible pool of default CAs that are shipped with $OS is not
an inherent property of X.509 in principle).

And, again, in GPG you have no other choice but to actually do it yourself.

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

If that is what you are after, it is extremely simple to achieve at least for
FF: Just disable all root CAs.  This will make FF query you every single time
you encounter an unknown certificate, and storing that exception permanently is
effectively pinning this particular certificate.  Yes, it is a pain in the ass,
but it's essentially a one-time effort.

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

True, but with concepts like X.509 it is possible to define useful and sensible
defaults.  (This is not to say that the currently prevalent way of doing things
is sensible.)

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

Admittedly.  Again, I'm not claiming X.509 is perfect.

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

Absolutely correct for unfortunately many CAs, not true in general.

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

Full ACK.

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

Agreed, that'd be fantastic.

Cheers,
Toby.
> [0] btw, https://www.gridka.de delivers a certificate that is only valid
>     for web-kit.gridka.de.

*Sigh* Thanks for the pointer.  I'll pass it on.
-- 
There is enough in the world for everyone's need, but not for
some people's greed.
                                       ---Mahatma Gandhi

----

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



More information about the Ach mailing list