

Forward Secrecy for Google HTTPS - dpeck
http://www.imperialviolet.org/2011/11/22/forwardsecret.html

======
ominous_prime
What worries me here, is a cargo-cult following of this advice.

Ephemeral Diffie-Helman adds an order of magnitude to the session initiation
overhead (nginx got a bad rap a little while back, becuase it has kEDH enabled
by default). I don't want to see people slide back into the "SSL is too
expensive" mindset, because they don't understand the SSL options they are
using.

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

~~~
ominous_prime
Thanks - I missed the DHE optimizations, and it's really nice to see that
these improvements were immediately fed back into OpenSSL.

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

~~~
tptacek
It kind of has to be less performant, just because ECDHE uses more bignum
crypto primitives.

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

~~~
marshray
I think that with the session resumptions they got by using session tickets,
this could easily end up being a net gain for them.

------
benblack
More great work from Google legitimizing and advocating for strong HTTPS
defaults. I'm looking forward to this being broadly adopted.

Securely Yours,

Lil' B

------
dekz
I'm sure these guys have thought about the longevity of data at rest when
selecting the security strengths on the EC curves and RSA keys. These chosen
parameters are quite high and they link to an article which mentions a period
of up to 2040 before having to be re-encrypted or expected potentially be
broken.

Make your own conclusions about that.

I'm not certainly a fan of session resumption and renegotiation's from a
potential security aspect, anyone care to persuade me apart from a performance
standpoint?

~~~
marshray
Look at it this way: session resumption enables you not start the handshake
all over again from scratch for every TCP connection your browser makes. This
mean you can actually do more secure things like preferring DHE on the initial
handshake because it happens much less often.

The session ticket support enables Google to use session resumption across
their massively load-balanced SSL terminators.

I don't think Google is using renegotiation in this architecture, but I think
we got renegotiation nailed down tight with RFC 5746.

------
101001010111
I am not a cypherpunk, but can/should we differentiate between 1. encouraging
those running OpenSSL/TLS servers to use a. sane defaults that allow forward
secrecy and b. ephemeral TLS session ticket keys, 2. using Google's in-house
EC cipher implementations and 3. doing 1. and 2.?

We could do 1. only and still reap some benefit, correct?

~~~
tptacek
There are environments where ephemeral DH keys violate policy (those sessions
can't be passively monitored; some sessions must be), which could militate
against PFS suites becoming the default.

DHE is good, but I'm not sure forward secrecy is as pressing a security issue
as simple adoption of TLS is. I admire Google's continued efforts to set the
standard for its secure deployment, though.

~~~
marshray
Look at it from Google's point of view though:

Now they won't have "lawfully intercepted" packet captures showing up in their
mailbox with demands that they decrypt them using their private key.

