httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emilia Kasper <>
Subject Re: mod_ssl patch: use new OpenSSL features to autofix cert chains
Date Thu, 27 Mar 2014 13:27:12 GMT
On Wed, Mar 26, 2014 at 5:46 PM, Daniel Kahn Gillmor

> On 03/26/2014 11:29 AM, Emilia Kasper wrote:
> > Cross-signing happens all the time but afaik the other way around, i.e.,
> an
> > intermediate Y' corresponding to a _newer_ root cert Y is cross-signed by
> > some _older_ root cert Z. So an old client would usually know only Z and
> a
> > newer client would know Z and Y (or even Y' - some clients directly trust
> > intermediates these days).
> >
> > W, Y' is the correct chain to ship. Shipping W, Y is unnecessary for
> > clients that have either Y or Y' in their local store - they can build
> the
> > chain from W alone. And conversely, shipping W, Y won't help against
> > clients that only know Z - they can't build the chain through Y' no
> matter
> > what.
> And by your patch, a server configured to ship W,Y would be stripped to
> a serve just W, which wouldn't work for clients that only know Z either.

Correct, but stripping Y wouldn't make anything worse either.

> > In general shipping a self-signed certificate should never help with
> > anything as the client must have an exact copy in the local store to
> trust
> > it. That said, there are always surprising perversities in SSL...
> ah, this brings to mind one other thought:  We're relying here on
> servers not using HPKP as a mechanism to introduce novel CAs that are
> only usable for a given host.

HPKP can never work this way. Pin validation is always done on top of
normal TLS validation and can only invalidate an otherwise valid connection
and never the other way around. Otherwise I could trivially hijack
connections by pinning sites to a fake FooCA.

> For HPKP, that might be possible, because

> ietf-websec-key-pinning-11#section-2.6<>
> suggests that any TLS errors will cause a connection termination anyway,
> before pins are checked.  But, it's conceivable that an HPKP
> implementation could modify a TLS stack to allow a novel root cert base
> on its SPKI matching a known pin for a given site.  I don't see that
> implementation choice explicitly forbidden in the spec.

In that section,

"When a UA connects to a Pinned Host, if the TLS connection has errors, the
UA MUST terminate the connection without allowing the user to proceed

"If the connection has no errors, then the UA will determine whether to
apply a new, additional correctness check: Pin Validation." (note the word

as well as

"The UA MUST note the Pins if and only if it received the Public-Key-Pins
response header field over an error-free TLS connection."

> to be clear about the scenario:
> a TLS server could use HPKP to indicate a set of acceptable signing
> authorities for the site, including the current certifying authority.
> This enables the site to indicate, say, that it is willing to rely on
> FooCA for its certificates (currently in use), plus BarCA, that the
> browser has never seen before.  The browser now has a hash of both
> FooCA's public key and BarCA's public key, and it knows that these two
> are the only legitimate signing authorities for the site in question.
> At some point, the site administrator switches over to BarCA (perhaps
> they learn that BarCA has finally been imported into the root store of a
> major browser that they care about).  But some clients don't list BarCA
> yet, even though they've recorded these public key pins.
> Now a server might want to explicitly ship EE,BarCA so that clients who
> know about the pin but don't yet know about the cert can make the
> connection.
> If we want to avoid this situation, maybe it needs to be clarified as
> something HPKP needs to forbid?  or maybe it's too far in the weeds to
> seriously consider it.
> > I'm clueless here - how often would a server installation have something
> > reasonable in /etc/ssl/certs?
> hm, well, the ca-certificates debian package (which will install things
> in /etc/ssl/certs by default) has a higher popcon score than
> apache2-bin, which is a requirement for apache:
> otoh, ca-certificates is also installed on desktop systems, and i don't
> think the summaries published by the popcon project show the
> intersection of two packages.  i can ask folks within debian about that
> if people think this sort of spot-check would be useful (it doesn't
> cover other OSes or even debian users without popcon installed, of course).
> > No current plans for CT to require logging intermediates. But actually,
> if
> > we go the autocorrect route then we should just implement AIA fetching.
> > Modern certs should have a CA Issuers field in the
> > AuthorityInformationAccess extension in them that the chain builder could
> > follow recursively
> ah, this sounds like a very useful piece of data.
> > I've now looked a bit more at the mod_ssl code and it's
> > a bit of work but maybe not all that different from doing OCSP, really?
> >
> > The wrinkle with remote fetching at runtime is of course that it's
> > nondeterministic, so you may end up serving a different chain depending
> on
> > the network weather. Print the corrected chain big and bold in the error
> > logs and live with it?
> it doesn't even need to fetch the certificate itself, it could just make
> the big noisy error log say "you should fetch the cert from <AIAURL> and
> append it to <SSLCertificateChainFile>"

As I said, I have low faith in admin intervention.. According to SSL pulse,
6% of Alexa top 200K sites serve an incomplete chain. You'd think they'd



View raw message