Visual Networking Thinger

This challenge is a basic lesson in networking. The terminal is located on the north side of the frozen pond. You will find Jared Folkins there. Its a visual quiz application that asks you to match the correct port, message formats, and responses for common network protocols, like DNS, TCP, HTTP, etc...

Just find the correct answer to the questions and click submit.

The first protocol is DNS. DNS is the Domain Name System service machines use to convert domain names to IP addresses. This service is important for allowing us to use easily memorized names for things instead of IP addresses. There are many different record types you can request, but the most common and the one related to this quiz is the A record. A records associate domain names to IPv4 addresses. The only other thing you need to remember for this quiz is that DNS runs on port 53 UDP and TCP. Historically UDP was used, but optionally TCP may be used due to encryption and reliability improvements. For more information consult the DNS Wikipedia.

DNS uses port 53, requesting the A record for a particular domain name. The response is an A record containing the IPv4 address.

The second question is about the TCP 3-way handshake. This handshake is a process used to establish a reliable connection between a client and a server before data is transferred. It ensures both sides are connected and ready for the transfer. Each TCP message can have certain control flags which indicate the type of message being sent. The actual message structure is an important thing to know, but for this challenge all you really need to know is the process. Geeksforgeeks has a great overview of this 3-way handshake process.

The client sends a SYN message, which contains the Synchronize Sequence Number. The server responds with a SYN/ACK which acknowledges (ACK) the sequence number and tells the client what sequence number it expects in the next message. Lastly, the client responds with its own ACK.

If the values all match with what both sides expect, a connection is established and both sides are ready for communication.

The HTTP protocol is how browsers communicate and request data from servers. Specifically, the GET request is a client requesting a resource from a webserver. There are many different HTTP verbs out there. We just have to make sure that our GET request has a valid format. Tutorials Point has a good overview of the HTTP request and response format.

The verb must be GET because we are tasked with creating a GET HTTP request. All of the supplied HTTP version values are real, but 1.1 is still very common, so I selected that one. HTTP version 2 and 3 are getting more and more common and provide advantages like connection reuse, etc... The host is simply the hostname of the webserver you are requesting data from. The User-Agent header is a string that the browser supplies to identify itself. Most of the time, webservers only really use this header to try to make sure the resource provided is compatible for the type of browser. For instance if a User-Agent specifies that its a mobile browser, the server may supply a version of the requested page that is formated for a mobile device. I just grabbed a User-Agent string from my mobile phone and it seemed to work ok. Sometimes User-Agent headers don't effect the response at all.

The server seemed to like my user agent and gave me a valid response.

Transport Layer Security (TLS) is a cryptographic protocol the provides encrypted communication over a network. The first step to establish an ecrypted communication channel is perform the handshake. This handshake negotiates which cipher suite will be used as well as establishing that both parties are ready for communication.

• Client: Sends CLIENT HELLO
• Alerts the server that the client wants to communicate.
• Tells the server which cipher suites the client can use.
• Server: Sends SERVER HELLO
• Tells the client that the server is ready to communicate.
• Specifies the agreed upon cipher suite.
• Server: Sends Certificate
• Client: Sends Cipher Key Exchange
• Tells the server how to calculate the shared secret key
• Both sides can arrive at the same calculated secret key
• This process is specific to the cipher suite selected
• Server: Sends Cipher Key Exchange
• Indicates the switch between unencrypted messages to encrypted.
• Server: Sends FINISHED
• Indicates the end of the handshake process.
• Ready to move on to the data transfer process.

If you want some really good, concise data on this process, check out this Cloudflare page.

The last task is to create a valid HTTPS GET request. The good news is that this process is exactly the same as HTTP GET request because your browser will do the TLS connection negotiation under the covers. You can specify the exact same values as before for HTTP Verb, HTTP Version, Host, and User-Agent.

Once these challenge questions are completed successfully, you will get a notification that the objective is complete in the Holiday Hack Challange as well.