Dan Kaminsky's Blog

I have deployed KEY1 on mattmccutchen.net.

There seems to be a gap in the security of phreeload: it checks for KEY1 at the certificate’s common name, but OpenSSL-based applications will also accept the certificate for its subjectAltNames. Unfortunately, the way the OpenSSL API is designed, there is no single X509_verify_cert_for_host function that phreeload could override to supply the right semantics. That functionality is generally only brought together in application protocol implementations such as libcurl and libsoup. You could consider patching some of those instead.

Dan Kaminsky :
It’s safe, because of the assumption that something else later will check CN.

Not a good assumption. Almost all clients check the SAN.

I’ll add parallel SAN support to 1.03.

What does that mean? Phreeload would check for KEY1 at all of the names in the SAN? That would be slow, but maybe server operators would adapt by not using certificates with many names. What if the SAN contains *.foo.com? Even if there is a KEY1 at *.foo.com (a DNS wildcard), strictly speaking, you still need to know it hasn’t been overridden at somesub.foo.com, and there is no way to test all possible subdomains.

I say the API sucks because x509_verify_cert doesn’t actually know the name to compare against.

Of course it doesn’t, that’s not a defect. The defect is that determination of cert acceptability for a server name (which is what Phreeload needs to replace) is not encapsulated in a single function in any of the major open source SSL/TLS libraries. NSS and GnuTLS make applications call one function for X509 verification and another for a name check, while OpenSSL makes applications implement the name check themselves (way to get bugs!).

The “proper” solution would be to add better API to the libraries and port applications to use it. In the meantime, replacing ssl_verify_cert_chain and using the tlsext_hostname may work for most SNI clients. Alternatively, one could use Phoxie. Do you plan to release it to the public?

In the meantime, replacing ssl_verify_cert_chain and using the tlsext_hostname may work for most SNI clients.

I thought I had some reason that API wouldn’t work. Specifically, the name checking functionality just wasn’t there. Could be wrong though.

The OpenSSL function does not do a name check, but your replacement can. That will ensure that KEY1 endorsement, when applicable, is a necessary condition for a cert to be accepted. The application may do additional name checking, but that just means the admin has to use a cert containing the appropriate names, which is generally easy to arrange. If you take this approach, then the complexity of having to check all the SANs goes away.

Alternatively, one could use Phoxie. Do you plan to release it to the public?

It’s super sketchy python right now. Interested in helping me make a solid C port?

Interested, but unlikely to actually find the time. I’d encourage you to go ahead and release what you have so people can start playing with it.

In keeping with your goal of easy deployment, have you thought about making Phreebird automatically generate KEY1 records:
from the cert presented by the host, if the organization is confident in the security of their internal network
after verifying the presented cert against an existing X.509 CA operated by the organization?

Matt McCutchen :
The defect is that determination of cert acceptability for a server name (which is what Phreeload needs to replace) is not encapsulated in a single function in any of the major open source SSL/TLS libraries. NSS and GnuTLS make applications call one function for X509 verification and another for a name check

Correction: NSS has such a function, SSL_AuthCertificate.

I have made a proof-of-concept DANE implementation for NSS by modifying SSL_AuthCertificate. The DNSSEC is done with libunbound, inspired by Phreeload.