News for hackers. Stuff that matters.
Re:Forward Secrecy for Google HTTPS by tptacek on Tuesday November 22, 2011 @03:29PM (#3267196)
I think this is a reasonable concern about DHE, but this blog post was specifically intended to rebut the concern: they optimized DHE and use EC (faster, smaller keys), and managed to get it deployed across all of Google. The subtext is that one reason DHE isn't widely deployed is poor implementation, and they've taken a step towards correcting it.
Re:Forward Secrecy for Google HTTPS by ominous_prime on Tuesday November 22, 2011 @03:52PM (#3267305)
Thanks - I missed the DHE optimizations, and it's really nice to see that these improvements were immediately fed back into OpenSSL.
Re:Forward Secrecy for Google HTTPS by stock_toaster on Tuesday November 22, 2011 @06:10PM (#3267876)
The post made it sound like just the bugfixes are in 1.0.0e, but the performance improvements may have not been accepted yet. I wonder if that is the case?

This is good to see, and I really appreciate the work google has put into making tls/ssl more pervasive.

I do wonder about the performance differences between their faster DHE implementation and what they were using before (RSA-RC4-SHA). I wish they had provided a bit of data on that.

Re:Forward Secrecy for Google HTTPS by tptacek on Tuesday November 22, 2011 @07:45PM (#3268171)
It kind of has to be less performant, just because ECDHE uses more bignum crypto primitives.
Re:Forward Secrecy for Google HTTPS by stock_toaster on Tuesday November 22, 2011 @08:35PM (#3268343)
Yeah, that makes sense.

I was mostly curious about how much faster their new implementation was over the old, and how much slower it was than RSA-RC4-SHA.

Re:Forward Secrecy for Google HTTPS by marshray on Wednesday November 23, 2011 @12:20AM (#3268881)
I think that with the session resumptions they got by using session tickets, this could easily end up being a net gain for them.
Re:Forward Secrecy for Google HTTPS by cperciva on Tuesday November 22, 2011 @08:48PM (#3268378)
DH over elliptic curves is definitely fast enough for general purpose use, but on low-power devices it could be problematic. I think a better approach is the one I used in spiped: Each connection can pick whether to do a DH computation and get forward secrecy or to instead use a DH exponent of zero and still get regular secrecy.

Alas, SSL doesn't support such a mechanism.

Re:Forward Secrecy for Google HTTPS by marshray on Wednesday November 23, 2011 @12:17AM (#3268870)
Why can't the client just not list the DH cipher suites in the Client Hello?