What everyone should know about HTTPS, SSL, TLS and Certificates

Growing concerns about Internet security spurred the development of secure encrypted protocols to deliver web content.  The Secure Sockets Layer Protocol was developed and released by Netscape in 1994, 19 years ago.  SSL and its superseding technology Transport Layer Security (TLS) is the primary method of securing web based data transfer today.

Amazingly, very few people know anything about it and even fewer people including some IT professionals know how it works. The aim of this articles is to briefly explain the concepts of how this technology works. With your new understanding you should be able to detect and avoid SSL related problems and warnings.

Terminology

There are a few common terms used to refer to different aspects of the technology, but in general they are all interchangeable and refer to an encrypted data session between a client browser and a secure web server:

• HTTPS - Hyper Text Transfer Protocol Secure
• SSL - Secure Sockets Layer
• TLS - Transport Layer Security

Other terms related to this technology include:

• Keys - Text cypher
• Public Key -Known text cypher
• Private Key - unknown text cyper
• Symmetrical or Session Key - Pair of matching keys on either side
• Certificates - Text containers containing cypher and other identifying information

The Basic Steps

Below are the main steps involved in creating and maintaining an encrypted data session. The initial SSL hand shake is covered in steps 1 through 5, and the data transmission that continually reoccurs is covered in steps 6 and 7.

1.  --> Browser requests secure site using HTTPS header
2. <-- Secure web server sends certificate containing its public key
3. --> Browser validates the certificate  with request to validation servers
4. --> Browser uses the public key and creates a symmetric key that will only be valid for that session and sends it to the web server
5. Web server decrypts the symmetric key with it's private key
6. <-- Web server returns data encrypted with the symmetric session key
7. Browser decrypts data using the symmetric session key

Depending on the client and the web server configuration, there may be additional steps (such as authentication / verification) involved.

Deeper dive into the steps

Step 1.  Request secure site

URLs for normal (un-encrypted) web browsing start with http://. When the URL starts with https:// it indicates to the web server that the browser is requesting secure content.

The actual header data for these two are methods contain three parts.

:// <Fully Qualified Domain Name (FQDN)> :

An example of this would be

• http://www.google.com:80
• https://www.google.com:443

The reason most users are not aware of this is because most modern browsers hide the http:// and :80 portions of the URL. For secure URLs, modern browsers usually show the https:// portion but they still  hide the port number portion.

Step 2.  Secure web server sends certificate

Once the web server receives the request that indicates a secure connection is required, it sends its certificate to the client browser.  The certificate contains the following bits of information that will be used in the following step.

• The site name to which the certificate is issued to
• The Certificate Authority (CA) that issued the certificate
• The dates for which the certificate is valid.
• Thumbprint
• CRL points

You can check these yourself by clicking on the certificate and examining the various fields (Open Windows Certificate Manager  with Start | Run | certmgr.msc).

Step 3. Browser validates the certificate

Before the browser will accept the certificate and use it to establish the session keys, it validates that the certificate is valid and trusted. To do this:

• It compares the name to which the certificate was issued and checks that it matches the Request and Response header.
• Checks the current date against the certificate validity period dates.
• It uses the Certificate Revocation List (CRL) points to see if the certificate's thumbprint has been revoked or if it is still valid.
• It also checks the local system to see if it trusts the Certificate Authority that issued the certificate.

If any of these validations fail the browser will alert you to it and provide the option to accept the invalid certificate and proceed to the following step. If the certificate is trusted and no alerts appear, a secure padlock indicator appears in the address bar.

There is another category of certificates that are "extra trusted".  These certificates require additional validation steps between the Certificate Authority and the client. These certificates are typically valid for shorter duration and are subject to annual re-evaluation.  You can identify the Extended Validation (EV) certificates by how the browser "Lights Up Green" when it encounters one of these.

Step 4. Browser creates the symmetric key

The browser uses the web server certificate's public key and and creates a unique session key. The session key will only be valid for the duration of the session and is therefore referred to as a session key.

Only the client browser can decrypt the data since it contains the private key that was used  in conjunction with the public key. The browser then send the session key back to the web server. At this point it is called the pre-master secret.

Step 5. Web server decrypts the session key

The web server is in possession of its own private key that can be used to decrypt any message encrypted using its public key. It uses its private key to decrypt the pre-master secret and the session key received from the client browser.

This is then used for all further encryption for the duration of the session. The the same key will now be used at the client and server side as it is a symmetric key pair. The process up to now is known as the SSL handshake.

Step 6. Data is encrypted before sending to the client

The web server now uses the symmetric key to encrypt the data portion of all packets being sent back to the client. It is important to note that the HTTP header information is not encrypted, allowing for correct routing and reporting of the encrypted traffic.

Step 7. The client browser decrypts the response from the web server

The client browser receives the encrypted data from the web server. It uses its session key to decrypt the data and render the content. An important concept to grasp here is that the tunnel is between the client browser and the web server, not the entire client computer. Even if data packets are intercepted on the client with a packet sniffer such as Wire Shark it cannot be decrypted.

Something to think about

With the Web 2.0 and cloud services, more information than ever before is being transmitted over the web. Increasingly, a lot of it is confidential and should not simply be transmitted in clear text.

As consumers we should be vigilant and take note of the SSL status (or lack thereof) before we post sensitive information to a web site.

As IT professionals we have an obligation to ensure that applications we publish over the Internet are secure and encrypted.

Implementing SSL and using proper certificates that do not generate a certificate warning is not difficult or expensive. Secure, validated and encrypted web communication becomes more important everyday.

As a starting point, make sure your TMG Reporter installation is secured by following this guide: How To Secure And Publish the Fastvue TMG Reporter Web Site