So let’s trace what happens when the certificate arrives at your computer. I
n the last post we talked about why it’s mathematically infeasible for someone to forge a root certificate signature. I also showed you how to view the trusted certificate authorities on your Mac and PC. Now we’re going to look at what happens when the certificate arrives and why you might receive an invalid certificate. We’ll finish up with a little talk about malware and key escrow services.
Let’s jump in this thing!
What happens when the certificate arrives
After entering https://www.bankofamerica.com, your browser pulls down the bank’s digital certificate and quickly ask three questions before assuming the certificate is good:
- Is the certificate signed by a Certificate Authority that I trust?
- Does the URL in the certificate match the URL in the location bar of the browser?
- Is the certificate valid? In other words, it’s not expired right? I need to check the validity dates.
The most important part of the digital certificate is the banks public key. That’s really the purpose of digital certificates. They are public key carriers.
So now your browser can take your private data, encrypt it with the banks public key and send it privately over to the bank. This is the asymmetric part of the process. Then it can kick over to symmetric encryption to generate a shared session key that you’ll use for bulk data encryption.
Looking at the certificates
In your browser, there’s a section called Trusted Root Certificates. If you have the public key of an issuer that matches the trusted CA of the bank then you can use the banks certificate for asymmetric encryption.
You can find them in Chrome by entering chrome://settings/ in the omnibar, scrolling down to Show advanced settings… and click Manage Certificates under the HTTPS/SSL section.
The fastest way to manage the certs trusted by all your browsers in Windows is to mash the Windows key and type:
In a large PKI environment you would typically have multiple tiers of CAs.
At the top is the grandpappy of them all; the root CA. The root signs the certificates used by an intermedia CA’s. (the child CA’s) So when the bank enrolls with an intermediate CA and receives the CA’s public key. But how does the bank know to trust this CA? Well, it can look at the issuer and see if it’s a trusted CA. Basically, the entire system is based on trusted CAs. There’s a hierarchy of trusted CA’s with each CA vouching for the next CA.
If you’re confounded at this point – that’s okay. This whole thing confounded me the first time I started reading about it but it’ll make sense with time.
The point here is that the CA’s live in an hierarchy of trust and your browser needs the certificates of both the intermediate and root CA’s installed on it. This stuff is installed by default so you don’t have to worry about it. I’m just showing you what happens behind the curtains.
Checking out invalid certificates
What would happen if you tried to browse to the HTTPS version of the Bank of America’s IP address.
You’ll get an invalid certificate error.
But why is this?
If you ping bankofamerica.com you’ll see the public IP address of 184.108.40.206 does indeed belong to bankofamerica.com.
The problem is that 17220.127.116.11 doesn’t match the URL in the digital certificate. The digital certificate URL is bankofamerica.com and the browser URL is the IP address. No match.
So your browser is warning you about a CERT_COMMON_NAME_INVALID error. If you ever see something like this after clicking a link or visiting the domain name of your favorite site then you should definately not continue. Your browser is telling you something is wrong with the cert so you shouldn’t use it.
Sometimes the browser is right!
Malware is bad but I think some of the most insidious malware is the kind that tricks your browser into trusting an untrusted root certificate. The SuperFish scare earlier this year is a prime example of what can happen when your browser trusts an untrusted certificate.
Here’s the scenario:
Let’s say you download some software on the net but during the installation process fail to see the sneaky opt-in offer bundled in the installation wizard. Most people instinctively click Next through the installation process and don’t take the time to actually read what they just agreed to. So some unsavory software vendors have partnered with free software companies to set the buttons to default to installing crapware (and some of it is malware)
So what happens if the malware installs a trusted CA in your browser and then you’re redirected to a “trusted site” like https://www.bankoamerica.com? Notice the “f” in the domain name is missing.
A duplicitous hacker could easily setup a web site that resembles the real Bank of America website with a domain name that looks legit; however, the public key in the digital certificate matches the “malware” trusted root certificate installed on your browser. So your browser would have no problem using the attackers public key to encrypt traffic before sending it to the bad guy’s server. When the fake website receives the cert, the attacker would decrypt the file and ruin your life.
The sad part is that you would have no idea that something went awry. Your browser would still show you’re connected via HTTPS, and the little pad lock in the status bar would still show up locked.
Your data would still be encrypted! The problem is that it would be encrypted with the attackers public key! That’s the issue.
The best way to guard against this sort of thing is to keep your antivirus software updated and running. Also slow down whenever you install anything on your computer. Take the time to read the screen before clicking next. I can’t tell you how many times I’ve almost been duped into installing a potentially unwanted program because I was in a rush.
Before we finish up I want to talk about one more important topic: Key Escrow.
Let’s say you have an employee in the finance department who was recently terminated. Unfortunately, right before he got canned he destroyed the private key and used his public key to encrypt the balance sheets, statement of cash flows and income statements. He basically tried to sabotage the company before getting fired.
So without the private key it’s virtually impossible to get that information back.
This is why most companies use a third party entity to maintain a copy of the private keys. Then you could authenticate yourself to the key escrow company and then receive the backup private key that would allow you to decrypt the financial data your disgruntled employee tried to lock out.
It’s usually a prudent idea to use a key escrow service. It can really be a life saver amid emergencies.
The Bottom Line
That’s PKI in a nutshell. It’s all about trust. Intermediate Certificate Authorities trust the Root Certificate Authority. And companies with a need to encrypt customer data trust the Certificate Authorities that are trusted by your browser. If someone can trick your browser into trusting a bad cert through malware then the entire system breaks down.
That’s why it’s super important to keep your AV software current, run periodic scans and pay attention when installing software on your computer.
I hope this help clear up a few questions you had about this! Thanks for reading.