Google and Amazon do not offer ciphers using Diffie-Hellman Ephemeral mode.

[root@jne-f14 cnark]# ./cnark.pl –host amazon.com –port 443
….
SSL Certificate Information…

Certificate Commmon Name: www.amazon.com

Testing SSLv2 Ciphers…
DES-CBC3-MD5 — 168 bits, High Encryption
RC2-CBC-MD5 — 128 bits, Medium Encryption
RC4-MD5 — 128 bits, Medium Encryption

DES-CBC-MD5 — 56 bits, Low Encryption
EXP-RC2-CBC-MD5 — 40 bits, Export-Grade Encryption
EXP-RC4-MD5 — 40 bits, Export-Grade Encryption

Testing SSLv3 Ciphers…
DES-CBC3-SHA — 168 bits, High Encryption
RC4-SHA — 128 bits, Medium Encryption
RC4-MD5 — 128 bits, Medium Encryption

DES-CBC-SHA — 56 bits, Low Encryption
EXP-DES-CBC-SHA — 40 bits, Export-Grade Encryption
EXP-RC4-MD5 — 40 bits, Export-Grade Encryption

Testing TLSv1 Ciphers…
AES256-SHA — 256 bits, High Encryption
DES-CBC3-SHA — 168 bits, High Encryption
AES128-SHA — 128 bits, High Encryption
RC4-SHA — 128 bits, Medium Encryption
RC4-MD5 — 128 bits, Medium Encryption

DES-CBC-SHA — 56 bits, Low Encryption
EXP-DES-CBC-SHA — 40 bits, Export-Grade Encryption
EXP-RC4-MD5 — 40 bits, Export-Grade Encryption

[root@jne-f14 cnark]# ./cnark.pl –host google.com –port 443

SSL Certificate Information…

Certificate Commmon Name: www.google.com

Testing SSLv2 Ciphers…

Testing SSLv3 Ciphers…
AES256-SHA — 256 bits, High Encryption
DES-CBC3-SHA — 168 bits, High Encryption
AES128-SHA — 128 bits, High Encryption
RC4-SHA — 128 bits, Medium Encryption
RC4-MD5 — 128 bits, Medium Encryption

Testing TLSv1 Ciphers…
AES256-SHA — 256 bits, High Encryption
DES-CBC3-SHA — 168 bits, High Encryption
AES128-SHA — 128 bits, High Encryption
RC4-SHA — 128 bits, Medium Encryption
RC4-MD5 — 128 bits, Medium Encryptio
n

So….where are all the ciphers incorporating DHE (Diffie-Hellman Ephemeral mode), such as DHE-RSA-AES256-SHA?

What does this mean for the typical user?

Simply put: Google and Amazon are capable of decrypting all of their HTTPS traffic using only their private keys.  Some of the possible reasons why they would prefer to use these non-DHE ciphers: ease of debugging or dealing with government subpoenas asking for detailed traffic records.

However, what if the private keys have been compromised by outsiders getting a copy of the private keys? This could be accomplished by either 0-day exploits or social engineering (including, but not limited to, bribing internal staff). These outsiders would be capable of decrypting fully captured HTTPS sessions and be able to sniff out sensitive information such as credit cards, addresses, messages, etc.

Can the users fully (and more importantly, continually) trust that the private keys are not in possession of anyone outside Google or Amazon? Ciphers using DHE go a long way to add another layer of protection against this possible scenario.  DHE ciphers could, in a way, be viewed as the last line of defense in case the server private keys have been leaked. How about it, Google and Amazon? There’s room to improve the security for your web traffic/transactions…

This entry was posted in Web/Tech. Bookmark the permalink.
  • RemyJe

    Securing the private keys is necessary no matter which cipher suite is used. Just like SSH, web certs are only used for encrypting (and establishing the trust of) the initial handshake, thereafter symmetric encryption being done with the negotiated cipher. If the private keys were compromised then it really doesn't matter what cipher is used – clear text is still coming out at the end, or worse – in the middle, which is where someone with a compromised private key would likely take advantage of it.

    The ability to debug web services or access traffic records happens regardless of any encryption being used – again because it's all clear text at the ends. How records of your transactions with a particular web service are handled/stored are completely up to the developers/admins.

  • Diffie-Hellman key exchange was designed to counter the scenario where the server's private key has been leaked to outsiders.

    If the attacker was in possession of the server private key, they still would not be able to figure out the secret shared key that is independently established at both ends.

    With DHE, the secret shared key never travels over the network so the attacker (who is busy decrypting the communication with the private key) still doesn't have access to the shared secret key and will be left out of the subsequent symmetrical encryption for the rest of the session.

    Try wiresharking with HTTPS session using a DHE cipher, even when you load the private key, you'll find that you are still unable to decrypt.

  • RemyJe

    True, you won't be able to sniff (the key is only used to decrypt the handshake) but if you were in the middle (as in man-in-the-middle) during the handshake then the client will actually negotiate the symmetric encryption with you and not with the the web server they think they're talking to (hijacked connection or DNS cache poisoning, etc etc)

    Besides, if someone were to hack Google or Amazon with a 0-day exploit, they'd do what they could on the end (since they're already inside) which is a better place to be than the middle.

  • Yes, if the attacker is in a man-in-the-middle position between client and the server, it becomes a completely different ball game and many different attacks vectors are possible.

    I'm more focused on a scenario where the attacker is passively sniffing the traffic and is able to decrypt due to possessing a copy of the private key (very difficult to detect this on-going). Using DHE ciphers eliminates this scenario.

    The most likely scenario: Unassuming user downloads and runs a trojan horse which starts a hidden packet capturing program. This program records all encrypted Google traffic. At a later time, the records are transferred to a remote machine under the control of the attacker. The attacker possessing the server key could decrypt and read everything. Now if DHE was in use, the attacker would not be able to divine the shared secret key necessary to view the rest of the session beyond the handshake and the encrypted traffic is still secure.

  • RemyJe

    Securing the private keys is necessary no matter which cipher suite is used. Just like SSH, web certs are only used for encrypting (and establishing the trust of) the initial handshake, thereafter symmetric encryption being done with the negotiated cipher. If the private keys were compromised then it really doesn't matter what cipher is used – clear text is still coming out at the end, or worse – in the middle, which is where someone with a compromised private key would likely take advantage of it.

    The ability to debug web services or access traffic records happens regardless of any encryption being used – again because it's all clear text at the ends. How records of your transactions with a particular web service are handled/stored are completely up to the developers/admins.

  • Diffie-Hellman key exchange was designed to counter the scenario where the server's private key has been leaked to outsiders.

    If the attacker was in possession of the server private key, they still would not be able to figure out the secret shared key that is independently established at both ends.

    With DHE, the secret shared key never travels over the network so the attacker (who is busy decrypting the communication with the private key) still doesn't have access to the shared secret key and will be left out of the subsequent symmetrical encryption for the rest of the session.

    Try wiresharking with HTTPS session using a DHE cipher, even when you load the private key, you'll find that you are still unable to decrypt.

  • RemyJe

    True, you won't be able to sniff (the key is only used to decrypt the handshake) but if you were in the middle (as in man-in-the-middle) during the handshake then the client will actually negotiate the symmetric encryption with you and not with the the web server they think they're talking to (hijacked connection or DNS cache poisoning, etc etc)

    Besides, if someone were to hack Google or Amazon with a 0-day exploit, they'd do what they could on the end (since they're already inside) which is a better place to be than the middle.

  • Yes, if the attacker is in a man-in-the-middle position between client and the server, it becomes a completely different ball game and many different attacks vectors are possible.

    I'm more focused on a scenario where the attacker is passively sniffing the traffic and is able to decrypt due to possessing a copy of the private key (very difficult to detect this on-going). Using DHE ciphers eliminates this scenario.

    The most likely scenario: Unassuming user downloads and runs a trojan horse which starts a hidden packet capturing program. This program records all encrypted Google traffic. At a later time, the records are transferred to a remote machine under the control of the attacker. The attacker possessing the server key could decrypt and read everything. Now if DHE was in use, the attacker would not be able to divine the shared secret key necessary to view the rest of the session beyond the handshake and the encrypted traffic is still secure.

  • j0sh

    Interesting factoid: Stuxnet authenticated itself using certificates signed with stolen private keys. These private keys belonged to businesses in close proximity to one another. The best guess is the keys were taken through physical infiltration. Very cloak and dagger.

  • Dude, I did an NMAP scan of google.com, gives me the MD5 hash for the SSL…. just listen to some packets and you got em. Those boys that did stuxnet weren’t anywhere close to Google’s headquarters, lol.