SSL is the secure communication protocol of choice for the Internet community. Its ubiquitous presence and availability is built into every web browser. SSL is utilized practically every time that secure websites are accessed. In fact, so widespread is its use that when a security flaw (Heartbleed) was discovered, not in the SSL protocol, but in one implementation of OpenSSL, it was deemed a potential disaster.
SSL is one of the most common protocols in use on the Internet today assuring confidentiality, integrity and authentication. It uses asymmetric keys to encrypt data and digital certificates for authentication through a trusted third party. SSL is commonly implemented as a client-server model, which means the server is responsible for its own authentication through signed certificates and encryption via public and private keys. In most cases, the client does not provide a certificate, as authentication of the host computer is not necessary. A typical SSL implementation is on web servers hosting email, ecommerce, banking, or other services where clients will send and receive confidential information such as passwords, credit card details and social security numbers over the public internet.
So, how does SSL work?
SSL provides the following:
- Privacy – connection through encryption
- Identity authentication – identification through certificates
- Reliability –dependable maintenance of a secure connection through message integrity checking
The Internet Engineering Task Force (IETF) introduced their own version of SSL, called TLS, in order to standardize the protocol for the Internet community. SSL V3 and TLS are very similar and are both commonly referred to simply as SSL.
SSL uses a series of nine messages to authenticate the server to the client. For example, a customer wishes to log on and access their web-based Internet banking server. The customer requests a connection via a web browser using HTTPS and expects that his credentials (username and password) will be securely transported over the public Internet. However, it is also extremely important that the server to which they are connecting is the “real” bank’s server before the customer sends his credentials. From the bank’s perspective, it does not matter where or from what PC, tablet or mobile phone the customer is connecting. All that matters to the bank is that the customer’s personal credentials are in order. Therefore, the customer’s device does not need to have a certificate. Only the bank’s server requires authentication.
So if the client can connect from any browser on any device, how does the server secure the communication messages?
From the client side, every modern browser has built-in SSL support, so no further requirements are necessary from the customer’s perspective. The customer simply accesses the URL of the bank’s website using HTTPS.
On the bank’s web server, some configurations are required. First, the bank needs to acquire a digital certificate from a trusted certificate authority (CA) that will verify the requester’s (the bank in this example) organization details such as address, company name and the owner’s signature. Secondly, the requester (again, the bank in this example) must install and configure the SSL application and data store on the server. Sometimes a server may hold certificates for several virtual websites.
The SSL Handshake
The client always initiates the secure SSL session by navigating to a web page that contains HTTPS as the protocol and the web server responds. Therefore, when a customer opens their browser and clicks on the URL for the bank’s web service, the browser will initiate the SSL handshake.
The handshake occurs using the following steps:
- ClientHello: This initial message provides a starting point for SSL communication by sending communication options such as version and type of encryption.
- ServerHello: Server response provides the decisions based on the clients options.
- ServerKeyExchange: Transmits information about the session key and server’s public key to the client.
- ServerHelloDone: Signals the end of the server’s message
- ClientKeyExchange: Confirms the selected encryption algorithm (RSA, Diffie-Hellman or Fortezza/DMS)
- Client’s ChangeCipherSpec: Indicates that the client is ready to begin secure communications
- Finished: Indicates that further messages from the client will be encrypted
- Server’s ChangeCipherSpec: Indicates that the server is ready to begin secure communications
- Finished: Indicates that further messages from the server will be encrypted.
The client and server “Hello” messages are self-explanatory in that they initiate the communication channel. The client offers the server options by telling the server its capabilities. These are version, supported cipher suites, and compression techniques. The server evaluates the client’s capabilities and selects a set before sending back a firm confirmation in its own hello.
In addition, the server must then initiate the key exchange. At this point no encryption has been established, so the server establishes a separate session using its public key to encrypt traffic. Both the client and the server will use this same public key to encrypt traffic over this new session. The server then sends its digital certificate signed by a CA to assure the client that it is the bank’s web server.
The client now enters the key exchange stage. At this stage, the client does not have keys or certificates to exchange information. It simply confirms its keys that will be used to communicate. Both client and server then send notification of a change in “ChangeCipherSpec “to announce both are now going to send data in encrypted format.
At this point, SSL has established a secure, authenticated two-way communication channel.
SSL provides confidentiality, integrity, authentication and ID verification through the use of digital certificates and encryption. The handshake mechanism ensures that the client’s browser and the SSL web server can establish a secure connection using the server’s public-private key pair.