How a website is accessed from a Web Server

1. End user enters https://example.com in its PCs browser.
2. Browser checks its local cache for example.com’s public IP address
3. If not found in local cache, browser will send the request to its broadband ISP (Internet Service Provider). ISP will check in its Resolver Server cache memory. If it cannot find the IP address, it will send a request to the Root Server.
4. Root Servers are the top of the DNS hierarchy.
   • There are 13 sets of root servers strategically placed around the world
   • and are operated by 12 different organisations.
   • Each root server set has its own unique Public IP address.
   • Its job is to confirm the Top Level Domain Server (TLD) to the resolver.
5. So, when root server receives the query for the IP address of the FQDN (example.com), root server will check its database for .com TLD server’s IP and give it to the resolver.
6. Resolver will then send the IP address query to the TLD server for google.com.
7. TLD Server only maintains the database of Authoritative Name Servers (ANSs) and will return the IP of the ANS for .com to the resolver.
8. Resolver will then send its query to the ANS for .com for the IP address of example.com.
9. ANS will respond with the corresponding Public IP address for example.com to resolver.
10. Resolver will return the public IP address to the end-user’s browser.
11. Browser will initiate and TCP 3-way handshake with the webserver hosting example.com

TCP uses a three-way handshake to establish a reliable connection between a client and a server. The handshake ensures both parties are ready to communicate and agree on initial parameters like sequence numbers.

Steps of the TCP Three-Way Handshake:

1. SYN (Synchronize) – Client to Server:
   • The client initiates the connection by sending a SYN packet to the server.
   • This packet contains an initial sequence number (ISN) for tracking data.
2. SYN-ACK (Synchronize-Acknowledge) – Server to Client:
   • The server responds with a SYN-ACK packet.
   • It acknowledges the client’s SYN by setting the ACK flag and an acknowledgment number.
   • It also sends its own ISN to the client.
3. ACK (Acknowledge) – Client to Server:
   • The client sends an ACK packet to confirm the connection.
   • The sequence numbers are updated, and the connection is established

TLS Handshake Process

1. Client Hello (Client → Server)
   • The client (browser) initiates the handshake by sending a ClientHello message.
   • It includes:
     • Supported TLS versions (e.g., TLS 1.2, TLS 1.3).
     • List of supported cipher suites (encryption algorithms).
     • A random number for session key generation.
2. Server Hello (Server → Client)
   • The server responds with a ServerHello message.
   • It includes:
     • The TLS version and cipher suite selected
     • A random number for session key generation
     • The server’s digital certificate (X.509) issued by a Certificate Authority (CA)
3. Server Certificate Authentication
   • The client validates the server’s certificate:
     • Checks if it’s signed by a trusted CA
     • Ensures the certificate is not expired or revoked
     • Confirms the certificate matches the requested domain
4. Keys Exchange and Session Key Generation
   • TLS1.2 and Earlier
     • The client encrypts a pre-master secret using the server’s public key and sends it.
     • The Server decrypts it using its private key
     • Both parties use this secret to derive a shared session key
   • TLS1.3 – More Secure
     • Uses Elliptic Curve Deffie-Hellman (ECDHE) for key exchange
     • The client and server exchange ephemeral keys to generate a shared session key without exposing it.
5. Finished Messages & Secure Communication
   • Both client and server send a Finished message encrypted with the session key
   • The connection is now fully encrypted and secure for data transfer