Cybersecurity gurus sometimes stumble over what SSL, HTTPS, TLS have in common. Do you know the answer? If you said the “S” then I’ll give you a gold star for being a smartie pants – but that’s not what I have in mind.
It’s all about Digital Certificates. it’s all about trust. Do you have trust issues?
Trust me on this one – you’re about to understand this stuff inside and out. Check this out.
It’s a lazy Sunday morning and you literally have nothing to do. You’re feeling indolent. Your wife is out of town on a business trip, your kids are being watched by your mother-in-law and you have exactly zero calls scheduled today.
This is a rare occasion; it never happens!
As you lie there in bed staring at your ceiling fan, a thought drifts into your mind about your bank account. You suddenly feel a prompting to buy the drone your co-worker mentioned last Friday. You’re a little dubious about your funds but heck you always have the credit card right? After vacillating back and forth on the decision, you end up creatively justifying the purchase. You peel your body of the mattress and enter https://www.bankofamerica.com/ to check your balance.
Do you know what happened behind the scenes when you entered your username and password?
Bank of America has a large collection of databases with the passwords of millions of customers. Hopefully that information isn’t stored in plaintext. Given the spate of data breaches that happened in 2013, any company storing sensitive customer data in plaintext should be publicly vituperated.
Obfuscate that password buddy!
If an attacker hacked into the Bank of America customer database and looked inside the password column, he shouldn’t see things like “password123” or “1234567”.
Passwords should look like gooblygook in databases.
An unscrupulous hacker should see the SHA message digest of the password; not the password itself.
But let’s get real here: password hashes are actually inadequate. Today, anyone can download precomputed tables containing millions of plaintext-to-hash mappings. These are called Rainbow Tables and are extremely easy to find. (just Google the term to see what I mean)
So most organizations try to obfuscate passwords through a technique known as key stretching.
By pushing the hashed password through a HMAC algorithm and then encrypting the digest, companies can make the reverse engineering job of a hacker more onerous. Furthermore, if security administrators interleave a long string of random characters into the password, it’ll make the cracking process exponentially harder. Now imagine what would happen if a prudent admin ran this scrambling process through 1,000 rounds? Cracking the password would become virtually infeasible.
This is exactly what the Password Based Key Deviation Function (PBKDFv2) does.
Companies that use this technology are dead serious about protecting your data. Apple’s FileVault uses it as well as LastPass.com. The idea is that hashing, encrypting and sprinkling in a bunch of random data (called a Salt) combined with running hundreds of iterations over the derived password, will make it nearly impossible for anyone to crack the password.
So let’s say Bank of America is using PBKDFv2.
When you login to the site what happens?
Once upon a time…
Before we can talk about the login process we need to go back. Way back to when Bank of America was just getting started doing business online.
The genesis of your bank’s foray into the information superhighway (does anyone actually call it that anymore? lol) started with a generated public/private keypair. Someone at the bank created this enigmatic pair such that one key locks and the other unlocks.
The keys are mathematical inverses of each other. You can’t use the same key to lock or unlock. One always unlocks and one always locks.
Your bank tucks away the private key but sends the public key to your computer via a digital certificate. That happens when you connect to their HTTPS website. And it’s all automatic.
Then your browser can encrypt your private data using the bank’s public key. Since the Bank of America is the only company with the corresponding private key, only Bank of America can read it.
Perfecto!
But here’s my question:
How does your computer know it’s really connecting to the real Bank of America and not some hacker who created a webpage that looks exactly the same as the real thing?
A mendacious attacker could create a fraudulent certificate claiming to be Bank of America. Then when you encrypt your message, you would unwittingly send it to the attacker who could read all your information. (since he’s the only one with the corresponding private key) Of course, if you scrutinized the certificate you would notice information that belied the real certificate but most people wouldn’t know what to look for, much less where to even find their browser certificates.
By the way, I’ll show you how to find your digital certificates later in this series.
How do we prevent that? How does your browser know if a digital certificate is credible? What exactly is a digital certificate anyway?
The confounding world of Digital Certificates
Back in 2007 I obtained my Certified Information Systems Security Professional certificate (CISSP). The next year I earned my Cisco Certified Networking Professional certificate. (CCNP)
If you came to my house, I could take you to my room and show you a piece of paper that has my name on it, a special certification number from the issuing company, the date the certificate was obtained and the date it expires along with a special seal. My Cisco certificate has the signature of the Cisco CEO.
So if you said, “Hey, do you really know Cisco?” I would show you my certificate.
Then if you said, “Yeah, but how do I know you just didn’t make it up?” I would show you the unique seal and the CEOs signature.
My CCNP certificate authorizes my claim to know Cisco products.
In the same way, computers, VPN gateways and websites can use digital certificates to prove that they are who they say they are.
https://www.bankofamerica.com says it’s the Bank of America. But how do you know it really is the Bank of America? It’s all in the certificate.
If you click the green Bank of America Corporation [US] notification in the omnibar, you’ll see a link titled Certificate Information under the Connection tab.
Under that is the digital certificate.
You can see it was issued by a Certificate Authority called Symantec which was signed by the VeriSign root CA.
Verisign, which is a well-known and reputable root CA, is basically endorsing the cert from Symantec. This is like having a CCNP certificate signed by the CEO of Cisco but it’s actually better that that. Because unlike the Cisco signature, the Verisign signature is mathematically impossible to forge.
So https://www.bankofamerica.com is saying “Hey, I’m the real Bank of America”. But how do you know for sure?
Well you have this little digital certificate that was signed by Symantec. Symantec validated the certificate. And VeriSign gave it’s stamp of approval on the Symantec certificate. It’s a pretty little chain of trust.
So your next question might be:
How do I know a fake Bank of America didn’t just lie and say that it was signed by Verisign? Isn’t it possible for anyone to claim they were signed by a trusted root CA.
That’s a great question.
And I’ll answer it definitively in tomorrow’s post!
See you then.
Connect with Vonnie on Twitter
Pingback: Crypto 201: Public Key Infrastructure (PKI) - Cryptography for smarties (Part 2 of 3) - fixedByVonnie()