When you go to most shopping sites, you get that little padlock in your browser to tell you that your session is, somehow, secure. But what does that mean?
What is SSL?
Secure Sockets Layer (SSL) provides two different services: encryption (preventing the traffic from being read in transit) and authentication (verifying that the site is who they claim to be). Although the term most commonly associated with SSL (“certificate”) refers only to authentication, people often see that as being synonymous with encryption instead. I’m going to explain why (and summarise how) it does both.
Why do we need them?
First, imagine the scenarios which SSL is intended to protect against. Let’s say there’s a user, Alice, who wants to buy a wig from Bob’s wig store. The most obvious risk is if an attacker, Eve, can somehow directly receive the traffic, e.g. through a poorly secured wifi access point. I’m going to call that scenario 1. The other (less common) risk is if Alice’s connection to Bob runs though one of Eve’s computers (because she controls one of the routers involved, or has provided false DNS records to Alice, for example), allowing Eve to alter the content arbitrarily. That’s scenario 2.
In scenario 1, the risk is that when Alice sends Bob her credit card details to buy a wig, Eve will note them down and use them to steal money. That’s bad for Alice, and even for Bob (who will probably be blamed). In scenario 2, Eve can still steal the card number, but she can also perform a more subtle attack, for example changing Alice’s request to deliver to Eve’s address and sending Alice back a page which says that the transaction failed. In that case, Alice and Bob will have every reason to blame each other.
So, the first thing to do is to stop Eve getting the card number – and that means encryption. Encrypted data is roughly analogous to a series of combination-locked boxes, of which Alice and Bob somehow both know the combination (and nobody else does). Alice can send boxes to Bob (and vice versa), while Eve can do nothing without knowing the combination. That would perfectly solve the problem, except that Alice and Bob still need a way to agree on a combination to use.
Since Alice and Bob don’t already have a mutually-known combination to use at the start, they have to use a slightly different approach called public key encryption. The basic idea is that there is a way for anyone to encrypt data that only Bob can decrypt. In the “boxes” metaphor, this would be latch-lock boxes that Bob gives to everyone he sees: you don’t need to know the combination to lock it, only to unlock it. That’s absolutely perfect for scenario 1: Bob sends Alice a latch-lock box; Alice sends it back with a suggested combination written on a piece of paper inside. This is roughly the security level you get with a self-signed certificate.
Unfortunately, scenario 2 is still a problem: Alice gets Eve’s latch-lock box, and Bob gets Eve’s suggested combination, making it no more secure than if no encryption has been used at all. This is where authentication comes in: Alice and Bob need to know they’re talking directly to each other.
For this, Bob makes a CSR (metaphorically a label saying “this is Bob’s lockbox”, firmly attached to each lockbox), and he gets someone they both trust, Charlie, to sign it (making a complete certificate). When Alice receives the lockbox, she knows that it’s Bob’s (or isn’t) based on whether Charlie has signed it as being so; Bob still doesn’t know he’s talking to Alice, but since Eve never knows Alice’s suggested combination, Alice will know that something is wrong when she doesn’t get a lockbox back which she can open with her combination. So, finally, Alice and Bob can be assured that they’re communicating in secret.
In terms of the practical implementation, Alice has already got knowledge of the Certification Authority (Charlie) because it came on her computer when she bought it, and what the certificate says is that the public key it contains is genuinely from the web site address that appears in her address bar.
Mixed Content Warnings
If you’ve built an SSL site before, you will probably have encountered this. If the browser loads some content over SSL, but loads some content unencrypted, it no longer knows whether all the content that the user perceives as secure actually is, and so issues a hard-to-ignore warning – this even extends to things like CSS (which can hide some text and add some of its own), so be sure that you don’t use full URLs for src= and href= if you’re running a site that you want to work on both HTTP and HTTPS.
Subscribe via 
Follow on 
