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.
Dropping 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.
1. 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.
2) 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.
Am 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.
I 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! JoAnn
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.
If 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.
I'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?
I 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).
Certicom detains various patents on EC and I would not like to wake-up with a lawsuit on my doorstep.
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.
Thus, 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.
Wasn't elliptic curve Diffie-Hellman an NSA. Plant onto NIST so NSA could break the encryption https://www.schneier.com/blog/archives/2013/09/the_nsas_crypto_1.html
Follow
15 comentários :
Are you planning on moving to TLS 1.1 or TLS 1.2?
Are 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.
Dropping 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.
1. 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.
2) 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?
Am 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.
WHy the Gmail Certification still non-EV SSL (Extended Validation SSL)?
I 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!
JoAnn
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.
If 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.
I'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?
Thanks for such a nice post.
I 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).
Certicom 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.
Thus, 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
https://www.schneier.com/blog/archives/2013/09/the_nsas_crypto_1.html
Postar um comentário