Google improves SSL session security
Google was the first major Internet company to implement a function to protect against future loss of the secret key on HTTPS servers (called perfect forward secrecy or PFS). An open-source add - on to OpenSSL was developed for this, in particular, a fast key generator was written on the P-224, P-256 and P-521 elliptic curves. In the course of their work, Google experts also fixed several bugs in OpenSSL.
PFS means that even if a secret server key is received (hacked), an attacker will not be able to decrypt previously intercepted and recorded HTTPS traffic. A real-life example: suppose that some organization at the provider level records and stores all your HTTPS traffic, and if necessary receives a secret key on the server (or many years later the computers have enough power to crack it with a simple brute force), after which reads all the accumulated correspondence without any problems.
In the case of Google, this option will not work. Now, short-lived (“ephemeral”) session keys are used that are exchanged according to the ECDHE scheme (the abbreviation ECDHE stands for “ Diffie-Hellman ephemeral algorithm using elliptic curves”). After the communication session, the keys are destroyed, and even the owner of the server will not be able to decrypt the session that his server has encrypted with the previous key.
The standard HTTPS scheme implies a “handshake” using RSA, RC4 and SHA algorithms, that is, the client (browser) selects a random key for the session, encrypts it with the public key of the server, signs it with its private key - and sends it to the server. This session can only be decrypted using the server's private key and the user's public key, so the session is considered secure.
')
Adding to the ECDHE scheme means that the server for each session generates a new public key and signs it with its private key. Thus, the session is not only secure at the moment, but also protected from the future loss of the server's secret key. To generate public keys, Google uses P-256 elliptic curves, the cryptographic strength of which roughly corresponds to the 3248-bit RSA.
Currently, PFS is considered an optional feature and is rarely used as an HTTPS option, and Google was the first major company to implement it by default.
The perfect forward secrecy system is implemented in all Google HTTPS services (this is Gmail, Google+, Google Docs, SSL Search) and is supported by Chrome and Firefox browsers. Unfortunately, IE browser does not yet support the combination of ECDHE and RC4.
You can be sure that the ECDHE key exchange mechanism is used if during a secure communication session with Google you click on the SSL icon in the address bar.
Since the add-on for OpenSSL is available for open-source, other web services can implement a similar HTTPS upgrade.
via Google Online Security Blog , Adam Langley
PFS means that even if a secret server key is received (hacked), an attacker will not be able to decrypt previously intercepted and recorded HTTPS traffic. A real-life example: suppose that some organization at the provider level records and stores all your HTTPS traffic, and if necessary receives a secret key on the server (or many years later the computers have enough power to crack it with a simple brute force), after which reads all the accumulated correspondence without any problems.
In the case of Google, this option will not work. Now, short-lived (“ephemeral”) session keys are used that are exchanged according to the ECDHE scheme (the abbreviation ECDHE stands for “ Diffie-Hellman ephemeral algorithm using elliptic curves”). After the communication session, the keys are destroyed, and even the owner of the server will not be able to decrypt the session that his server has encrypted with the previous key.
The standard HTTPS scheme implies a “handshake” using RSA, RC4 and SHA algorithms, that is, the client (browser) selects a random key for the session, encrypts it with the public key of the server, signs it with its private key - and sends it to the server. This session can only be decrypted using the server's private key and the user's public key, so the session is considered secure.
')
Adding to the ECDHE scheme means that the server for each session generates a new public key and signs it with its private key. Thus, the session is not only secure at the moment, but also protected from the future loss of the server's secret key. To generate public keys, Google uses P-256 elliptic curves, the cryptographic strength of which roughly corresponds to the 3248-bit RSA.
Currently, PFS is considered an optional feature and is rarely used as an HTTPS option, and Google was the first major company to implement it by default.
The perfect forward secrecy system is implemented in all Google HTTPS services (this is Gmail, Google+, Google Docs, SSL Search) and is supported by Chrome and Firefox browsers. Unfortunately, IE browser does not yet support the combination of ECDHE and RC4.
You can be sure that the ECDHE key exchange mechanism is used if during a secure communication session with Google you click on the SSL icon in the address bar.
Since the add-on for OpenSSL is available for open-source, other web services can implement a similar HTTPS upgrade.
via Google Online Security Blog , Adam Langley
Source: https://habr.com/ru/post/133268/
All Articles