The online economy will be worth $4.2 trillion by 2016. That’s an awful lot of money sloshing around the world over wires and through the air. The criminal market for user credentials and credit card numbers is enormous. For the online economy to work, online retailers and site owners need a way to protect data from prying eyes and verify their identity. SSL certificates are by far the most popular way of achieving both.
Imagine you are a shopper browsing an eCommerce website. You want to make a purchase, but before you do, you need to know that the store you are browsing are who they say they are — otherwise you might be sending credit card details to a criminal. You also need to be sure that no one else is looking at this data as it goes over the Internet.
When your browser connects to the store using the “https” protocol, the store responds by sending back an SSL certificate, a small file that contains information digitally signed by a certificate authority. Certificate authorities can be thought of as repositories of trust. It’s not possible for your browser to hold the information necessary to verify the identity of every domain on the Internet: there are millions. Instead your browser trusts a small number of certificate authorities that sign SSL certificates with a private key.
I don’t want to go too deeply into the complexities of public key cryptography in this article, but it’s enough to understand that keys come in two parts: public and private. Only the certificate authorities know the private key, but your browser knows the public key and can use it to verify that a certificate has been signed with the authority’s private key.
When your browser receives a properly signed certificate, it knows that it can trust the identity of the server. This is why you’ll sometimes get a warning from your browser that a site may not be who they claim to be. Usually it’s because someone has forgotten to renew their certificate and the browser can no longer trust that the certificate authority has vouched for them.
Once the browser has confirmed the identity of the server, a key is exchanged, usually encrypted by the public key on the certificate, which only the holder of the matching private key can decrypt. Both the browser and then perform some complex mathematical operations on the key to generate session keys. The session keys are then used to encrypt all of the information flowing between the server and the browser.
In this way, both ends of the connection can be sure that no one sitting between the browser and the server can read the contents of their communication; they can tell how much data is being sent and the IP of the browser and the server, but none of the details of the communication.
You might have spotted a potential weakness in the system: What if the certificate authorities don’t do their job of verifying identities properly or their private keys are leaked? If either of these things happen — as they have on occasion — the communication can no longer be guaranteed secure. While in the past there have been several instances of compromised certificate authorities, they are usually removed from the system very quickly: browser developers can send updates that stops the browser from trusting them.
In reality, the mathematics behind public key cryptography and the TLS/SSL system is complex, and for simplicity’s sake I’ve left out several stages, but hopefully this nutshell explanation is enough to give you a good understanding of how SSL certificates work to protect your users and their data from the prying eyes of cybercriminals.