The Internet was created in a time when we had main frame computers and used dumb terminals to access remote services. Thus many of the protocol such as HTTP, FTP and TELNET were created with plain-text commands. In those days there was no sense of security, as the networks had closed connections, where it was difficult to tap the communications. In these days, intruders can find many ways to capture data packets as they traverse over the Internet, thus we need newer protocols to protect our information. Unfortunately it is difficult to just change from these old and insecure protocols, which have actually worked well, to new secure ones, so SSL (Secure Socket Layer) and TLS (Transport Layer Security) have been brought in to plug the gap. Overall the work fine, but they do have problems – but let’s leave that for a future blog.
Many people think that encryption just keeps the message secret, but it does much more, including providing authentication and integrity. So SSL and TLS uses encryption to secure the data, and also to authenticate the Web server and provide integrity. It also stops the client and server being replaced by an intruder host. Along with this, the encryption key that is used is a session-based one, which means that if one of the keys are broken then it doesn’t affect other encrypted sessions, as each session has a unique key.
Within networking we normally use a layered model to view our communication (Figure 1). In this IP and TCP have been a core part of most of what goes on, on the Internet. So it’s kinda difficult to them, as they are the workhorse of the communications over the network. Thus a natural place is to shoehorn-in a security layer is between TCP and the Application Layer protocol, as the two where never that integrated. This will secure the data within the Application Layer protocol and the data contents, but will not protect the TCP or IP part. Thus an intruder can still determine the remote address and the ports that someone uses, but they won’t be able to see the URL requested.
With SSL, we change the TCP ports used, so that with HTTP we use 443 for HTTPS (which is HTTP over SSL). Other protocols, such as IMAP and SMTP change their ports too. The application layer protocol, through, stays the same, which makes it easy for the server to support SSL. Initially the client says “Hello”, and the server responds back with its digital certificate, which proves its identity (as long as the client trusts the signer of the certificate, of course). This certificate also contains the public key that the server uses, so the client creates a session key for the private key method that both the client and server want to use, and then will encrypt it with the public key of the server. This will then be sent over, and the server will decrypt it, and determine the session next. Next the client and server can now communicate securely using this session key.
If you want more information:
and I have a demonstration at: