

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

======
TrevorBurnham
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...

------
steve19
" 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!

~~~
agl
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).

~~~
briansmith
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
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.

------
cybernytrix
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!

------
nuclear_eclipse
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?

~~~
agl
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.

------
grandinj
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.

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

<https://encrypted.google.com/>

