Delving into secure communication over the internet
Transmission of sensitive information over the internet requires a trustworthy relationship to be established between the client machine and the server. Over the years, network communication security standards have been advancing on identity authentication, integrity and privacy aspects.
When browsing the network you may have noticed a lock icon in the corner of browser URL.
This indicates that a secure protocol has been agreed upon by the web browser and the server.
Normally when you visit an HTTP site, the padlock will be visualized as given below indicating that a secure connection has not been established.
In 2014, Google recommended websites to be switched to HTTPS. Today most of the websites we navigate are HTTPS-based. HTTPS (where ‘S’ stands for Secure) is an enhancement to HTTP by using TLS (SSL) to encrypt normal HTTP requests and responses. With HTTPS even if the packets are subjected to man in the middle attacks, they will come across as nonsensical characters to the attacker.
Let’s look into how SSL/TLS is playing major role to secure our browser interactions.
Developed in 1995 by Netscape, Secure Socket Layer (SSL) is a public key encryption based protocol introduced for the purpose of securely exchanging information in the internet. Transport Layer Security (TLS) is its successor.
Netscape worked on three SSL versions. SSL 1.0 had major security flaws which hindered the public release. SSL 2.0 also was identified with several security loopholes resulting in the design of SSL 3.0 just a year later. The POODLE attack in 2004 labeled SSL 3.0 as insecure.
With SSL 3.0 release, the development of future versions was taken over by the IETF.
TLS 1.0 was introduced as an upgrade to SSL 3.0. However, this protocol release was subjected to downgrade attacks as it allows attackers to downgrade to SSL 3.0. TLS 1.1 release provided protection against Cipher Block Chaining attacks. TLS 1.2 provides a significant enhancement in encryption by allowing the use of more secure hash algorithms.
Security and speed are further improved with the latest TLS 1.3 release.
As of the current time of writing, the recommended versions of TLS are 1.2 and 1.3
When looking into SSL/TLS architecture, it is important to understand how the handshake protocol works.
In the network security context, handshake is the means of establishing a secure connection between the client (ex: web browser) and the server (ex: web application) to pass messages. Validating the identity of the two parties to generating the secret key happens in this process.
Typically the handshaking contains the following series of messaging operations.
Client Hello
This is the first message in the handshake. The client machine requests a secure communication session to the server. This message contains information such as the version of SSL/TLS to be used, client supported cipher suites and compression methods.
Cipher suite is a collection of cryptographic algorithms that help secure a network connection that uses SSL/TLS. There are a number of cipher suites available and most of the time there is a cipher suite that can be accessed by both client and server.
Server Hello
The server responds back with the selected connection parameters. If the client and server do not share any capabilities in common, the connection is terminated at this point.
Server Certificate
Along with the parameters mentioned in the previous step, the server sends its certificates with the certificate chain to the client. The certificate chain will be validated against the list of certificates in the client trust store. The server’s public key information, signature algorithm, etc are also sent.
Server Key Exchange
In this message, the server sends details required by the client for generating the pre-master secret. Note that this step is required only if the details mentioned in the server certificate is not sufficient to generate a pre-master secret. This is dependent on the key exchange algorithm. For example, Diffie Hellman Ephermal key exchange method requires the server to provide additional data. RSA key exchange algorithm doesn’t require this step.
Server Hello Done
This message indicates the end of “Server Hello” messages.
Client Key Exchange
This message contains information on the key to be utilized by the client and the server for communication. With this message, the negotiation process between the two parties is completed.
Change Cipher Spec
This message signals that data transmission hereafter is transferred from an insecure state to a secure state by either of the party in the TLS negotiation process.
Client Change Cipher Spec indicates that any data sent from the client hereafter will be encrypted.
Server Change Cipher Spec indicates that any data sent from the server hereafter will be encrypted.
Finished
The final message of the handshake process indicates the handshake is completed.
When looking into the handshake messaging process we can see that there is a significant number of calls happening between the two communication parties. You may wonder about the web performance impact of this process. TLS 1.3 was designed with this in mind. With this latest version of TLS, encrypted connections have been made speedier with features such as Zero Round Trip Time (0-RTT) and TLS false start. Refer here for more information on TLS 1.3.
References: