In a previous report about changing from HTTP to HTTPS, it touched briefly on Single Socket Layer (SSL). In short, SSL and its successor, Transport Layer Security (TLS), are needed to operate securely online.
In this article, let’s take a closer look at answering the question “what is SSL” and also how SSL/TLS protects your sensitive information.
Why Should You Care About SSL/TLS?
Before heading into “How” however, let’s take a look at “Why” you’d want to use SSL/TLS in the first place.
These days, data security is golden. Anyone who’s had his or her identity stolen could tell you that. The key to keeping your information secure is to tuck it away someplace safe where no one else can see it.
Unfortunately, that’s not possible online. When you transfer information online, there’s always some point in the process where both you and your customer lose control the data.
You see, while your customer can secure the device on which your browser runs and you can secure your Web server, the pipes of the online world are out of both of your hands.
Whether it’s the cable company, the phone company or a government-operated undersea cable, your customers’ data will pass through someone else’s hands online and that’s why it needs to be encrypted using SSL/TLS.
Here are some examples of the types of information you can use SSL/TLS to secure online:
- Credit card transactions
- Website logins
- Passing private and personal information back and forth
- Securing your email from snoopers.
Yes, if you conduct business online, SSL/TLS is critical to your continued success. Why? Because:
- Your customers need to feel secure when they do business with you online or they won’t do business with you; and
- You have a responsibility to your customer to protect the sensitive information they’ve chosen to share with you.
Next, let’s take a look at how SSL/TLS works.
Public, Public and Session Keys are the, uh … Key
When you use SSL/TLS to transmit your sensitive data online, your browser and the secured Web server it’s connecting to use two separate keys to set-up a secure connection: a public and a private key. Once the connection is in place, a third type of key, the session key, is used to encrypt and decrypt the information passed back and forth.
Here’s how it works:
- When you connect to a secure sever (e.g. amazon.com), the “handshake” process begins:
- First, the server will pass your browser it’s SSL/TLS certificate as well as it’s public key;
- Your browser will then check the server’s certificate to see if it can trust it using factors such as whether the certificate was issued by a reliable source and if the certificate hasn’t expired.
- If the SSL/TLS can be trusted, your browser will send an acknowledgment back to the server letting it know it’s ready to go. That message will be encrypted using the server’s public key and can only be decrypted using the server’s private key. Included in that acknowledgement is your browser’s public key.
- If the server cannot be trusted, you’ll see a warning within your browser. You can always ignore the warning, but it’s not wise.
- The server then creates the session key. Before sending it to your browser, it encrypts the message using your public key so that only your browser, using its private key, can decrypt it.
- Now that the handshake is over and both partiers have securely received the session key, your browser and the server share a secure connection. Both your browser and the server use the session key to encrypt and decrypt the sensitive data as it’s sent back-and-forth over online.
- Once the session is over, the session key is discarded. Even if you connect one hour later, you’ll need to run through this process from the beginning which will result in a new session key.
All three types of keys consist of long strings of numbers. The longer the string, the more secure the encryption. On the down side, a longer string takes more time to encrypt and decrypt data and puts more strain on both the server’s and your browser’s resources.
This is why session keys exist. A session key is much shorter than both the public and private keys. The result: much faster encryption and decryption but less security.
Wait – less security? Isn’t that bad? Not really.
Session keys only exist for a short time before they’re deleted. And while they’re not as long as the other two types of keys, they are secure enough to prevent hacking during the short time that the connection between your browser and the secure server exists.
Both the public and private keys are created using one of three encryption algorithms.
We’re not going to get too deep here, you literally need a math degree (maybe several) to understand encryption algorithms completely however, it’s handy to know the basics when it comes time to choose the type that your own website sill use.
The three primary algorithms are:
- RSA – named after its creators (Ron Rivest, Adi Shamir, and Leonard Adlema), RSA has been around since 1977. RSA creates keys by using two random prime numbers in a series of calculations. Learn more…
- Digital Signature Algorithm (DSA) – created by the National Security Agency (NSA), DSA creates keys using a two-step process that uses a “crptographic hash function” in a series of calculations. Learn more…
- Elliptic Curve Cryptography (EEC) – EEC creates keys using “the algebraic structure of elliptical curves” in a complex series of calculations. Learn More…
Which Encryption Algorithm Should You Choose?
Math aside, which is the best encryption algorithm to use?
Currently, ECC seems to be coming in on top. Thanks to the math, keys created with the ECC algorithm are shorter while still being as secure as much longer keys. Yes, ECC breaks the “size matters” rule making it ideal for secure connection on less powerful devices such a your mobile phone or tablet.
The best approach may be a hybrid one, where your server can accept all three types of algorithms so it can handle whatever is thrown at it. The two downsides of this approach can be:
- The server uses more resources handling RSA, DSA and ECC as opposed to only ECC; and
- Your SSL/TLS certificate provider may charge you more. Look around however, there are very creditable providers who do not charge extra for using all three.
Why is TLS Still Being Called SSL?
As we mentioned at the top of this post, TLS is the successor of SSL. While SSL is still in use, TLS is a more refined solution and plugs many of the security holes that plagued SSL.
Most hosting companies and SSL/TLS certificate providers still use the term “SSL certificate” instead of “TLS Certificate”.
Be clear however, the better hosting and certificate providers are indeed using TLS certificates – they just didn’t want to change the name ’cause it would confuse their customers.
Single Socket Layer (SSL), and its successor, Transport Layer Security (TLS), are needed to operate securely online. Using long strings of numbers called, “Keys”, SSL/TLS enables connections where both your and your customer’s information is encrypted before it’s sent and decrypted when it arrives.
Bottom line: if you conduct business online, SSL/TLS is critical to your continued success because it builds trust while protecting both you and your customers.
Security Photo via Shutterstock
Online businesses today have to be secure and this is how you do it. Get on board people.
I’ll be honest. I’ve been seeing SSL a lot but I have not bothered to know what it is. Thanks to this, I now know what it means.
This explanation is bit wrong. Server never creates a session key. Sever certificate is validated by browser and then browser generate a session key which is encrypted by server’s public key and forwarded to server. Once key is shared between server and client, message flow starts.
Does every browser(client) has public/private key pair? Moreover its always client who authenticate the server and client itself gets authenticated by its username/passcode.
How safe is SSL/TLS when it is included in an online tool for e-commerce – like Weebly.com? As I understand it the key is open to the staff in the company providing the services?
This is really helpful. Thanks for the clear explanations! (Note: I rarely leave comments online. That’s how much I needed this article to help me understand SSL/TSL!)