Last updated: 18th of April 2001.
The vulnerability was analysed by:
Secure Sockets Layer (SSL) provides a secure communication channel between two peers. SSL provides secure means to authenticate the peers and then proceed with an encrypted and tamper-proof session between the parties. The authentication and key-exchange is based on public key cryptography. The actual traffic is encrypted using secret key cryptography due the performance reasons. There exists multiple versions of SSL (v2, v3 and TLS) which are all referred as SSL throughout the text as all versions of SSL have same functionalities when considering man-in-the-middle attack against it.
The peers in SSL session are authenticated using public key certificates. SSL can be used to tunnel any application level protocol, which would be otherwise run on top of TCP. The most common use nowadays is to secure the HTTP communication (shortly HTTPS). However, in HTTPS case the client browsers are not usually authenticated but only the server side is authenticated by SSL.
The following attack analysis focuses to HTTPS only. In case of HTTPS the user has usually possibility to decide whether to accept the certificate represented to her/him or not. Together with the lack of client peer authentication this opens possibility to man-in-the-middle attack which is a widely known feature of SSL. The attacker can fake the server to the client and create two secure channels, one to the client and one to the server. After the secure communication channels are established, the communication can be relayed between the channel ends points at the attacker in plaintext. The real server has no means to realise the difference, as the client is not authenticated by the cryptographic means.
As usually in man-in-the-middle attacks the attacker must redirect the client's communication to himself. In practice it means redirecting the IP packets targeted to a remote server to the attacker instead. There are several ways to implement the redirection. In this attack the authors chose DNS spoofing due its simplicity and because the redirection mechanism itself is irrelevant to the SSL man-in-the-middle attack.
Once the traffic is being routed through the attacker a special tool is required to relay the traffic between the original peers. As the communication is encrypted an active relay tool is required as simple TCP forwarding is not enough. The authors chose the webmitm tool available as part of dsniff package.
As the communication occuring between the victims is routed through the attacker, the attacker must have good-enough network connections. The extra hop in traffic route should not cause any noticeable effects, meaning e.g. significant increases in latencies or decreases in bandwidth.
The webmitm tool requires that the client browser gives the virtual host name in the HTTP request. The virtual host name is required as the HTTP traffic is redirected to the attacker and the IP of the original TCP connection target server is unknown to the webmitm tool. Luckily most modern HTTP based browsers give in HTTP GET requests the virtual host name. The rationale for the virtual host name is that there can exist multiple HTTP servers behind one IP and without the virtual host name in the incoming HTTP request the server has no means to know which server a client intended to connect.
The client HTTP browser must allow user to accept non-trusted server SSL certificates i.e. the browser must allow the user to accept unknown certificates as trusted ones. The browsers usually have this possibility due the usability reasons. Another option for the attacker is somehow to insert the certificate of the fake server to the list of trusted certificates in the client browser. However, this requires access to the client host and its browser installation and thus is not in the focus of this attack.
The attack involved three hosts:
The attacker and the client were in the same Local Area Network (LAN). In addition to the hosts mentioned above the attack involves a fourth host, the domain name system (DNS) server. The DNS server was not located in the same LAN as the client and the attacker, but had to be accessed through IP router by the client. Thus, the DNS spoofing was trivial to implement for the attacker. For more details on practical DNS spoofing implementation, see this page.
The attack has the following steps.
# ./webmitm -d warning, not much extra random data, consider using the -rand option Generating RSA private key, 1024 bit long modulus ....................++++++ ...........................................++++++ e is 65537 (0x10001) Using configuration from //etc/openssl.cnf You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:FI State or Province Name (full name) [Some-State]: Locality Name (eg, city) []:Espoo Organization Name (eg, company) [Internet Widgits Pty Ltd]:Hakkeri-kurssi Organizational Unit Name (eg, section) []:HUT Common Name (eg, YOUR name) []:Mr. Hacker Email Address []:hack-me@hack.com Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []:extra An optional company name []:Optional Signature ok subject=/C=FI/ST=Some-State/L=Espoo/O=Hakkeri-kurssi/OU=HUT/CN=Mr. Hacker/Email=hack-me@hack.com Getting Private key webmitm: certificate generated webmitm: relaying transparently
The detection is next to impossible by the SSL server, as the server does not usually authenticate the client browser. However, the client has the possibility to realise the on-going attack. The client browsers, if they are not explicitly to ignore silently suspicious certificates, warn in most cases about a certificate not signed by a trusted party to the browser. If the user does read the warning, before clicking yes button, she/he has a possibility to realise the attack.
If the client host was exposed and the browser's trusted certificate signer information was changed, then the client browser will not even warn about on-going attack.
The protection actions can be divided to two groups: to the counter-measures that prevent the redirection of the network traffic through the attacker and to the counter-measures that prevent the possibility of misauthentication of peers.
Unfortunately, the counter-measures in neither of groups are not comprehensive or trivial to implement. The redirection of traffic can be made harder by using DNSSEC, but it's still possible by other means than DNS spoofing. The protection efforts should be clearly focused to the counter-measures in the second group.
The client browsers could be configured not to accept certificates signed by untrusted parties. In some cases, this might however reduce significantly the usability of the client browser as there exist HTTPS servers using self-created certificates. In any case, the client browsers must always warn about the untrusted certificate and not to be configured to trust blindly and silently the untrusted the certificate. For example, Internet Explorer 5 can be configured in such manner!
The users should be aware of the possibility of the man-in-the-middle attack. The users should not blindly accept the untrusted certificates and especially not to install these untrusted certificates to their browsers. If they install them, the future connections to the attacker won't generate even a warning to the user and the attack is impossible to detect.
The HTTPS servers should always use certificates signed by public authorities e.g. VeriSign, Baltimore, GTE etc. Then the client hosts can authenticate the servers with pre-installed public keys of these public authorities. Also, the public keys of trusted signers can be distributed to the client browsers e.g. in Intranet SSL usage.
The authors did not manage to get Internet Explorer 5 to send the virtual host name in every HTTP request. As the virtual host name was not sent in every HTTP request, the webmitm tool was unable to relay the HTTP requests not including the virtual host name. Opera 5.1 sent the virtual host name properly with every HTTP request.
The DNS spoofing worked perfectly, as one could suspect. Once the client had accepted to trust to the attacker by approving the untrusted certificate and sent the HTTP request with virtual host name defined the relaying worked seamlessly. The webmitm dumped the plaintext HTTP headers and requests to the console of the attacker and all passwords were easily readable from HTTP POSTs.
The results indicate the risk of SSL man-in-the-middle attack is very real and the users of applications utilising SSL should be aware of it. The public tools are high quality and relatively easy to use. Thus, the attack is implementable even by a person with very limited knowledge about the SSL or networking in general.