Thursday, May 20, 2010

Take the Chinese Government Out of Firefox

If you use the Firefox Web browser, you are unwittingly granting the Chinese government the ability to make your browser validate the identity of any Web site controlled by that government. How is this possible?

When a Web browser visits a secure Web site, it validates the site's identity by checking the digital signature on the SSL/TLS certificate presented by that Web site. Those digital signatures are generated by Certificate Authorities (CAs) which are trusted implicitly by every Web browser. A company that operates a secure Web site, such as Amazon.com, wants your browser to validate the identity of their site, so that customers can trust that their credit card info is being sent to the real Amazon.com instead of a site that is pretending to be Amazon.com. To do this, they pay a Certificate Authority to verify their identity and issue a digital signature on their site's SSL/TLS certificate. That digital signature is how a CA vouches for the identity of a secure Web site.

We trust Certificate Authorities never to issue digital signatures for fake Web sites. We believe they won't do that, because if a CA loses its trustworthy reputation, it loses money. Your Web browser is created to automatically trust many different CAs. How many? Well, it might surprise you, but it's hundreds of CAs — from all over the world. And one of them is the Chinese state Network Information Center, known as CNNIC.

If you use Firefox, you can see the list of trusted CAs by choosing Options from the Tools menu, then select the Advanced tab, then the Encryption tab, and click on View Certificates. This will open the Certificate Manager dialog. Click on the Authorities tab. Scroll down to the entry for CNNIC ROOT: It should look like this:

CLICK IMAGE TO SEE A LARGER VERSION

Select the CNNIC ROOT entry and click on the Edit button. This opens the Trust Settings dialog for that CA, which should look like this:

CLICK IMAGE TO SEE A LARGER VERSION

Those checkboxes tell your browser to trust the CNNIC Certificate Authority to identify Web sites, mail users, and software makers. Uncheck all of the checkboxes and click OK on each dialog.

Now your browser refuses to trust the Certificate Authority operated by the Chinese government.

Tuesday, May 18, 2010

SSL's Dirty Little Secret

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:
  1. Was the content of the cert modified in any way after it was digitally signed?
  2. 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.

Thursday, May 13, 2010

Prevent Web Sites from Accessing Your Facebook Info

It's all well and good to configure your Facebook privacy settings to limit what other Facebook users can see of your personal info, but Facebook also allows other Web sites to access your account info if you are logged into Facebook when you visit the other site. Yes, you can configure Facebook not to allow this, but there is no guarantee that Facebook will always allow you to block other sites from accessing your profile, so you need to take matters into your own hands.

You can use Firefox's Adblock Plus add-on (https://addons.mozilla.org/en-US/firefox/addon/1865) to prevent any other Web site from talking to Facebook when you visit that site. Just install Adblock Plus and then add the following filters:

||facebook.com/*$domain=~facebook.com|~facebook.net|~fbcdn.com|~fbcdn.net
||facebook.net/*$domain=~facebook.com|~facebook.net|~fbcdn.com|~fbcdn.net
||fbcdn.com/*$domain=~facebook.com|~facebook.net|~fbcdn.com|~fbcdn.net
||fbcdn.net/*$domain=~facebook.com|~facebook.net|~fbcdn.com|~fbcdn.net


Enter them exactly as shown, including the vertical bars (|), asterisks (*), dollar signs ($), equal signs (=), and tilde (~) characters. Don't add any spaces either. This screenshot shows what the rules should look like after you've added them to Adblock Plus:

CLICK IMAGE TO SEE A LARGER VERSION

How does this work? When you visit a site such as http://cnn.com/, the CNN Web server sends you a page that might contain code that tells your browser to interact with Facebook. That allows the CNN Web site to access your Facebook profile (and even change it). The above filters tell Firefox never to allow any site other than Facebook's four sites (facebook.com, facebook.net, fbcdn.com, and fbcdn.net) to access Facebook. Thus, Facebook continues to work perfectly, but other sites don't get to talk to Facebook at all.

This has nothing to do with blocking ads. Adblock Plus was invented to block ads, but we're using it to block any access to Facebook from other sites.

NOTE: This doesn't eliminate the need to configure your private settings within Facebook, but it stops any secret agreements between Facebook and other companies from allowing those companies to access your Facebook profile.