On Sat, Apr 5, 2014 at 12:03 PM, Viktor Dukhovni <[email protected]> wrote: > On Fri, Apr 04, 2014 at 02:27:32PM -0400, Stephen Nightingale wrote: > >> https://www.had-pilot.com/dane/danelaw.html. > >> The three DANE clients based on TLSlite 0.4.6, GnuTLS 3.1.16 and OpenSSL >> 1.0.1e all now incorporate Viktor Dukhovni's 'C' language dane checker >> and return consistent - though not identical - results. > > To be precise, currently each of these: connects, dumps the server > certificate chain to a PEM chain file, and invokes my DANE verification > code in an "offline" mode to validate the chain against each of > the TLSA records. That way the verification code is independent > of the TLS toolkit used to complete the connection. > >> - Dougbarton.us works with GnuTLS, but generates handshake failures with >> TLSlite and OpenSSL. > > Something is not right with the above, at least with OpenSSL 1.0.1 > I get a working SSL connection with dougbarton.us. Now this server > presents a chain with just the leaf certificate, even though the > issuing CA is an intermediate CA. When I put both the intermediate > cert (attached) and its issuing root (attached) in a CAfile, I can > verify the dougbarton.us "1 0 2" TLSA record just fine. > >> - Kumari.net and Spodhuis.org both complete handshakes with TLSlite and >> GnuTLS, but fail against OpenSSL. > > OpenSSL succeeds for me with spodhuis.org. Same StartCom root and > intermediate as dougbarton.us, but spodhuis actually presents a > full chain. > > Likewise www.kumari.net works, and the "TLSA 1 0 1" record matches > with the PKIX root from Equifax. > > Do connections to these sites work for you with "openssl s_client"?
Works for me with OpenSSL 1.0.1. > This warrants further investigation. > Yup. >> - Kumari.net returns 403 forbidden to TLSlite and GnuTLS, but works with the >> Browsers. I am guessing the 403 is generated because my clients do not send >> a certificate. I will be testing for bi-directional verification sometime >> in the future. Actually the 403 was being returned because some stupid webscrawler script kept DoSing me, so I denied anything that didn't include an "accept: " header. I've now removed that and the TLSlite and GnuTLS tests now show a page instead of the 403. While looking into this I found: [Sat Apr 05 19:12:50 2014] [error] [client 66.84.81.58] script not found or unable to stat: /usr/lib/cgi-bin/dane, referer: https://www.had-pilot.com/dane/yourdane.html in my log, which made me giggle... W > That's an application layer issue, that is not really relevant for > testing DANE. Once the TLS session is up, you can just disconnect, > without even sending an HTTP request. > >> GnuTLS is running all 0xx and 1xx certificate uses, serving a single end >> certificate per use. It runs 24/7 robustly. It can only be configured to >> take a single end certificate for the server handshake. When presented with >> a concatenation of PEM certs, it will send only the end cert in the server >> side handshake. > > That does not sound right, are you sure about that? RFC 2246, 4346 > and 5246 all require servers to present a chain with more than just > the leaf certificate unless directly issued by a root CA. So it > would be rather surprising of GnuTLS were not capable of presenting > a complete chain. Almost certainly you just need to invoke it > differently to load a complete chain. > >> The OpenSSL DANE server is running all 3xx certificate uses, with a single >> wild card end certificate. Whether it can serve a full PEM concatenated >> certificate chain is a question still to be investigated. > > OpenSSL definitely supports presenting a complete chain. > >> The near-future course of the DANE project at NIST will now focus on SMTP >> uses, for both MUAs and MTAs. > > I think the issues with the HTTP use case are not protocol-specific > and will crop up again with SMTP. So they should be addressed. > > -- > Viktor. > > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane > _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
