[openssl-dev] [openssl.org #3621] Support legacy CA removal, ignore unnecessary intermediate CAs in SSL/TLS handshake by default

Hubert Kario hkario at redhat.com
Tue Dec 16 14:02:22 UTC 2014


On Monday 15 December 2014 16:32:42 Viktor Dukhovni wrote:
> On Mon, Dec 15, 2014 at 05:24:03PM +0100, Tomas Mraz wrote:
> > > This can break DANE TLSA verification, because the site's designated
> > > trust anchor might no longer be in the shorter constructed chain.
> > > 
> > > [Postfix not affected]
> > 
> > Please enlighten me how this case could be broken by this change of
> > default? If the trust anchor is not found in the trust list, the
> > intermediate that is sent by the peer is followed anyway.
> 
> The DANE TLSA issue stands.
> 
> DANE TLSA PKIX-TA(0) records can designate the digest of a trust
> anchor selected by the server operator.  When TLS server transmits
> a corresponding certificate chain it may not be safe to replace
> that chain with a shorter chain, because the shorter chain may not
> employ the designated trust anchor, causing DANE TLSA checks to
> fail.

But then why would you use the PKIX chain builder with system root store?

If you use DANE with CA digest, then the server needs to send all 
certificates, so you just need to validate the chain you have - you don't have 
to build it, you already have it built and in correct order, you just need to 
verify signatures and root digest.

If you really want to use the PKIX builder and verifier (to workaround 
misconfigured servers), then you search for the cert with matching digest, 
load it as trusted, load other certs as untrusted and then try to verify peer 
certificate with such trust store.

So it does affect only buggy DANE clients with a root that is signed by other 
root (and probably you could even argue about misconfigured DANE records - 
missing all valid trust anchors).

-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic


More information about the openssl-dev mailing list