SSL / HTTPS Man-in-the-Middle Attacks
2008-12-24 Initial Post
The other month I was wondering if HTTP SSL traffic could be spoofed by some type of man-in-the-middle scenario and just the other day I read an article, http://redmondmag.com/columns/article.asp?editorialsid=2946, that mentioned SSL inspection. That article basically answered my question and gave me some additional insights into SSL. After doing some research on SSL and MITM, I found these resources that were interesting:
• http://www.pburkholder.com/sysadmin/SSL-mitm/index.php
• http://www.mail-archive.com/cryptography@metzdowd.com/msg07178.html
• http://www.mail-archive.com/cryptography@metzdowd.com/msg07181.html
Based on what I’ve read, SSL filtering or SSL MITM attacks are possible, but under very special circumstances and many things have to be coordinated for that to work. A proof of concept can be created in a lab environment, but in the real world it would be much more difficult. Some things that support SSL security are
• Since its end-to-end, the data between the Web server and client must be unaltered. Proxies and firewalls can change the IP addresses and other routing information, but the data itself cannot be altered, otherwise the SSL session would be invalidated.
• To initiate the SSL session, the client encrypts a challenge using the server’s public key. So based on this, anything intercepting the encrypted challenge would need the server’s private key to decrypt it. If the server responded with the wrong challenge, then the client would know that the server did not have the correct private key and therefore the SSL session would not be valid.
• There are proxies and similar network devices that can inspect SSL traffic, but to do so, they must establish two separate SSL sessions, one with the Web server and one with the client. The proxy would not be able to truly impersonate the server since it wouldn’t have the server’s private key. The proxy can “pseudo-impersonate” the server ONLY if the client trusts the proxy as a CA. This would require that the proxy be on the client’s list of trusted CAs.
##### Per http://redmondmag.com/columns/article.asp?editorialsid=2946 on 2008-12-24:
To get around this, SSL inspection solutions normally create certificates on the fly that they present to the client. This can be done very quickly and for any Web site a user may try to access. Creating certificates on the fly leads to a problem, though. Unless the certificate was issued by a trusted CA, the Web browser will warn the user and recommend against proceeding. Users should certainly heed this warning because they generally can't verify whether the certificate was issued by a device on their network or some impostor on the Internet. To make everything look normal, you must configure each browser to trust certificates that were created by the proxy server. To do this, you add its certificate to the browser's list of trusted root CAs. You can even centralize the deployment of the certificate by using Group Policy, for example. #####
Note that it’s possible for an organization to filter and inspect SSL traffic. As mentioned in the Redmond article, the organization just needs to use a GPO to install the proxy’s certificate as a trusted CA on the client computers. If you’re unsure whether your organization is filtering SSL, go to your bank’s Web site and then view its certificate in IE to see if a standard root CA such as VeriSign or Thawte issued the certificate. If you see a root CA that doesn’t look familiar, look it up to verify whether it’s a legit, public root CA. Otherwise, it could be your organization's proxy CA.
