Skip navigation
BLOG  |  FEBRUARY, 2009

What is SSL?

February 13, 2009 at 11:00 am
by Nolan

SSL (or secure sockets layer) is a way for a user to verify two things about a server they are trying to contact for requesting a web page. The first is that they are communicating with the exact server they are expecting to be communicating with, and secondly, that no one is listening in on this communication. SSL is essential for logins, transporting delicate information, as well guaranteeing the correct sender and receiver.

When should a website use SSL?

Basically, whenever you are transmitting something you wouldn't want a casual observer to view. If you work in an office building, a transaction may go through 2-3 hops before it leaves your building, and then it goes to out the local branch of your ISP, and further up through the various conduits (tubes, if you will) of the Internet, until your packets find the server it's aiming for. A traceroute from where I'm typing this post at work to "google.com" visits 10 different servers before getting to the Google server. If you are transmitting vital information unsecured, these are 10 different spots where someone could read your traffic. If you are using high-grade SSL, the snoop will see a stream of seemingly random bits, and even if he gets the entire conversation saved, it would take about 1000 times the age of the universe to brute-force attack the key. Obviously, there are better methods than brute forcing, but with a large enough key, you are good for several years. As of now, high-grade SSL is effectively unbreakable.

Several industries are required by law to use some sort of SSL. Bank account access must be secured, as well as most health care operations. Any transportation of credit card information must be secured. Most major webmail clients allow you to access them via HTTPS. Even Wordpress will allow you to switch on HTTPS to access its admin section. My suggestion usually is if you are transporting anything of value over the Internet, mainly username and passwords for any important business, an SSL key is recommended.

How do I get an SSL certificate?

If you are hosting a site with us, just ask us and we'll set you up. If not, Verisign and Geo Trust are two good options. Even registrars like Go Daddy allow you to buy SSL certificates from them.

With an SSL certificate, you will want to make sure it is signed by a recognized certificate authority. Since anyone can make an SSL certificate, there is no inherent trust created, since you can't tell the difference between a certificate signed by one of the trusted authorities, or some malicious entity. The trust is generated when you have one of the major authorities verify who you say you are. Browsers come pre-installed with these major authorities' root certificates so you can check the authority's signature on the SSL certificate. This is basically a "trust by association" model. You trust Company A, and Company A says Online Store B is trustworthy, therefore, you are able to trust Online Store B. A non-trusted SSL certificate will give you an error in the browser, alerting you to the possibility that the certificate has not been verified by one of the big certificate authorities.

How does SSL work?

 


This is a fairly technical explanation, so if you don't have any interest in the ins-and-outs of SSL, you can skip this section with the take away that SSL is an extremely secure and a neat way for browsers and servers to setup secure channels.

With that said, I'll commence with the explanation.

When a browser makes an HTTPS request, the browser first does an DNS lookup on the hostname to get the IP address. The browser makes a connection to the server at this IP address on port 443 (by default) to start setting up the secure connection. The server replies with its public SSL certificate, which the browser will then verify, checking its signature against the pre-installed certificate authority keys. This certificate authority's signature gives you faith that the entity you are talking to is whom you expect it to be. The SSL certificate from the server contains information such as what hostname the certificate was built for and how long the certificate is good for. It may also contain other information about the business, such as contact information, but this is not required. This step is where the browser will show SSL errors to the user, such as the hostname mismatch or certificate expiration. The most common error that people see is the hostname mismatch. If you typed in "https://www.example.com" and the SSL certificate was built for just "example.com", you'll see the mismatch notice.

The data is transmitted encrypted using symmetric key cryptography. Symmetric key cryptography involves the sender and receiver (in this case, the browser and the server) both having the same key which is then used to both encrypt and decrypt a message. The advantage of this type of protocol is that encryption and decryption are very fast while still being incredibly secure. The downside of this is the issue of how to get the key from the client to the browser without anyone in the middle stealing it. This is where another kind of cryptography, public key cryptography comes in.

Public-key cryptography consists of the message receiver having two keys, one being public and the other being private. To send an encrypted message, the sender uses the receiver's public key to encrypt the message. To decrypt this message, the receiver uses the private key against the message. The public key is available for anyone to use, but the private key should be never be shared with anyone, because if this key gets out, then any messages encrypted with the public key can be decrypted by anyone possessing the private key. A good analogy for this type of cryptography is to think of it like a mailbox. Anyone is allowed to drop a letter in, but only the owner of the mailbox has the key to unlock it and get the letters out.

So after the browser makes its request to begin the secure transaction, the server will reply with its SSL certificate, which contains its public key. After the browser checks out the authenticity of the certificate, it will generate a brand-new, temporary symmetric key. The browser will encrypt this new key with the SSL certificate's public key, and send it back. Since only the server is able to decrypt this message and get the symmetric key out, the symmetric key has been safely transported from the browser to the server, with no one being able to snoop on it while in transit. From then on, the browser and client will do all of its encryption and decryption with this symmetric key, due to its speed advantage mentioned earlier. Thus, a relatively fast and secure channel has been created between the server and browser.

To sum up, here's a quick rundown of the full SSL transaction:
  1. The client requests an HTTPS URL.
  2. The server replies with its public certificate.
  3. The browser will verify the authenticity of this certificate. If it's not valid in some way, the browser will show the user the problem(s) with the SSL certificate and let them decide what to do.
  4. If everything checks out from step 3, the client generates a brand-new symmetric key, encrypts it with the server's public key from the certificate, and sends it back.
  5. The server decrypts this encrypted key with its private key and sends back a message saying that the connection has been made. This message is also encrypted with the symmetric key.
  6. If the browser can decrypt this message, then a secure channel has been created and communication can continue with everything being encrypted with the new symmetric key.
  7. At the end of the session, the symmetric key is destroyed.

This protocol completes the two goals of SSL: secure communication and guaranteed authentication.

The cool thing about the SSL protocol is that the secure channel is created before anything is transferred, even the URL itself. That means if you request "https://www.example.com/some_secret_resource" the browser does a DNS lookup of "www.example.com", goes through the above steps, and after the secure channel has been created, then the full URL is sent to the server. The DNS lookup, if it doesn't come out of the client's DNS cache, will be the only way to verify what server the user is trying to contact. Someone on the outside can tell the client is trying to contact a certain IP address and see the encrypted traffic, but that's basically the sum total of an observer's view of the transaction.

--

In summary, if you don't want an outsider to see what you are transmitting between the browser and the server, an SSL certificate is a simple way to get a high-level of privacy and security.






Comments