Last year we introduced HTTPS by default for Gmail and encrypted search. We’re pleased to see that other major communications sites are following suit and deploying HTTPS in one form or another. We are now pushing forward by enabling forward secrecy by default.
Most major sites supporting HTTPS operate in a non-forward secret fashion, which runs the risk of retrospective decryption. In other words, an encrypted, unreadable email could be recorded while being delivered to your computer today. In ten years time, when computers are much faster, an adversary could break the server private key and retrospectively decrypt today’s email traffic.
Forward secrecy requires that the private keys for a connection are not kept in persistent storage. An adversary that breaks a single key will no longer be able to decrypt months’ worth of connections; in fact, not even the server operator will be able to retroactively decrypt HTTPS sessions.
Forward secret HTTPS is now live for Gmail and many other Google HTTPS services(*), like SSL Search, Docs and Google+. We have also released the work that we did on the open source OpenSSL library that made this possible. You can check whether you have forward secret connections in Chrome by clicking on the green padlock in the address bar of HTTPS sites. Google’s forward secret connections will have a key exchange mechanism of ECDHE_RSA.
We would very much like to see forward secrecy become the norm and hope that our deployment serves as a demonstration of the practicality of that vision.
(* Chrome, Firefox (all platforms) and Internet Explorer (Vista or later) support forward secrecy using elliptic curve Diffie-Hellman. Initially, only Chrome and Firefox will use it by default with Google services because IE doesn’t support the combination of ECDHE and RC4. We hope to support IE in the future.)
Are you planning on moving to TLS 1.1 or TLS 1.2?
ReplyDeleteAre you planning on using an RC4 cipher that drops some packets to reduce the risk that the key can be recovered?
Thank you for adding fast security which is transparent to users.
TLS 1.1 and 1.2 support is a nice-to-have that we hope to pick up in the future, although we have no firm plans yet.
ReplyDeleteDropping key-stream output from RC4 helps avoid some known biases at the beginning of the connection. However, the plaintext at the beginning of the connection is already very well known (it's an HTTP request), and the same client doesn't encrypt the same data under very many keys. So dropping key-stream output is something that we could implement, but it doesn't seem to offer any significant benefits for the specific case of HTTP over TLS.
Thank you for bringing this to the attention of many website owners. It is sad that they don't implement these options. I do have some questions as knowing your thoughts could help the community.
ReplyDelete1. It's the key exchange that performs perfect forward security correct? If so, could one implement ECDHE with other symmetric cryptography such as AES?
2. Doesn't the standard Diffie-Helman (Merkle) key exchange also provide perfect forward security? Did you feel that it was too slow or not secure enough?
3. Is there was an EDH-RC4 option on all browsers, could this have provided the feature that you wanted?
1) Yes, the ECDHE key exchange is the part that provides the forward secrecy and ECDHE can be used with other ciphers, such as AES.
ReplyDelete2) TLS also provides an option for EDH: ephemeral Diffie-Hellman in a multiplicative group. We chose ECDHE because of the speed advantages: EDH in a 2048-bit group is plenty secure, but much slower.
3) Any browser that supports ECDHE-RC4-SHA will get forward secrecy with Google HTTPS sites. There's nothing Chrome or Firefox specific on the server side. A browser that supports only DHE-RC4-SHA will *not* get forward secrecy because we don't support EDH for speed reasons.
Are you planning anything for safari?
ReplyDeleteAm I misunderstanding something, or is the aspect of the value of forward secrecy you mentioned a little bit silly? In some number of years, an adversary will be able to break the symmertric cipher keys directly, and then forward secrecy will be irrelevant.
ReplyDeleteWHy the Gmail Certification still non-EV SSL (Extended Validation SSL)?
ReplyDeleteI am a new blogger and am concerned about safety of my private information on my blogspot blog. I do not see the "https://" before my web address - does this mean my blog pages are unsecure and that a hacker can gain access to my photos, etc., plus place unwanted graphics images on my site? I recently had to go thru the necessary steps on my facebook account for a "secure" page. Please help with any security information. thank you for the article!
ReplyDeleteJoAnn
It's not at all clear that an adversary will be able to break symmetric cipher keys directly in some number of years. For example, quantum computers (which are a very plausible future mechanism for breaking asymmetric encryption) don't work for symmetric keys.
ReplyDeleteIf security is your goal, why don't you support ECDHE_ECDSA_WITH_AES, which works in IE? RC4 is more expensive computationally if your CPU has AES-NI, and RC has been broken already.
ReplyDeleteI'm using Google chrome from the official Yum repositories on Fedora 16. When i visit either GMail or the Google home page, and click on the padlock icon, the Key Exchange algorithm is still mentioned as "RSA" instead of "ECDH_RSA". Any ideas?
ReplyDeleteThanks for such a nice post.
ReplyDeleteI did a lot of research on OpenSSL elliptic curves usage on a https website with a web server like Apache and nothing is clear. Could any of Google engineers post if the end-user is allowed to legally use the EC ciphers provided into OpenSSL package. Basically, all I want to know if I can legally reproduce the setup Google has now at https://www.google.com (RC4_128 with an ECHHE_RSA exchnage key).
ReplyDeleteCerticom detains various patents on EC and I would not like to wake-up with a lawsuit on my doorstep.
Thank you.
This week we learnt that intelligence agencies are blanket capturing internet traffic (in the UK, GCHQ's Mastering the Internet program takes 20 petabytes per day [1]), and archiving some of it. Meanwhile, spooks are trying to get their hands on providers' private keys (overtly by law, and presumably covertly by hacking). If this hasn't already happened, it will.
ReplyDeleteThus, encryption algorithms with perfect forward secrecy are a must. Compromise of a provider's house key shouldn't bring the house down. Encryption should fail gracefully, old conversations should stay private.
Thanks Google for implementing forward secrecy on your servers. But adoption has been snail's pace slow elsewhere [3].
Google, you drafted the upcoming HTTP 2 specification [2] to mandate encryption. That's the web every citizen wants. And you've already argued to protect that clause against parties more naive. Thanks again.
Now, I implore you Google, to strengthen the specification to mandate algorithms with forward secrecy. Your influence can help them be adopted widely. Privacy shouldn't be an option. Privacy should be universal.
[1] http://www.guardian.co.uk/uk/2013/jun/21/gchq-cables-secret-world-communications-nsa
[2] http://datatracker.ietf.org/wg/httpbis/charter/
[3] http://news.netcraft.com/wp-content/uploads/2013/08/heatmap2.png
Wasn't elliptic curve Diffie-Hellman an NSA. Plant onto NIST so NSA could break the encryption
ReplyDeletehttps://www.schneier.com/blog/archives/2013/09/the_nsas_crypto_1.html