To prevent a man-in-the-middle from obtaining the SSL/TLS key

httpsSecurityssl

As I understand it, the main reason to use HTTPS over HTTP is that the communication is encrypted so that anyone listening in is not able to view the plain text of the HTTP exchange between client/server.

Now, at the start of the session the client and server agree a master key based on the information obtained during the SSL/TLS handshake. But what is to stop someone listening in from also obtaining the key using the same cipher suite agreed by the client/server?

If there is nothing to prevent that, then how is HTTPS actually that much more secure than HTTP? All it would take for a MITM would be to engineer the key themselves using the information taken from the handshake and use it to decipher the communication between the client and server.

I must be missing something…

Best Answer

The client and server only agree on a key, they never actually send it in plain.

Most commonly, DH key exchange (2) or its ECDH variant are used – each peer only combines its DH private key with the other peer's DH public key and both obtain the same result. If you watch the traffic, you will only see both peers' public keys, which is not enough to derive the resulting session key. (The TLS handshake later verifies that an attacker hasn't injected its own pubkeys.)

Another method (nowadays rare) is "static RSA" – in this mode, the client generates the session key on its own and encrypts it using the server's public key (obtained from the SSL certificate). Although the key is sent over the net, only the server is able to decrypt it.

(While the "static RSA" method might be simpler, it is also less secure – obtaining the certificate's private key would allow one to decrypt all old and new HTTPS sessions; in other words, there is no forward secrecy. Also it requires the certificate to have a keypair capable of encryption/decryption, while DH-style key derivation only needs sign/verify.)

Related Solutions

Security – How to List SSL/TLS Cipher Suites Offered by a Website

I wrote a bash script to test cipher suites. It gets a list of supported cipher suites from OpenSSL and tries to connect using each one. If the handshake is successful, it prints YES. If the handshake isn't successful, it prints NO, followed by the OpenSSL error text.

#!/usr/bin/env bash

# OpenSSL requires the port number.
SERVER=$1
DELAY=1
ciphers=$(openssl ciphers 'ALL:eNULL' | sed -e 's/:/ /g')

echo Obtaining cipher list from $(openssl version).

for cipher in ${ciphers[@]}
do
echo -n Testing $cipher...
result=$(echo -n | openssl s_client -cipher "$cipher" -connect $SERVER 2>&1)
if [[ "$result" =~ ":error:" ]] ; then
  error=$(echo -n $result | cut -d':' -f6)
  echo NO \($error\)
else
  if [[ "$result" =~ "Cipher is ${cipher}" || "$result" =~ "Cipher    :" ]] ; then
    echo YES
  else
    echo UNKNOWN RESPONSE
    echo $result
  fi
fi
sleep $DELAY
done

Here's sample output showing 3 unsupported ciphers, and 1 supported cipher:

[@linux ~]$ ./test_ciphers 192.168.1.11:443
Obtaining cipher list from OpenSSL 0.9.8k 25 Mar 2009.
Testing ADH-AES256-SHA...NO (sslv3 alert handshake failure)
Testing DHE-RSA-AES256-SHA...NO (sslv3 alert handshake failure)
Testing DHE-DSS-AES256-SHA...NO (sslv3 alert handshake failure)
Testing AES256-SHA...YES

EDIT: Add flexibility as host and port are provided as parameter to the script

How to block specific HTTPS traffic

Although the example you cite in your question is trivial to achieve with a proxy because the URLs are not encrypted, and therefore easy to add to a blacklist, it IS possible to inspect HTTPS traffic going through a proxy.

Enterprise deployments usually achieve this by deploying an internally trusted certificate to their entire installed end user machines. Connections to the proxy server are done via this certificate (whether the users realise it or not), where the proxy software can decrypt the payload, inspect it and decide on its validity. The onward connection to the end site is done with "real" certs.

This is a bit of a sad state of affairs really, as it breaks the trusted model of SSL and TLS - but I know for a fact it's done - as it happens where I work.

Best Answer

Related Solutions

Security – How to List SSL/TLS Cipher Suites Offered by a Website

How to block specific HTTPS traffic

Related Question