Overclocking SSL

http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html

by kgutteridge • 16 years ago

54 14 16 years ago

steve192• 16 years ago

" However, with a pure RSA ciphersuite, an attacker can record traffic, crack (or steal) your private key at will and decrypt the traffic retrospectively, so consider your needs."

Can somebody please explain what this means. Sounds bad!

agl3• 16 years ago

RSA ciphersuites involve the client generating a random session key, encrypting it using the server's public key and sending it to the server. The session key is then used to key the MAC and bulk cipher.

If an attacker records the traffic, then factors or steals the public key, they can decrypt the session key and read the traffic.

With ephemeral Diffie-Hellman, a random DH public value is generated for each connection and the server signs it with its public key. Each side then performs key agreement to generate the session key. Now, an attacker can solve the discreet logarithm and decrypt the traffic, but they have to break each connection separately.

The trick in the future is to perform Diffie-Hellman much faster (answer: write tuned code to work in an elliptic curve group) and then to perform EDH without the latency hit (longer term).

briansmith2• 16 years ago

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?

briansmith2• 16 years ago

Just to add to what agl said:

With RSA key exchange, if somebody ever gets your RSA private key, they can decrypt all past and future traffic that was protected with that key. With ephemeral Diffie-Hellman key exchange, even with the RSA private key, they cannot decrypt that past and future traffic, because each session has its own unique encryption keys that are independent of the RSA keys. They can only impersonate you to intercept future traffic, and only if they set up a MITM attack, but that kind of active attack is MUCH harder to execute (especially undetected) than the passive attacks that RSA key exchange allows. And, again, it doesn't allow them to decrypt past traffic at all.

This advantage of ephemeral key exchange is called "perfect forward secrecy."

For example, let's say you are a dictator and you want to decrypt some encrypted GMail sessions you suspect were done by dissidents in your country last month. If those sessions were done with RSA key exchange, you could steal the RSA private key from Google today (admittedly a very difficult task) and then decrypt those past sessions. If (EC)DHE key exchange was used, it would be practically impossible (no exaggeration) to ever decrypt them.

steve192• 16 years ago

thanks for the replies.

nuclear_eclipse• 16 years ago

I'm curious why they recommend against 4096-bit certs; they say they mentioned it, but I must have missed it... Is it just because it will make the size of the certificate bigger?

agl3• 16 years ago

If you can afford 4096-bit certs, or you need them, then you should use them. However, on my laptop, I can only handle 34 connections/second/core with a 4096-bit cert. Such performance is likely to be unacceptable for many uses.

gxti• 16 years ago

Bigger numbers take much longer to crunch.

cdine• 16 years ago

They specifically mention that the certificate size (and that of intermediates, among other things) impacts the message size and thus the TCP packet sizes used during handshakes. They actually explain all of this quite well, just read the entire article [specifically the "Certificates" section].

TrevorBurnham• 16 years ago

Great read. Don't miss the last section, in which Google talks about the things they've been doing in Chrome and Android to make SSL seedier, especially in Google apps. In case anyone was wondering why Google made a browser...

ash• 16 years ago

The author mentioned encrypted Google search - I haven't heard of it before:

https://encrypted.google.com/

grandinj• 16 years ago

So what they're really saying is "Yes you should enable HTTPS provided you check all sorts of things and understand all sorts of complicated stuff".

Speaking for those of us living with long-latency links to the US (South Africa), unnecessary HTTPS on websites is a major PITA.

cybernytrix• 16 years ago

I worked out a solution on solving exactly this problem in a browser setting using Javascript. Before you jump on man-in-the-middle, DNS spoofing, code injection or cross domain security, please take a look at http://www.research.rutgers.edu/~ashwink/ajaxcrypt/ and let me know if you have any comments!

Overclocking SSL

Related Stories