Let’s follow the advancement of the HTTP and SSL protocols to their next forms. It was then brought to IETF, where it was received with moderately minor changes as HTTP/2. Then again, SSL experienced five corrections somewhere in the range of 1995 and 2008, when TLS 1.2 was adopted. TLS 1.2 managed the Web for 10 years before TLS 1.3 was proposed.
Today, the Internet is a need for a huge division of the population. Thus, it should be profoundly accessible, secure and quick. As we talked about in the last article, the Network Stack is the establishment of the Internet and it executes the protocols that govern network communication. The present inspiration is to go past the useful requirements, and structures the reason for redesigning the protocols for security and performance.
What’s wrong with HTTP/1.1 ?
For example, when I attempted www.etechwall.com from my browser, then in the background the browser made 50 HTTP requests , spread across 5 different hosts.
Just to load the home page of etechwall, the browser needed to make connections with 5 distinct hosts and activated 50 HTTP requests. Suppose that the all out content items downloaded was around 500kB, just to show this home page.
Let us likewise be reminded this is just with the homepage of the website, as one explores over the different pages, more content items will be available and downloaded, requiring more connections and HTTPS requests/responses.
Let us take a look at how protocols evolved.
Let’s take a look at the new protocols and at which part of the network stack they work in, getting performance enhancements.
1. Transport layer: TCP → QUIC
2. Session layer: TLS 1.2 → TLS 1.3
3. Application layer : HTTP 1.1 → HTTP/2 to HTTP/3
In this article, we will concentrate on the plan of the HTTP/2 protocol and the performance enhancements that it is relied upon to get. We additionally quickly take a look at TLS 1.2 as it is the most stable and broadly deployed security protocol till date.
The key highlights of HTTP 1.1 are:
1. Message Headers and Metadata are sent in normal text configuration.
2. In HTTP 1.0, just one message could be sent at a time on a connection which is inefficient as we are dealing with a lot of requests and responses.
3. HTTP 1.1 enhanced this with Persistent Connections i.e. a client could send multiple requests on the same connection.
4. HTTP 1.1 likewise had come up with Request Pipelining. With this, a client does not need to hang till a response for a previous request was received before it sent the next request.
Let us take a look at HTTP/2.
The restricted concurrency of HTTP 1.1 makes the web browser hold up till previous requests were responded to. HTTP/2 presented the idea of a stream of information that generally relates to the request/response pair of HTTP 1.1. Nonetheless, HTTP/2 goes beyond this and allows concurrent multi-stream communication on an already established connection.
The other limitation in HTTP 1.1 was its broad use of text content in HTTP Headers. This is one more upgrade driven by HTTP/2, where headers are compressed and transmitted in binary structure.
Multiple streams: HTTP/2 presents another paradigm inside HTTP by taking the request/response and making it adaptable in various manners.
At the point when numerous streams are in progress simultaneously, the sender must show which stream the information being sent belongs to. This prompts the idea of Frames, which are main components of communication in HTTP/2. When an endpoint must send information, it chooses the stream to which the information has a place, shapes a Frame, labels it with the stream-ID, and afterward sends it over the connection.
When an endpoint opens a stream, it needs to pick a stream-ID. Clients take odd numbers and Servers take even numbers. Along these lines, the first client stream normally has the ID of 1, the following one may have the ID 3-5-7 etc, while the first server stream-ID is commonly 2-4-6 etc.
Server Push : It allows a HTTP/2 supported server to send resources to a HTTP/2-supported client before the client demands or requests for them. It is, generally, a presentation method that can be useful in stacking resources preemptively.
Pushed resources are used by the client when it might have in any case created a request to get the resource at any rate; this can bring about wasted data transfer bandwidth whenever said pushed resources go unused by the client.
Header compression: While no semantic changes have been made in streams, the arrangement of streams has been advanced. The HTTP headers, which were in text content in HTTP 1.1, have been dependent upon compression and in this way changed over to a binary arrangement. The compression plot is stateful, which suggests that both the endpoints must have the correct initial state to effectively compress and decompress the stream headers. This is a for each connection state and is shared for all streams on that connection.
We quickly notice some more aspects.
1. Stream : Each stream follows a state machine that demonstrates the messages which a stream can send/get in those states. It is feasible for either endpoint to show which stream is of higher priority.
2. Frames : SETTINGS option allows an endpoint to communicate the restrictions of different protocol elements like the maximum number of concurrent streams, window sizes etc. A stream is opened with the HEADERS outline, whose payload contains the compressed headers. When the HEADERS do not fit inside the maximum frame size supported by the peer, at that point the sender breaks them into different frames. Every one of these frames, other than the first, are marked as CONTINUATION of the HEADERS frame.
3. Error handling: HTTP 2.0 supports two sorts of errors – connection and stream errors. A few instances of these are: Connection errors: Decoding error in a header, decompression error with a header etc. , Stream mistakes: Receiving headers on a stream that causes stream limit points to be surpassed etc.
Let us take a look at TLS 1.2
The SSL protocol is a superb case of integrating the ideas of symmetric and asymmetric cryptography to give start to end to end security.
SSL protocol had two variants – SSLv2 and SSLv3 before it was submitted to the IETF and normalized as TLS 1.0. The cryptography specialists knew about limitations in the protocol and henceforth, TLS 1.2 was proposed and normalized a couple of years before the security analysts started recognizing vulnerabilities in SSLv3. POODLE and BEAST were two of the significant vulnerabilities found in SSLv3 (Let’s do not discuss those vulnerabilities in this section). When they were found, TLS 1.0 and TLS 1.1, as well as even TLS 1.2, was well under deployment. In this way, the Internet people group was set up to manage SSLv3 vulnerabilities, and truth be told, these aided in quickening the appropriation of TLS 1.2.
Let us take a look at SSL/TLS protocols
The SSL protocol includes the following advances:
1. Client sets up a TCP connection with the server and SSL handshake happens. But, how ?
a. Client sends a <ClientHello> message that demonstrates: maximum SSL/TLS version that the client can support, symmetric and asymmetric ciphers that the client supports.
The format of cipher string is: (protocol)_(key_exchange_method)_(certificate)_(symmetric_cipher)_(hash_algo)
For instance, TLS_RSA_WITH_AES_128_CBC_SHA, shows the use of RSA for key exchange and certificate, with AES-128 and SHA hashing a log. Another model is ECDHE-RSA-AES128-SHA256, where the key exchange is Elliptic Curve Diffie-Hellman, the certificate is of type RSA, AES128 is the symmetric cipher and SHA256 is the hashing a log.
b. This format helps in the development process of certificates.
c. The server sends its certificate to the client which verifies the server by checking the certificate.
d. In the following step, if RSA is a key exchange method, the client generates a private key and encrypts the data with the public key from the server’s certificate. This is sent in the ClientKeyExchange message.
e. As the server has the private key for the certificate that is shared, it can decrypt the data using the client’s public key from the ClientKeyExchange message.
f. The session key is generated.
Improvements in TLS 1.2
While TLS 1.2 has on a very basic level a similar stream as its SSL and TLS, the protocol has been improved in the following manners.
1. Expulsion of MD5 hashing method: MD5 is considered cryptographically broken and was misused by malware, subsequently demonstrating a reasonable instance of a hash collision (generating the same hash for two different inputs).
2. Support for SSLv2 has been removed from the default options.
This is enough for this section. There are additionally different enhancements yet every one of them fall in the classification of fixing the protocol. Be that as it may, We have not discussed TLS 1.3, let’s see if we can cover it in one of the next articles in this networking series.
If you have any suggestions or thoughts, just comment down below.