What Every Web Developer Needs To Know about SSL

Picture this scenario. You’re online shopping for clothes or a new gadget. You find a great deal on a website you’ve never heard of and don’t hesitate to add the item to your cart. You navigate to the checkout screen. Without a second thought, you input your name, address, phone number, email address, and credit card number. You click Submit.

We’ve all done it hundreds of times, but we rarely stop to think about where that information goes from there. We don’t think about the hackers lurking and dredging for anything they can steal – looking to snatch your identity out from under you and sell your information to advertisers, open credit cards in your name, or make unauthorized purchases that you won’t find out about until a collections agency starts beating down your door.

For this reason, we need a way to know whom we can trust with our personal information. We need a way to know who’s going to take the necessary precautions to keep it out of the hands of ne’er-do-wells and thieves. You might think that you can trust your banking website, Amazon, the Red Cross, or other names you recognize – but on the web, it’s incredibly easy for hackers to impersonate people or organizations. We need a way to know for sure whom it is that we’re dealing with.

Enter Secure Sockets Layer (SSL) and Security Certificates. SSL describes the method that two computers use to connect to each other to create a secure “tunnel”. Security Certificates (also called “keys”) are how your computer, tablet, or phone can validate a server’s identity and encrypt, or scramble, the information that is passed back and forth to prevent eavesdropping. This technology operates behind-the-scenes in your browser or device of choice, and is what allows you to see that reassuring little padlock icon or green verification button. This technology exists to keep your information safe and sound.

So, how does it work?

Establishing Trust on the Internet

 

When we were kids, we learned that the bank, post office and many other organizations are trusted through the guidance of our parents and of society at large. On the Internet there is a similar “trust structure” that helps to guide us as consumers.

There are dozens of companies who form the core of Trust, and they are called Root Certificate Authorities. 90% of Security Certificates are generated and digitally “signed” by: Symantec (who now owns Thawte, Geotrust, and VeriSign’s security group), Comodo, GoDaddy and GlobalSign. Some of these names should sound familiar to you.

It is these international companies that generate and digitally sign Security Certificates for your bank, Google Mail, Facebook, and your favorite shopping sites. Even Google, Facebook and Wikipedia, some of the sites we trust the most, are verified by other, older and more reputable organizations. Google, for example, actually operates as an “intermediate” certificate authority, but only under the auspices of GeoTrust and Equifax’s higher-level certificates.

This trust dependency means a couple of things. First, it’s not a walk-in-the-park to become or to remain a certificate authority. A certificate authority is subject to constant auditing and considerable public scrutiny. But, secondly, and more importantly, sites aren’t simply allowed the right to be trusted on the Internet just because they are popular, without following the same process as every other site.

As high-and-mighty as all this sounds, though, you can actually see a list of these Root Certificates running on your own computer by opening Keychain Access on your Mac, or, if you’re using Windows, by running certmgr.msc. Every operating system, whether on a smartphone, tablet, laptop or desktop, has it’s own copies of dozens of trusted Root Certificates.

If you own a website and want people to trust you, the process for acquiring a piece of this digital Trust is hardly grandiose. Depending on your budget and business requirements, it’s as easy as applying for a Security Certificate, forking over $20 or $200 per year, then sending in a Certificate Signing Request (CSR) file from the web server; after which the certificate (or, “public key”) is e-mailed back to you. The process takes just a couple of hours and requires only a few quick verifications.

How Does a Browser Verify Trust?

 

So now we get to the guts of SSL, which involves two files. One is the CSR file that you send to the certificate authority. The other is the “private key”, which under no circumstances do you make publicly available.

With both the private key that your server generated, and the public key that the certificate authority sent back, you now have what’s called an “asymmetric key pair”! Woohoo! That sounds great! But let’s not stop here. Let’s keep digging to see exactly how the key pair works together to make your credit card number look like a jumbled mess to a hacker.

It may be helpful to use a simple illustration of a lockbox that somebody sends to a friend. Let’s say that Person A writes a secret (such as your credit card number) on a piece of parchment, places it in this lockbox, affixes a padlock onto the latch, and sends it on to Person B. In order for Person B to be able to open the lockbox, he or she would need a copy of Person A’s key, right? So, you say, why not just have Person A send a copy of the key to Person B?

The problem is that the key is very valuable and the shipping system (the public Internet) isn’t at all like the United States Postal Service. Any Random Joe can intercept the key copy while it’s in transit to person B. They could make a copy of it for themselves and you’d never know they had it. But, far worse, this third person could open your lockbox, read what’s inside, and even change the contents!

This doesn’t seem to be a good solution, since we have to assume that the Internet can’t be trusted in general, with Random Joe lurking about. But, if it were possible for Person B to have a key that could open the lockbox, this might work.

Using our fancy-dancy algorithms, there is a way to lock, or encrypt, a package of data in such a way that the same key (this is the “public key”) cannot unlock it again. Only the complementary key (the “private key”) can unlock it. And, this private key is the one that we are keeping safe on our server. You did keep it safe right?!?

This is precisely how symmetric encryption works. An exact replica of the key that was used to lock the box, or package, is used to also unlock the same package – so one key locks while the other unlocks.

And that is how SSL begins. The process looks like this:

1. Your browser asks to connect with an SSL secure page and the web server sends back it’s public key
2. Your browser uses the server’s public key to “lock” and send back some data (i.e. “encrypt” it) which the web server can unlock with its private key. This data just happens to be a new key -- a symmetric key
3. The web server says it's ready to start using symmetric encryption
4. Both your computer and the server now have a copy of the same key that they can use to lock and unlock data

So, to recap: when an SSL connection is begun, asymmetric encryption is utilized to set up a symmetric encryption connection, which is used for the rest of the digital conversation. At this point, all of your personal information is kept safe from prying eyes. Beautiful, isn’t it?

Putting Our Trust in Trust

 

Web developers need to understand the ins and outs and all the complexities of SSL, as they'll be the ones generating Certificate Signing Requests and installing the certificates they receive in return. But it’s just as important for the rest of us, as daily web users, to have a working knowledge of how security works on the Internet.

We’ve established what’s at stake every time you choose to share information on the web. Without this elaborate network of security features, your money, or even your identity, would be at risk every time you logged on. Despite the risks – and we’ve all heard the horror stories – most people still tend to ignore warnings generated by their browser when it can’t validate the identity of a website. Tech-savvy users are the worst offenders, as they’ve been around long enough to have been bombarded by more than their fair share of benign security warnings.

It’s clear that there’s a disconnect. Users know enough to know that the Internet can be a dangerous place but they don’t know enough about the warning signs. They often don’t know how to spot red flags and they don’t know that they should heed browser alerts. For online consumers, gamers, and the like, hopefully this baseline of knowledge will help them make informed decisions about your online browsing habits.

In the meantime, we as developers should think about how we can best communicate our sites’ level of trust to users who may not know what to look for, and how we can more effectively warn them when they’re at risk.