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.
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:
Other terms related to this technology include:
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.
Depending on the client and the web server configuration, there may be additional steps (such as authentication / verification) involved.
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.
An example of this would be
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.
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.
You can check these yourself by clicking on the certificate and examining the various fields (Open Windows Certificate Manager with Start | Run | certmgr.msc).
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:
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.
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.
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.
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.
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.
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
Download the free 30 day trial, or schedule a demo and we'll show you how it works!
How to Enable and Disable SSL / TLS Versions on Forefront TMG
How To Secure The Fastvue Sophos Reporter Web Site