There is other useful information here, such as what layer of the OSI model is being used by switches (Layer 2) and what is being used by routers (Layer 3). Switches move traffic within networks, and routers move traffic between networks.
Anyway, here is the assignment, and my response:
Send a detailed walkthrough of what happens when you go to cnn.com, and it is a multi-factored website. Which means that the information that is coming from Cnn.com is not coming just from cnn.com.
1 - Open browser, type cnn.com
2 - Browser calls the DNS resolver to check the local /hosts file and (if no IP address is found) to check the cache for a DNS record to find the corresponding IP address of cnn.com. The caches are checked in the following order:
Browser cache
OS cache
DNS cache
ISP cache
3 - If no IP address for cnn.com is found in the cache, the ISP DNS server initiates a DNS query to find the address of the server that hosts cnn.com.
If the DNS server is on the same subnet as my local machine then the network library follows the Address Resolution Protocol (ARP) for the DNS server. If the DNS server is on the is on a different subnet than my local machine then the network library follows the ARP process for the Default Gateway IP.
To send the ARP broadcast the network stack library needs the target IP address to look up, as well as the MAC address of the interface it will use to send out the ARP broadcast.
The ARP cache is checked for an ARP entry for the target IP. If the entry is cached then the library returns a value that the target IP is equal to the MAC address.
If the entry is not in the ARP cache:
The Client looks up the routing table to see if the target IP address is on any of the subnets on the local route table. If so, the library uses the interface associated with that subnet. If not, the library uses the interface that has the subnet of our default gateway.
The Client Looks up the MAC address of the selected network interface.
The Client Network library sends a Layer 2 (data link layer) ARP request. The request includes the Sender MAC address, Sender IP address, Target MAC address, and Target IP address.
ARP request:
Sender MAC: client:mac:address:here
Sender IP: client.ip.goes.here
Target MAC: FF:FF:FF:FF:FF:FF (Broadcast)
Target IP: target.ip.goes.here
Next step depends on the hardware between the computer sending the ARP request and the router.
Directly connected to router: Router responds with ARP reply
- Hub: Hub will broadcast ARP request out all the other ports. If router connected on same ‘wire’, it will respond with an ARP reply
- Switch: Switch will check local CAM/MAC table to see which port has the MAC address we went. If no entry it will rebroadcast the ARP request to all other ports. If switch has an entry in the MAC/CAM table it will send the ARP request to the port that has the MAC address we are looking for. If the router is on the same ‘wire’ as the switch it will respond with ARP reply. The reply will be routed directly to the sender using the ARP reply.
Sender MAC: server:mac:address:here
Sender IP: server.ip.goes.here
Target MAC: client:mac:address:here
Target IP: client.ip.goes.here
The network library now has the IP address of the DNS server or the default gateway and it can send a UPP request to the DNS server for the IP address. If the local ISP/DNS does not have it, it starts a recursive search across the list of DNS servers until an answer is returned.
4 - IP address found, the browser initiates a TCP connection with the Server, likely using the default port 80 (HTTP) or port 443 (HTTPS).
The request from the browser is passed to the Transport layer (Layer 4) to create a TCP Segment. The Transport Layer adds (encapsulates) a TCP header, which includes the source port and destination port, and creates a Segment.
The Transport Segment is then sent to the Network layer (Layer 3), which wraps another IP header to create a packet. The IP header includes the IP address of the current machine and the IP address of the destination server (i.e. the IP address for cnn.com, in our example).
The Packet is sent to the Data Link layer (Layer 2), where the encapsulation adds the Ethernet header to create a Frame. The Ethernet header (or Frame header) includes the MAC address of my local machine and the MAC address of the local router.
At this stage the message/segment/packet/frame is ready to be transmitted. To summarize, it includes:
- Request
- TCP Segment (added in Transport layer), Destination Port and Source Port headers
- IP header (added in Network layer) which includes the IP address of the destination server AND the IP Address of the current machine
- Frame Header (added in Data Link layer) that includes the MAC address of the destination machine NIC, and the MAC address of the gateway (local router)
Packet will pass through the wire on some combination of Ethernet / WiFi / Cellular Data Network
Eventually the packet will reach the router managing the local subnet. From there it travels across the autonomous system’s border routers, other autonomous systems, and finally to the destination server. Each router along the way extracts the destination address from the IP header and routes it to the appropriate next hop. The time to live field (TTL) is decremented by one for each router that it passes. Packet will be dropped if the TTL field reaches zero or if the router has no space in its queue.
When the message reaches the server it is de-encapsulated: the Frame header is stripped by the Data Link layer, then the IP header is stripped by the Network layer, and then the TCP header is stripped and used to identify the destination port on the server. (Likely 443, if we connect to cnn via HTTPS.)
When the message is received we can establish a connection via a TCP/IP three way handshake, where the Client and Server exchange SYN (synchronize) and ACK (acknowledge) messages to establish a connection.
Step 1/3: Client sends a SYN packet to server asking if open for new connections
2/3: If the server has open ports that can accept and initiate new connections, it will respond with ACKnowledgement of the SYN packet with a SYN/ACK packet
3/3: Client receives SYN/ACK from server and acknowledges with ACK packet, and the connection is established.
Connection established, we can now execute the TLS handshake:
- Client sends ClientHello message to the server with its TLS version, list of cipher algorithms, and available compression methods.
- Server replies with ServerHello to Client with TLS version, selected cipher, selected compression methods, and server’s public cert signed by a Cert Authority.
- If using typical RSA (not PFS) encryption, then the Client uses the server’s public key to create a pre-master Secret, and sends that pre-master secret to the Server.
- Server decrypts the pre-master secret from the Client using its private key, and both the Server and Client can now generate a Master Secret, or Session Key, for bulk encryption. Usually this asymmetric encryption is used with the RSA encryption algorithm.
- If using Diffie-Hellman Ephemeral Encryption (enforces Perfect Forward Secrecy), the Server responds with a Diffie-Hellman key exchange as its preferred selected cipher. It uses two known, public values (prime number and a modulo number), along with a secret value, to send a Diffie-Hellman key value to the Client.
- Client uses this Server Diffie-Hellmen key value to calculate its own Diffie-Hellman Key value (the math is complex, but it is based on the fact that the Client knows the modulo and prime number used by the Server, and also on a unique number known only to the client), and sends that back to the server.
- Now both Client and Server know the calculated values for each other, and they can use these values to generate a pre-master secret. Both Client and Server arrive at a pre-master secret without ever having had to know the private key of the Server.
- Once a pre-master secret is generated, then a master secret on both Client and Server is generated (often using AES), and they can communicate.
- Note that if PFS is enabled then this flow is repeated, and a new key is generated for each session of the Client and Server. Using Elliptic Curve Diffie-Hellman Ephemeral encryption will improve performance, as ECDHE offers similar security to RSA at substantially lower bit sizes.
5 - Once the TLS handshake is complete my browser can send a HTTPS GET request to transfer data from cnn.com. The request contains additional information like browser identification (User-Agent header) and requests it will accept (Accept header), and connection headers to keep the TCP connection alive for future requests. It will also pass info from cookies that my browser has stored for this domain.
6 - Server receives the request and passes it to a handler to read and generate a response. The handler reads the request, the headers, the cookies, updates any information on the server as needed and assembles a response in the format specified by my request. The server sends an HTTP response with the form:
200 OK
Headers for:
Content-Encoding
Cache-Control
Cookies to set
Privacy information
(single empty line)
If the HTTP headers sent by the Client include enough information to determine that the version of the file is unchanged since the last visit then it sends a 304 Not Modified response and no payload, and the Client Web browser retrieves the HTML from its cache.
After parsing the HTML the Client and Server repeat this process for every resource (CSS, image, etc.) referenced by the HTML page.
7 - My browser displays the HTML content.
No comments:
Post a Comment