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 _______________________________________________ openssl-dev mailing list [email protected] https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
