SSL is the Secure Sockets Layer protocol that Web browsers and Web servers use to secure the data they exchange with each other. SSL is more formally known as
TLS (Transport Layer Security). The name of the protocol was changed because SSL is a trademark of Netscape Communications Corporation. But a lot of people still call it SSL.
You probably know that SSL is used to secure an
HTTPS connection when you browse to a secure Web site. Most people know that a secure Web connection uses SSL to encrypt all data sent in both directions. This prevents someone who is snooping your network traffic from seeing sensitive information, such as your credit card number. A lesser known benefit of an SSL connection is that your browser
authenticates the Web server so that you can be sure the Web server is who it says it is. You don't want to send your credit card info to a Web site pretending to be Amazon.com, even if it is encrypted during transit. The bad guy still gets your credit card number, and the encryption only serves to prevent different bad guys from stealing it in transit.
Your browser can authenticate a secure Web server because the server sends an SSL
certificate to the browser. That certificate (or "cert" in technical jargon) contains the identity of the server along with a
public key that can be used to encrypt data sent to the server (see
http://en.wikipedia.org/wiki/Public_key_cryptography for more info on how public-key cryptography works). The obvious question is: How can your browser be sure the identity information in the certificate is not fake? That is done using a
digital signature.
A digital signature is a piece of data that someone creates using a digital signature algorithm (see
http://en.wikipedia.org/wiki/Digital_signature for more info). A digital signature is like a fingerprint of some other piece of data (such as an SSL cert). Your Web browser takes the digital signature that comes with the SSL cert and performs some math on the cert and the digital signature. The outcome of that math tells your browser two things:
- Was the content of the cert modified in any way after it was digitally signed?
- Is the identity information in the cert to be trusted?
These two facts can be computed mathematically thanks to the wonders of public-key cryptography (which is beyond the scope of this little blog post to describe). Now you might ask: Why can't a fake Web server simply put a fake digital signature on their fake SSL cert to fool my Web browser into believing the server really is Amazon.com and thus leading me to send them my credit card number?
The answer is that it is mathematically impossible (again thanks to public-key cryptography) to fake a digital signature. The math behind public-key cryptography allows your browser to detect a fake digital signature. Your browser only trusts digital signatures that have been created by a short list of trusted
certificate authorities (CAs) — organizations that make money by digitally signing SSL certificates to vouch that the identity information in a cert is correct. That short list of trusted CAs is built into your browser by the browser vendor, and those CAs obey strict rules guiding how they will digitally sign a Web server's SSL cert.
This combination of encryption and server-authentication has allowed Web-based commerce to flower in the last 15 years. We all know to look for some icon or color change in our browser that tells us "This Web server is who they say they are, and all data exchanged with this server is encrypted." This is the reason you can read your email and buy things on Amazon.com when using your local coffee shop's free WiFi without worrying that your data is being seen by the bad guys. It's perfect.
Or is it? The SSL/TLS protocol has a dirty little secret: Your browser will trust any CA it is configured to trust, and anyone with administrative access to your computer can configure a new trusted CA in your browser without you knowing about it! If someone adds a new (fake) trusted CA to your browser, that person can set up a fake Web site that presents an SSL cert digitally signed by that fake CA, and your browser will validate the fake cert, leading you to believe the site is legitimate when it really isn't. You might give the site your credit card number or some other sensitive data. That's bad.
I know what you're thinking: This can only happen if someone has administrative access to my computer, so I'm safe. This is probably true for your home computer, but consider your work computer. Many people believe that if they use a secure Web server from work to read their personal email or buy something online, then their employer cannot see the content of the Web traffic exchanged with that server. This is
not true!
It is standard these days for employers to run so-called
net nannies, software that watches the content of Web sites browsed by employees. This enables the employer to block unwanted content and to watch for data leaks. This happens so much that there's a name for the category of products that do this monitoring: Data Loss Prevention (
http://en.wikipedia.org/wiki/Data_Loss_Prevention). If your company is running a DLP product, then you might be surprised to learn that it can monitor your SSL-encrypted Web traffic as well as your non-encrypted Web traffic. How is that possible?
Simple. Your company, which has administrative access to your work computer, adds a new (fake) CA to the list of trusted CAs in your Web browser. Then it sets up a server to transparently proxy your outbound HTTPS connections. When your browser connects to a secure Web server outside of the company, the proxy responds in place of the secure server, giving your browser a cert that claims to be from the outside server but which contains the public key of the company-owned proxy server and a digital signature generated by the fake CA operated by your company. Your browser validates the digital signature, because it comes from a trusted CA. Your browser believes it has connected to the outside secure Web server but it is really connected to your company's proxy server. The proxy server then makes its own connection to the external secure Web server and forwards data between the outside server and your browser, monitoring it in the process.
There's a name for this. It's called a
Man-in-the-Middle (MITM) attack (see
http://en.wikipedia.org/wiki/Man-in-the-middle_attack), because the company's proxy server is sitting in the middle of the communication between your browser and the outside Web server. How can you prevent this? The best way is to use the Firefox browser and install the
Certificate Patrol add-on (
https://addons.mozilla.org/en-US/firefox/addon/6415). This add-on watches for changes in the SSL certs received by your browser. If you previously have visited a secure Web server and your company begins intercepting your SSL traffic using a DLP product, you will be alerted that the SSL cert has changed. This add-on does not trust the list of CAs configured into your browser. It simply compares the newly-received cert with the previously-received cert and alerts you if it has changed.
That's great if you know the SSL cert previously received by your browser is legitimate, but what if it's your first day on the job, or you get a new computer from your IT department, or the IT department wipes your hard drive to install a new OS? The Certificate Patrol add-on can't help in that case. Instead, you should manually examine the SSL cert to see if it matches a known-good copy of the cert. Don't visit the secure Web server until you know for certain that the cert you get from inside the company is the same as the cert you get from outside (i.e., from home).
So how do you manually examine the SSL cert of a secure Web server? If you have a Linux machine (or have Cygwin installed on a Windows machine), you can use the
openssl utility like this:
$ echo | openssl s_client -connect mail.google.com:443 2>/dev/null |
sed -ne '/BEGIN/,/END/p'
Simply change
mail.google.com to the hostname of the secure Web server you want to examine. The output of the above command looks like this:
-----BEGIN CERTIFICATE-----
MIIDIjCCAougAwIBAgIQHxn23jXdY6FCkYrVLMCrEjANBgkqhkiG9w0BAQUFADBM
MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg
THRkLjEWMBQGA1UEAxMNVGhhd3RlIFNHQyBDQTAeFw0wOTEyMTgwMDAwMDBaFw0x
MTEyMTgyMzU5NTlaMGkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlh
MRYwFAYDVQQHFA1Nb3VudGFpbiBWaWV3MRMwEQYDVQQKFApHb29nbGUgSW5jMRgw
FgYDVQQDFA9tYWlsLmdvb2dsZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
AoGBANknyBHye+RFyUa2Y3WDsXd+F0GJgDjxRSegPNnoqABL2QfQut7t9CymrNwn
E+wMwaaZF0LmjSfSgRSwS4L6ssXQuyBZYiijlrVh9nbBbUbS/brGDz3RyXeaWDP2
BnYyrVFfKV9u+BKLrebFCDmzQ0OpW5Ed1+PPUd91WY6NgKtTAgMBAAGjgecwgeQw
DAYDVR0TAQH/BAIwADA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnRoYXd0
ZS5jb20vVGhhd3RlU0dDQ0EuY3JsMCgGA1UdJQQhMB8GCCsGAQUFBwMBBggrBgEF
BQcDAgYJYIZIAYb4QgQBMHIGCCsGAQUFBwEBBGYwZDAiBggrBgEFBQcwAYYWaHR0
cDovL29jc3AudGhhd3RlLmNvbTA+BggrBgEFBQcwAoYyaHR0cDovL3d3dy50aGF3
dGUuY29tL3JlcG9zaXRvcnkvVGhhd3RlX1NHQ19DQS5jcnQwDQYJKoZIhvcNAQEF
BQADgYEAicju7fexy+yRP2drx57Tcqo+BElR1CiHNZ1nhPmS9QSZaudDA8jy25IP
VWvjEgaq13Hro0Hg32ZNVK53qcXwjWtnCAReojvNwj6/x1Ciq5B6D7E6eiYDSfXJ
8/a2vR5IbgY89nq+wuHaA6vspH6vNR848xO3z1PQ7BrIjnYQ1A0=
-----END CERTIFICATE-----
That block of apparently random text is the binary SSL cert encoded in base64 form, which allows it to be easily transmitted textual form and visualized by people. If you fetch a cert from outside your company and save it in a file, then you can fetch it again from inside your company and compare them (the Linux
diff utility is the simplest way to do that). If they are byte-for-byte identical, then you know that your company is not intercepting your SSL traffic. If they are different, do not connect to that secure Web server, until you can re-verify the cert from outside. Occasionally, secure Web sites change their SSL certs, so you might see a difference that is not caused by an SSL interceptor.
File this under
What They Never Told Me About the Web.
