Networking fundamentals Interview topics

Q1) What happens behind the hood when you type a URL?

URL Parsing and DNS Lookup

  • When you type a URL (e.g., https://www.example.com), the browser parses it and identifies the protocol (https) and the domain name (www.example.com).

  • To connect to the server, the browser needs the IP address of www.example.com, so it initiates a DNS (Domain Name System) query.

  • The DNS lookup process goes through the following steps:

    • Browser Cache: Checks if the IP address is cached locally in the browser.

    • Operating System Cache: If not found, it checks the operating system’s DNS cache.

    • Router Cache: If the IP is still not found, it queries the router’s cache.

    • ISP DNS Server: If no local caches have the address, the request is forwarded to the ISP's DNS server.

    • Recursive DNS Lookup: If necessary, the DNS server will perform a recursive lookup by contacting other DNS servers, moving from root DNS servers to TLD (Top-Level Domain) servers and finally to the authoritative DNS server for the domain.

  • Once the IP address is found, it's returned to the browser, which can then proceed with the connection.

2. TCP 3-Way Handshake

  • With the IP address in hand, the browser initiates a TCP connection to the web server on port 443 (the default port for HTTPS).

  • The 3-way handshake process between the client (browser) and server goes as follows:

    • SYN: The client sends a SYN (synchronize) packet to the server, indicating its intention to establish a connection and its initial sequence number.

    • SYN-ACK: The server responds with a SYN-ACK packet, acknowledging the client's SYN packet and providing its own sequence number.

    • ACK: The client sends an ACK (acknowledgment) packet back to the server, completing the handshake and establishing the connection.

3. TLS Handshake and Diffie-Hellman Key Exchange

  • Since this is an HTTPS connection, the client and server now perform a TLS (Transport Layer Security) handshake to establish a secure, encrypted channel. Here’s how this works:

    • ClientHello: The client sends a "ClientHello" message to the server, specifying supported encryption protocols (like TLS 1.3), cipher suites, and a randomly generated value (used in key exchange).

    • ServerHello: The server responds with a "ServerHello" message, selecting a protocol, cipher suite, and another random value.

    • Server Certificate: The server then sends its digital certificate, which contains its public key and proves its identity. The client verifies this certificate, typically through a trusted certificate authority (CA).

    • Diffie-Hellman Key Exchange: The client and server use the Diffie-Hellman algorithm (or a variant like ECDHE) to exchange cryptographic keys. The server and client each generate their own public-private key pairs for this exchange. They share the public keys and compute a shared secret independently, which becomes the session key.

  • Session Key Generation: The session key, derived from the shared secret and random values exchanged during the handshake, is used to encrypt all future communication.

  • Finished Messages: Both client and server exchange "Finished" messages, each encrypted with the session key to ensure that both parties are in sync and that the key exchange was successful.

4. HTTP Request and Response

  • Now that a secure TLS channel is established, the browser sends an HTTP request to fetch the website content.

  • For a typical GET request, the client specifies the resource it wants (e.g., GET /index.html), along with additional headers like cookies, user-agent, etc.

  • The server processes this request and sends back an HTTP response containing the requested resource (e.g., HTML, CSS, JavaScript files) and metadata (e.g., content-type, status code).

5. Rendering the Page

  • The browser parses the HTML, CSS, and JavaScript files received from the server to render the page. If additional resources are needed (like images or fonts), the browser repeats similar request-response cycles to fetch them.

  • Throughout the session, the encrypted channel (established with TLS) ensures that all data exchanged is secure.

Summary

Here’s a quick recap of each step involved when you type a URL into the browser:

  1. DNS Lookup: Resolves the URL to an IP address.

  2. TCP 3-Way Handshake: Establishes a reliable connection between the client and server.

  3. TLS Handshake: Performs mutual authentication and sets up an encrypted channel.

  4. HTTP Request and Response: Fetches the requested resource over the secure connection.

  5. Page Rendering: Browser renders the received content into the final webpage.

Q2) Difference between DNS iterative and recursive query

  • Iterative Query: In an iterative query, each DNS server provides the best answer it has, which could be a direct answer (the IP address) or a referral to another DNS server. This is what the recursive DNS resolver does when querying servers like the Root, TLD, and ultimately, the Authoritative DNS Server.

  • Recursive Query: By contrast, a recursive query is what the client (like your browser or OS) initially sends to the recursive DNS resolver, asking it to resolve the domain entirely on its behalf. The recursive resolver is then responsible for finding the answer by sending iterative queries to other DNS servers.

Key Differences at a Glance

Feature
Recursive Query
Iterative Query

Responsibility

DNS resolver handles entire query process

Client handles entire query process

Process Complexity

Simple for the client

Requires multiple queries by the client

DNS Server Load

Higher for the recursive DNS server

Distributed across different DNS servers

Typical Use Case

Client to DNS resolver

DNS resolver to other DNS servers

Q3) What is recursive DNS lookup?

Let's say I have to visit www.example.com

In my browser and OS cache (ipconfig /displaydns) I couldn't find the IP address.

I'll send a recursive query to my configured DNS server. It could be google (8.8.8.8) or ISP's DNS. The recursive DNS server then would:

  1. Send an iterative query to the root server. There are only 12-13 root servers in the world. These are servers that know the locations of TLD server. Eg: .com server. the root server sends the IP of TLD server to the DNS Client (for us, google DNS).

  2. The DNS client then reaches to the TLD server specified by the root server. The TLD DNS server responds with the IP address of the Authoritative DNS Server responsible for the specific domain (e.g., example.com).

  3. The DNS client then asks the Authoritative DNS server for www.example.com. It responds back with the IP address of the domain www.example.com to the DNS client.

  4. The recursive DNS server caches the IP address for www.example.com so it can respond faster if the same domain is requested again within a certain time frame (TTL - Time To Live).

  5. It then returns the IP address to the client (the browser or OS) that originally requested it.

Q4) Why do we have DNS before TLS?

  • When you type a URL (e.g., https://example.com) in your browser, the browser needs to know the IP address of example.com to connect to the server hosting that site.

  • DNS (Domain Name System) serves as the "phonebook" of the internet, translating human-readable domain names into IP addresses that computers use to route data.

Without DNS, the client wouldn't know which IP address to connect to, so it couldn't start a TLS handshake with the intended server.

Q5) What is RSA and where is it most commonly used?

RSA is an asymmetric cryptography schema which is primarily used for secure data transmission and is based on the mathematical difficulty of factoring large integers, which provides its security foundation. The security of RSA relies on the fact that while it’s easy to multiply two large prime numbers to produce a composite number, it’s extremely difficult to factor the composite number back into its prime factors. This process is known as the factoring problem and is computationally intensive, especially for large numbers.

RSA is used extensively in TLS/SSL certificates, which secure data transmission over the internet. When you visit a website over HTTPS, RSA is often used as part of the process to securely exchange keys that will then encrypt the communication between your browser and the server.

Q6) How does Diffie Hellman Key Exchange Work? How does RSA play a part in TLS if key is already generated by DHE?

The Diffie-Hellman key exchange is a cryptographic protocol that allows two parties to establish a shared secret over an insecure channel. This shared secret can then be used to encrypt further communications using symmetric encryption, without directly transmitting the secret itself.

How Diffie-Hellman Key Exchange Works

Here’s a step-by-step overview of the Diffie-Hellman key exchange:

  1. Agree on Public Parameters:

    • Both parties agree on two public values: a prime number p and a base (or generator) g.

    • These values do not need to be kept secret, and they can be shared openly.

  2. Generate Private Keys:

    • Each party independently chooses a private key:

      • The first party (Alice) chooses a private key a, which is kept secret.

      • The second party (Bob) chooses a private key b, which is also kept secret.

  3. Calculate Public Keys:

    • Each party then uses their private key to calculate a corresponding public key, based on the agreed public parameters:

      • Alice computes her public key as A = g^a mod p

      • Bob computes his public key as B = g^b mod p

    • These public keys A and B are exchanged between Alice and Bob over the insecure channel.

  4. Calculate the Shared Secret:

    • Each party then uses their own private key and the other party’s public key to compute a shared secret:

      • Alice computes the shared secret as S = B^a mod p.

      • Bob computes the shared secret as S=A^b modp.

    • Due to the mathematical properties of modular exponentiation, both Alice and Bob will arrive at the same shared secret S, even though they each used different private keys.

  5. Shared Secret Usage:

    • This shared secret SSS can now be used as a symmetric key for encrypting and decrypting further communication between Alice and Bob.

Key Properties of Diffie-Hellman

  • No Transmission of the Secret: The actual shared secret SSS is never transmitted over the channel, making it secure from eavesdroppers.

  • One-Way Function: The calculations rely on the difficulty of the discrete logarithm problem, meaning that even if an attacker intercepts the public keys AAA and BBB, it is computationally infeasible to determine the private keys aaa and bbb or the shared secret SSS.

How RSA Ties into Diffie-Hellman

RSA and Diffie-Hellman serve different purposes in cryptographic protocols, and they can be combined in systems like TLS for enhanced security.

  1. Authentication:

    • Diffie-Hellman on its own doesn’t provide authentication; it only enables two parties to agree on a shared secret.

    • In protocols like TLS, RSA can be used to authenticate the parties involved by verifying the server’s identity using its RSA-based digital certificate. This certificate, signed by a trusted certificate authority (CA), ensures the client knows it’s connecting to the legitimate server.

  2. Combining RSA and Diffie-Hellman in TLS:

    • The server presents an RSA-based certificate to the client, authenticating itself.

    • The server and client then perform a Diffie-Hellman key exchange to generate a shared session key.

    • The server uses its RSA private key to sign parts of the Diffie-Hellman exchange, verifying to the client that the exchange parameters are indeed from the legitimate server.

  3. Achieving Forward Secrecy:

    • In protocols like TLS, Diffie-Hellman (specifically Ephemeral Diffie-Hellman or DHE) provides forward secrecy, meaning that even if the RSA private key were later compromised, past session keys would remain secure.

    • With RSA alone, a compromised private key could allow an attacker to decrypt past sessions if they had recorded the encrypted traffic. Diffie-Hellman mitigates this by using a unique key for each session.

Summary

  • Diffie-Hellman enables two parties to establish a shared secret over an insecure channel.

  • RSA is used to authenticate the parties in a protocol like TLS.

  • In TLS, DHE_RSA or ECDHE_RSA combines Diffie-Hellman for key exchange (providing forward secrecy) with RSA for authentication, ensuring both security and identity verification.

By using RSA and Diffie-Hellman together, protocols achieve a secure, authenticated connection that also supports forward secrecy, making the communication highly secure against future key compromise.

Q7) TLS handshake using DHE_RSA

TLS Handshake: Step-by-Step with RSA and DHE

  1. ClientHello:

    • When you visit a secure website (starting with https://), your browser (the client) starts by saying hello to the server.

    • The client lists the cipher suites (encryption methods) it supports, including DHE_RSA (which uses both Diffie-Hellman and RSA).

    • It also sends a random value, which will be used later in the encryption process.

  2. ServerHello:

    • The server replies with a ServerHello, choosing a matching cipher suite (in this case, DHE_RSA) that both the client and server support.

    • The server also sends its own random value to be used later in key generation.

  3. Server Certificate (RSA for Authentication):

    • To prove its identity, the server sends a digital certificate to the client. This certificate includes the server’s RSA public key.

    • The client uses this RSA public key to verify that the server is who it says it is by checking the certificate against trusted authorities.

    • This step provides authentication—it assures the client that it’s talking to the legitimate server and not an impostor.

  4. Server Key Exchange (DHE for Key Exchange):

    • Next, the server generates Diffie-Hellman (DH) parameters. These parameters are used to securely create a shared secret that only the client and server will know.

    • The server signs these DH parameters with its RSA private key and sends them to the client.

      • By signing the DH parameters, the server proves that it created them. This prevents any tampering by third parties.

    • The client uses the server’s RSA public key to check this signature and confirm that the DH parameters truly came from the legitimate server.

  5. Client Key Exchange (Completing the DHE Key Exchange):

    • The client now generates its own DH parameters (private and public keys) and sends its DH public key back to the server.

    • Both the client and the server now have each other’s DH public keys and can use them to independently compute a shared secret. This shared secret will serve as the session key.

  6. Session Key Generation (Shared Secret from DHE):

    • Using the Diffie-Hellman method, both the client and server combine:

      • Their own private DH keys.

      • The other party’s public DH keys.

    • This results in a shared session key that only the client and server know.

    • This shared key is unique to the session and will be used to encrypt and decrypt all further communication.

  7. Finished Messages:

    • Both the client and server send a Finished message to each other, encrypted with the session key. This message verifies that they both have the same session key.

    • The handshake is now complete, and both parties are confident they’re talking to each other securely.

  8. Secure Communication:

    • All further communication is now encrypted with the session key.

    • This session key provides forward secrecy because it is generated only for this session. If the server’s RSA private key is ever compromised in the future, it won’t affect this past session.

Summary of How RSA and DHE Are Used

  • RSA is used to authenticate the server by verifying its identity with a digital certificate.

  • DHE (Diffie-Hellman Ephemeral) is used to create a shared session key that provides forward secrecy, meaning the session remains secure even if the server’s RSA key is compromised in the future.

In simpler terms:

  • RSA proves you’re talking to the real server.

  • DHE creates a unique, secure key for each session.

This combination ensures that you’re connected securely and that your data can’t be decrypted by anyone else.

PreviousCompromise using SSH KeyNextWeb Pentest

Last updated