In Learning Tree’s System and Network Security Introduction course we talk about how digital signatures work, and how they are used to create x509.v3 digital certificates, which in turn are used to secure your connections to web servers.
The connections are secured in two ways. First, by verifying the identity of the server to which you connected. Is that really Amazon’s server to which I am about to send my credit card information? Secondly, by negotiating a session key to encrypt the following communication, so someone sniffing packets can’t read my credit card number as it flashes past.
The first of those is much more important. The Russian mob won’t try to intercept just one connection to steal your credit card information, that’s too much work for the amount of gain. They would prefer to build a convincing replica of an on-line commerce site and trick hundreds of thousands of people into sending over their sensitive data.
Server identity masquerading is far more lucrative than brute-force cryptanalysis!
Unfortunately for all of us, questionable behavior by some root CAs makes Internet server identity much less trustworthy. Let’s see what’s going on.
Bring up the Preferences in Firefox, select the Advanced panel and the Encryption tab. Then click View Certificates. In the new window, select the Authorities tab.
These are the authorities your browser trusts on your behalf. “Good enough for one of them is good enough for me.” The browser has each authority’s public key on its keyring, it believes that it is a valid copy of that public key, and it trusts that if the authority is vouching for the identity of some third party, you should also believe the identity.
The way that this works is that you connect to a web site using the HTTPS protocol and that server sends over its digital certificate. That’s a multipart data structure including the web site’s identity by domain name (or names) and human-friendly organization name, what claims to be the web site’s public key, start and end dates of certificate validity, and some other odds and ends, with all of that wrapped inside a digital signature from one of these authorities. Your browser can then verify that yes, according to a certain one of its trusted authorities, that really is the public key for a certain organization.
That’s all you really know, you don’t yet know who you have really connected to. Digital certificates are public, anyone could have connected to the real server to get a copy, put it on their server, and tricked your browser (perhaps through DNS poisoning) into viewing the bogus server.
So, the browser’s next step is to issue a challenge — if you’re really who you say you are then you have the corresponding private key. Use it to encrypt this random challenge and send the result back to me. I decrypt that with what I now know to be the real public key and get my challenge, then you’re really the legitimate server and we can set up encryption keys and continue.
The cryptography is pretty straightforward. It’s the human or corporate trust where things get messy. Check back next week for the big risks many people are overlooking!