How a browser Works?

When you hit ‘Enter’?

Ever wondered what happens when you type in the URL in a browser and hit Enter. The first thing that the Browser does, is parse the URL.

Parse the URL

Parsing the url gives the browser the following information contained in it:

• Protocol “http”: Use ‘Hyper Text Transfer Protocol’
• Resource “/”: Retrieve main (index) page
• When no protocol or valid domain name is given the browser passes the input test to the default search engine.
• Next browser looks in the cached “preloaded HSTS (HTTP Strict Transport Security, list of websites that have requested to be contacted via HTTPS only)” list.
• If the website is in the list, the browser sends its request via HTTPS instead of HTTP.
• Otherwise, the initial request is sent via HTTP.

DNS lookup

The next step is to find out the IP address which serves/hosts the website which was requested. The following steps are involved to figure out that IP:

• Browser cache: Browser maintains a cache, this is where it looks for the details, if there is no detail in cache it moves on to next step.
• OS cache: If the browser cache does not contain the desired record, the browser makes a system call (gethostbyname in Windows). The OS has its own cache, details can be added/found in hosts or resolv files too.
• Router cache: If no details are found in OS cache the next place to look is the router cache.
• ISP DNS cache: The next place checked is the cache ISP’s DNS server.
• Recursive search: Your ISP’s DNS server begins a recursive search, from the root nameserver, through the .com top-level nameserver, to Google’s nameserver.

How a recursive DNS search looks like

When the browser has the details of website hosting, socket opening, and TLS handshake start.

Opening of a socket + TLS handshake

• The browser takes the IP and given port number (the HTTP protocol defaults to port 80, and HTTPS to port 443) and requests a TCP socket stream.
• The client-side computer sends a ClientHello message to the server side computer with its TLS version.
• The server Responds with a ServerHello message to the client computer with the TLS version, cipher, compression techniques and the server’s public certificate signed by Certificate Authority.
• The client computer then verifies the server digital certificate against its list of trusted CAs. If trust can be established, the client generates a string of pseudo-random bytes and encrypts this with the server’s public key. These random bytes can be used to determine the symmetric key.
• The server decrypts the random bytes using its private key and uses these bytes to generate its own copy of the symmetric master key.
• The client sends a Finished message to the server, encrypting a hash of the transmission up to this point with the symmetric key.
• The server generates its own hash, and then decrypts the client-sent hash to verify that it matches. If it does, it sends its own Finished message to the client, also encrypted with the symmetric key.
• From now on the TLS session transmits the application (HTTP) data encrypted with the agreed symmetric key.