Connecting the Dots: The Internet and Your Search for Google

What the heck is Internet ?

We have many devices at our home, and we want them all to connect so that they can share information with each other. So for this purpose we use a switch which connects them all together. This forms a local area network (LAN).But this only works within your home, the devices can’t reach the outside world-yet.

Now, what if you want to connect to another LAN, like one in a friend’s house or another office building? To do this, we use a router. The router takes the data from your LAN and sends it to another network. When you connect two or more LANs, you form a Wide Area Network (WAN).This WAN can stretch over cities, countries, or even continents, depending on the scale of the networks connected.

But connecting a few LANs isn’t the full picture.The internet is a much larger network made up of millions of these smaller LANs and WANs, all connected together. It’s like taking the small networks formed in homes, offices, and schools and linking them into a global network.A massive WAN is the Internet.

What happens when we type www.google.com in Browser ?

Step 1 : DNS Lookup

• Our browser first finds out the IP address of www.google.com because computers use IP addresses (like 222.777.020.364) to communicate, not domain names.

• For that it first sends a request to a DNS (Domain Name System) server, which acts like a phone book for the internet, converting domain names into IP addresses. If the IP address for www.google.com isn’t cached (stored locally or in your ISP’s DNS server), it queries other DNS servers until it finds the IP address.

Step 2 : TCP Connection

Once the IP address is known, your browser establishes a connection with Google’s servers using TCP (Transmission Control Protocol).A process called the three-way handshake occurs to establish this connection:

1. Client sends a synchronization SYN (synchronize) packet to server saying that I want to connect with you.

2. Server will acknowledge the requet by sending SYN-ACK (synchronize-acknowledge) packet.

3. Client sends an ACK (acknowledge) packet back, and the connection is established.

Step 3 : TLS (Transport Layer Security) handshake

Now this is one of the important step where you need to pay attention.TLS handshake ensures that all data transmitted between your device and the server is encrypted, making it unreadable to anyone who intercepts it.The TLS handshake also helps ensure that the data sent and received is not tampered with during transmission.

The TLS handshake is not required for a regular HTTP connection because it transfers data between a client (like a browser) and a server without encryption but to setup a HTTPS connection it is crucial.Now let’s see how this TLS handshake happens:

1. Client Hello : The client sends a message Client Hello to the server.It includes :

   1. version: Highest version of TLS/SSL Client supports.

   2. Random Number:32Bytes - Timestamp endcode in first four bytes.The random number is used to help generate the session keys that will be used for encryption later in the handshake.It adds randomness to the key generation process, making it more secure and preventing attackers from predicting or precomputing keys.

   3. Session Id : 8bytes.Reference for this particular sessionAll 0’s will be sent by client initially.

   4. Cipher suits : List of Cipher suits(encryption algorithms) client supports, so that both client and server will later agree upon any one algorithm.

2. Server Hello : The server responds with a Server Hello message, which contains:

   1. version: Highest version of TLS/SSL Server supports.This will be the final version that will be used.

   2. Random Number:32Bytes - Timestamp endcode in first four bytes.

   3. Session Id - 8 Bytes.Randomly generated value that will be used as a reference for this particular session

   4. Cipher suits : The chosen cipher suite from the client’s list.

3. Certificate : Server will be sending his SSL certificate which contains its public key and is signed by a trusted Certificate Authority (CA).When the client receives the server's certificate, it verifies that it is signed by a CA that the client trusts. This helps the client confirm that it is indeed connecting to the legitimate server and not an imposter. Now the question that should pop up in your brain is that why server don’t send Public key directly, why sharing that along a certificate ? [Remember the mathematical relationship between private and public keys is such that message encrypted by a public key can only be decryptes by it’s pair of private key].

   Let’s say the server sends its public key directly over the internet, without embedding it in a certificate. Now see what happens - If a hacker intercepts this public key during transmission, they could replace it with their own. When you then use this tampered public key to encrypt your messages, the hacker would be able to decrypt them with their own private key. As a result, the hacker could impersonate the server, making you believe you're communicating securely with the genuine server, while in reality, you're interacting with the hacker.

   See if a hacker will be tampering the public key send along with signed SSL certificate then client will immediately come to know that this is a tempered public key because signatures will become invalid as soon as you will be changing even a dot in the public key.

4. Server Hello Done : The server sends a Server Hello Done message to indicate it has completed its part of the handshake.

5. Client Key Exchange:This is a message sent by the client to server for two purposes :

   1. Client wants to know is that server the legitimate holder of this certificate.Always remember the certificate always contains the issuer Public key and the server’s public key.So what client will be doing is that it will be sending a text encrypted with server’s public key and if the server will be able to decrypt that then it confirms that server is the legitimate holder because that text could have been decrypted only with the private key pair of that public key which server should have with it.

   2. Secondly they want to have a pre master secret text which they will be using to generate session keys.Pre master secret text is that same that client encrypted in above point.

6. Generating the Master Secret : Both the client and the server use the pre-master secret along with the random values exchanged earlier to generate a master secret. This master secret is then used to create session keys for encryption and decryption.

   master secret = Premaster secret + “master secret”+client Random+server Random

7. Generating Session Keys : Now 4 session keys will be generated with these master secret.

   session keys = master sercret +”key expansion”+client random+server random+PRF(Pseudo Random Function)

   These 4 session keys are :

   1. Client Encryption key:Used by the client to encrypt data it sends to the server.

   2. Client HMAC Key:Used by the client for message integrity (MAC - Message Authentication Code).

   3. Server Encryption key:Used by the server to encrypt data it sends to the client.

   4. Server HMAC key:Used by the server for message integrity.

The HMAC key ensures that the message received is the same as the message sent. If an attacker tries to alter the message in transit, the MAC value (computed using the MAC key) will not match when the recipient checks it, and the message will be considered tampered with.Before sending a message, the sender (client or server) computes a MAC using the MAC key and attaches it to the message. This MAC value is a fixed-length code derived from the message content and the MAC key.The recipient uses the corresponding MAC key to generate its own MAC based on the received message. It then compares this computed MAC with the MAC value sent alongside the message.If the two match, the message is confirmed to be intact and authentic. If not, the message is rejected as tampered.

Now below steps are just for confimation that both cient and server have got same set of all four session keys.

8. Change Cipher Spec : Client will send a Change Cipher Spec message to signal that it will start using the new session keys for encryption

9. Handshake: Finished Client will generate a hash(verification Data) with values :

   verification Data = master secret +”client finished”+handshake hash + PRF where handshake hash :

   Handshake hash = Client hello+server hello+certificate+server hello done+client key exchange

   This verification data will be encrypted with public key of client encryption keys .

   Now server also has these all data used for generating this verification data and it will also generate this verification data.Then server will be decrypting the verification data sent by client with its own set of client encryption key(session key).This proves client has correct set of session keys.

10. Now at end server will be sending it’s change cipher spec and finish message to prove to client that server has correct session keys.

So now both server and client will start sending data encrypted with these session keys they have negotiated upon.If you have understood till now give yourself a pat on your back because we just have covered lots on things and if you feel some confusion do give it a read again because I know it’s little difficult to understand.

Step 4 : Server Processing

Now connection is established so Google’s server receives the request and processes it. It might query its databases, run backend code, or fetch necessary files (HTML, CSS, JavaScript) to construct the webpage.Once the server has assembled the page, it sends it back to your browser in the form of an HTTP response.

Now your browser receive the response and renders that page for you and voila! this is how your request to www.google.com completes.So, the next time you type in a URL and hit enter, remember the remarkable journey your request undertakes to bring the information you seek right to your fingertips.Happy Coding :)