Subscribe To CCIERANTS

Tuesday, September 15, 2009

Ironports can perform man-in-the-middle for SSL.

Ironport WebProxys are capable of intercepting SSL to ensure they are not being used to tunnel other protocols. It used to be that you could run your SSH daemon on port 443, and even if you where behind a proxy you could potentially tunnel your traffic via SSH so you can get out and do whatever it is you want to do (BitTorrent, MSN, etc. etc.)

The reason for this was fairly simple: Since the connection was a secure connection, the proxy could not see the traffic encapsulated inside the port and thus was unable to determine if it was legitimate traffic or not. Luckily however the Cisco Ironport has a method around this, by inserting itself in any SSL path, so the actual SSL stream looks like this:

Client Iron Port Secure Website.

The main drawback from this approach is that the certificate presented to the client will be untrusted, because it is signed by the Ironport application. This is easily resolved by either trusting the ironports self-signed certificate as a root-CA (Meaning any certificates the ironport subsequently signs are trusted) or by having the ironport request a Root-CA certificate from your own organizations root-CA and then rolling out the trust relationship via group policy.

Another awesome Ironport feature and a great way to stop people doing the dodgy on your network.

3 comments:

Say I point my browser to https://mail.google.com. My browser will see a certificate "issued to" "ironport.mycompany.com" instead of "mail.google.com." So, my question is: Even if the certificate issued to "ironport.mycompany.com" is trusted, why won't my browser throw an error because of the mismatch?