5 ms·

Forward Secrecy for Google HTTPS

97 points by dpeck 15y ago

benblack 15y ago
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
101001010111 15y ago
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?
- benblack 15y ago
  Correct!
- tptacek 15y ago
  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 15y ago
    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.
ominous_prime 15y ago
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 15y ago
  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 15y ago
    Thanks - I missed the DHE optimizations, and it's really nice to see that these improvements were immediately fed back into OpenSSL.
    - stock_toaster 15y ago
      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 15y ago
        It kind of has to be less performant, just because ECDHE uses more bignum crypto primitives.
        15y ago
dekz 15y ago
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 15y ago
  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.

97 points by dpeck 15y ago

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

101001010111 15y ago

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?

benblack 15y ago
Correct!
tptacek 15y ago
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 15y ago
  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.

ominous_prime 15y ago

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 15y ago
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 15y ago
  Thanks - I missed the DHE optimizations, and it's really nice to see that these improvements were immediately fed back into OpenSSL.
  - stock_toaster 15y ago
    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 15y ago
      It kind of has to be less performant, just because ECDHE uses more bignum crypto primitives.
      - 15y ago

dekz 15y ago

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 15y ago
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.