4 ms·

I am glad you mentioned (EC)DHE. The TLS snap start draft is quite discouraging against (EC)DHE ciphersuites because it says snap start doesn't work for (EC)DHE

I am glad you mentioned (EC)DHE. The TLS snap start draft is quite discouraging against (EC)DHE ciphersuites because it says snap start doesn't work for (EC)DHE key exchange, and I got the impression that Google isn't interested in using (EC)DHE, despite its significant security advantages. I think snap start would work for resuming connections that were originally started with (EC)DHE key exchange. And, with an optimal OCSP stapling + snap start configuration, the only types of handshakes that would be done would be full non-snap-start handshakes (with OCSP responses stapled to them) and snap start resuming handshakes. This leads me to believe that snap start only needs to be defined for the resuming case; if snap start full handshakes are happening then it means something needs to be improved w.r.t. OCSP response caching. I believe this would make snap start much simpler. Coincidentally, I was just working on reducing memory consumption in NSS, probably very similar to the way that you reduced it in OpenSSL. I am curious as to why Google is doing its optimizations for servers using OpenSSL and for clients using NSS. What makes NSS less suitable for servers than OpenSSL?

agl 16y ago
There are several aspects of the web's transport security ecosystem which need to be improved, and the addition of DHE is one of them. The latency implications of DHE are a problem: it pretty much requires an extra round trip. As you mention, we could amortise that over several connections using resumption, and we might well do that. We can also do SSL connection pre-warming to get rid of the latency issues. We have lots of ideas, but not an army of people working on them I'm afraid :) To answer your other question: our use of different SSL libraries on the client and server side are largely historical. Having said that, OpenSSL is easier to hack away on. Personally, I find that, at the small scale, NSS code is cleaner. However, on the larger scale OpenSSL wins. Once I get past the insane OpenSSL code style, I prefer hacking on OpenSSL.

agl 16y ago

There are several aspects of the web's transport security ecosystem which need to be improved, and the addition of DHE is one of them. The latency implications of DHE are a problem: it pretty much requires an extra round trip. As you mention, we could amortise that over several connections using resumption, and we might well do that. We can also do SSL connection pre-warming to get rid of the latency issues. We have lots of ideas, but not an army of people working on them I'm afraid :) To answer your other question: our use of different SSL libraries on the client and server side are largely historical. Having said that, OpenSSL is easier to hack away on. Personally, I find that, at the small scale, NSS code is cleaner. However, on the larger scale OpenSSL wins. Once I get past the insane OpenSSL code style, I prefer hacking on OpenSSL.