As you are reading this article you will most likely be aware that SSL or Secure Socket Layer is a protocol used to encrypt data between the user’s web browser and the web server that it is communicating with. You will also know that a typical web user will very rarely trust their credit card, private personal or confidential business details without their browser session being protected by SSL and that all important gold padlock at the bottom of the browser status bar. But just what is SSL and why is it so important? This article attempts to explain without going into too much technical depth.
Unencrypted web communication
When a web browser or other web client initiates a normal HTTP session with a web server the information is sent in the form of “packets” of information. If an attacker has access to any of the many routers and networks between your PC and the web server they may be able to carry out what is know as “packet sniffing” (see http://www.securitydocs.com/library/3479 for an in depth explanation of packet sniffing). A computer that has been attacked and compromised or even a malicious insider at an ISP would allow this kind of attack. As these packets are in clear text it is a relatively trivial job for an experienced hacker to collect usernames, passwords, credit card details and business information. They can even inject their own packets into the return transmission, perhaps asking the web user for more information than they would normally divulge. Clearly, a more secure way of transmitting confidential data across what is a potentially insecure medium is needed.
In almost all cases the answer to the problem is encryption, a procedure that has been used for centuries to allow encoded information to be passed from one party to the other without a third party being able to interpret it. The Secure Socket Layer (SSL) was developed by Netscape to allow two machines encrypted, secured communications regardless of the number of network "hops" between them. The Internet Engineering Task Force (IETF) drafted a standard based on Netscape's SSL and the lesser-known Transport Layer Security (TLS). These protocols are supported by nearly every major web browser, web server, and email client.
Initiating a Secure Web Session
Please bear with me whilst I explain in greater detail how your web browser uses SSL to connect to a website securely. The process is initiated with a request from your web browser to a website. For instance you may type in https://www.domain.co.uk. The "s" after http tells your web browser to attempt to initiate a secure communications channel when sending and receiving data from the remote web site. Your browser will connect to the server on the SSL port (tcp/443) and send non-confidential information to the server, such as which cryptographic methods the client supports, SSL version, etc. The server will then respond with its list of supported ciphers, SSL version and other necessary information. Included is a copy of the server's certificate and public key. The certificate is then validated by the client (web browser). If the client validates the certificate, it will generate a secret key to be used during the secured session, encrypt it using the server's public key and then send it to the server. The server will then send a final message back to the client, encrypted with the client's generated secret key, to indicate the handshake has been completed. From this point onwards, all communications within the session will be encrypted using the new "shared" secret key. As a web user, your indication that the connection is encrypted usually comes in the form of a locked padlock icon in your web browser's status bar. Note that this key is only used for this session; new sessions will require re-negotiation and in all likelihood, a new shared key.
It can be seen that it is essential to pass the public key to the recipient without it being compromised in transit. Public-key encryption, or "PKE", is used to overcome this issue. In public-key encryption, the web server possesses a private key that is kept secret and known only to the web server. If this key is leaked then the encryption is compromised and the communication is no longer secure. For clients who wish to send encrypted messages to the server, the web server has a public key. The private key cannot be derived from the public key, making the whole system secure. The private key can be used to encrypt messages from the server to the client or decrypt messages encrypted by the client using the public key that the web server sent it.
All this clever encryption is only of any use if you can trust the website that has sent your browser the public key. Private/public keys can be generated in an instant and it would be easy for a hacker, using packet sniffing and claiming to be xyz to generate a private/public key combination, sending the public key to the browser under the guise of a legitimate organisation. What is needed is a method of trust that will enable your web browser to positively identify that the generator of the key belongs to the website URL that is in your browser address bar.
SSL certificates contain information about the individual or organisation that uses them. Certificates provide the individual or organisation's name, location, email address, server name and the dates during which the certificate is valid. However it would still be relatively easy for an organisation to create a certificate with seemingly credible information, regardless of their true identity.
To overcome this, Certificate Authorities (CA) were created. A Certificate Authority is an organisation that is trusted to vouch for whether an individual or Company is who they say they are. In order to certify a certificate, the CA will investigate the identity of the requester and, if satisfied, "sign" the SSL certificate. When the server presents this signed certificate to the client during the SSL handshake, the client will attempt to verify the signature against a list of "known good" signers. Web browsers normally come with lists of CAs that they will implicitly trust to identify hosts. If the authority is not on the list, as with some sites that sign their own certificates, the browser will alert the user that the certificate is not signed by a recognised authority and ask the user if they wish to continue communications with the unverified site. Additionally the web browser will check that the current date falls within the certificate's valid time range and that the host name matches that of the current URL. As a final precaution, the user can verify the information their self by clicking the "lock" icon in the browser window and looking through the certificate details.
As was discussed with regards to public and private keys, the system is based on the difficulty of uncovering the private key used to encrypt and decrypt messages. The size of that key affects the amount of time required to break the encryption. Public-key encryption strength is expressed in terms of "bits", as in the common standard of "128-bit encryption". What this means is that the key used contains 128 bits, each "bit" being either a "1" or a "0". Ignoring the possibility of a lucky guess, a brute-force method of uncovering a 128-bit key would require testing a worst case of 2128 combinations of ones and zeroes. To get an idea of the sheer size of this number, imagine the number three followed by thirty-eight zeroes! Even if you had a modern 4GHz machine capable of trying one combination per cycle dedicated to the task of cracking a key of this strength, it would take you roughly 2.6x1021 years (2.6 sextillion!) to try every combination. However, if you take the bare minimum encryption level supported by most browsers (excepting no encryption), 40-bit or 240 combinations, the same machine could try every key within a matter of minutes. Of course, these theoretical numbers do not take into account the normal overhead of running an operating system and other user processes that would reduce the amount of cycles dedicated to cracking the key. What they do show is the tremendous difference in effort between the 128-bit and 40-bit strengths. Therefore, to obtain the best encryption supported by most browsers and servers, you'd definitely want the sites you visit securely (and your browser) to support 128-bit encryption.