Quick SSL certification primer |
SSL uses "certificates" to identify https websites. When the website webmaster sets up the site, s/he purchases a certificate from a Certificate Authority (CA). The CA should make the webmaster "prove" that the site is "real" - it would be bad for a CA to sell me a cert alleging that I'm google.com if I'm not actually Google. The reason that it's important for a CA to verify the website is because web browsers "trust" the CA. When a web browser loads the cert for the https website, the cert contains the URL and the certification path - basically, the list of which CA issued the cert. Web browsers come pre-loaded with a list of CAs, and a method to identify that the cert really was issued by that CA. Bottom line: if my web browser trusts a CA, then any cert issued by that CA looks like a valid ID for the website. If a different CA issues a different cert for the same site, it looks equally valid to the web browser - which means that someone doing something sneaky can fool my browser, and fool me. |
How to fake a certificate | |
Wildcard | Use wildcard characters to create SSL certs which are valid for multiple sites. Announced at DefCon in 2009, the vulnerability was quickly patched by many browsers. |
"Lawful Intercept" | There are appliances targeted at law enforcement which can present alternate SSL certs for sites. Governments presumably have the legal means to order Certificate Authorities to generate these look-alike certs - and hopefully will only use them in the course of legal criminal investigations. |
Many Internet users assume that the system is designed in a way that makes everything work. For the most part, they're right. DNS, for example, generally allows web browsers to find a website based on a hierarchy: I don't know where www.google.com is, so my browser asks my DNS server, who doesn't know. Using a technique known as recursion, my DNS server will go ask the root server for the .com name space, who doesn't specifically know, but it tells my server where to find the authoritative server for the google.com domain. My server asks the google.com server where to find www.google.com, gets the response, and tells my web browser. I know I can trust the answer because I know I can trust the DNS .com root server.
Here's the problem: There is no SSL root CA. Given the current political and commercial state of the Internet, there's not likely to be any agreement about establishing a root CA. There is not currently a convenient nor reliable method to check that the certification path for a SSL cert is the "real" path.
The next blog post will cover potential solutions.
No comments:
Post a Comment