<style>
details {
padding-left: 2em;
padding-bottom: 1em;

summary:hover {
text-decoration: underline;
}
}
</style>

# Lab: Getting started with Wireshark

Wireshark a network traffic analyzer. It is widely regarded as the de facto tool for capturing and examining network traffic.

In this lab, you'll install Wireshark on your own system and become familiar with a few of its key features: capturing traffic, exploring packets, and extracting data from captures.
There will be a few points in this tutorial where you can demonstrate your progress, which you can include in your homework submission to receive credit.

## Installing Wireshark

To install Wireshark:

1. Download Wireshark via [this link](https://www.wireshark.org/download.html) and install it on your system.
2. Install Wireshark using the installer you downloaded. You may be prompted to install some additional components (eg. `WinPcap` on Windows or BPF tools on MacOS); you should install these as well.
3. Next, open wireshark! You should be greeted with a window like this:


**What's next?** There are two ways to use wireshark: it can perform **live captures**, where it reads and displays network traffic observed on your system in real-time, or it can view or save **capture files** (also called .pcap files), which are files that store captured traffic for later analysis. In this lab, we will briefly work with both.

## Starting a live capture

Now that you have Wireshark running, it's time to use it to capture traffic!

Packet captures are performed by attaching to one of your system's network *interfaces* (eg. your Wifi card, Ethernet port, etc.). To start a capture:
1. Select **Capture > Options** from the menus at the top. This will present a list of interfaces
2. **Select the network interface you use to connect to the internet.** If you connect using Wifi, the interface is most likely labeled "Wi-Fi", "Wireless Network connection", or "Local Area Connection".
<details><summary><b>Not sure which interface to pick?</b></summary>

- If you're not sure which interface is correct, watch the tiny traffic graphs that appear next to each interface: the one you use to connect to the internet should have the most activity.
- If the graphs don't give any clues, you can just start at the top of the list and try every interface except "Loopback". If you've picked the right one, you should see some traffic within a couple of seconds.

</details>
3. Once you've selected your interface, click **Start**.
4. If all goes well, your main Wireshark window should now be filled with a whole lot of packets, like the figure below. Yay! If you don't see anything: make sure you are connected to the Internet, or try a different interface.


What you're seeing are all the packets entering or leaving your network interface in real-time. If you have some applications running that are using a lot of network traffic (eg. watching a video), you may see a lot of packets!

Just watching the packets in real-time can be useful: you can observe exactly how your system is interacting with the network as you do things. However, what we see here is a ton of information--this can be overwhelming, and we don't need to understand everything here. In the next section, we'll look at how to narrow this down and examine some packets.

:::warning
**Warning**: While you have a live capture running, Wireshark stores all network traffic it captures in your memory or on disk. If you're doing something bandwidth intensive (eg. streaming a movie, Zoom call, etc.) and need to leave the capture running, this could use a lot of resources!

**If you need to stop working on this tutorial**, you can stop your capture by selecting **Capture > Stop** from the menu. This will stop Wireshark from saving packets while you're not working.

> *It's also possible to confiure Wireshark to skip saving certain types of packets to save resources: this is called a capture filter, which is beyond the scope of this tutorial. You can read more about Capture Filters [here](https://wiki.wireshark.org/CaptureFilters).*
:::

## Filtering traffic

To help us sort through all of the packets, Wireshark has support for *filtering* traffic based on certain criteria. This can be useful to focus your analysis for certain types of packets.

To demonstrate filters, we'll send some traffic and then look for it in Wireshark's output. To do this:

1. Start a live capture as described in the previous section (or leave it running if you already had it open)

2. Open a terminal on your host machine and run one of the following:
- **(On MacOS/Linux)**: `ping -c 3 1.1.1.1`
- **(On Windows, from Command Prompt/Powershell)**: `ping 1.1.1.1`

This will send some ping packets (like in the figure below)--these are really simple messages used to test if a host is online. In this case, we are sending three packets to the address 1.1.1.1 (which happens to be [Cloudflare's public DNS server](https://1.1.1.1)).

When you type the command, you might see some pink packets fly past your Wireshark output. To find them, let's add a filter:

2. In the "Display filter" box just above the packet list, **enter the filter `icmp`**. This tells Wireshark to show only packets for the [ICMP protocol](https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol), which is the protocol used by ping packets. Your Wireshark window should now look like this:


You should now see six packets (like the figure) in the list: there should be 3 packets sent from your IP address to 1.1.1.1, and a response for each one.

You've now had practice with the most basic Wireshark filters. You can do a lot with filters--this is only the beginning. Here are some more examples of filters you might find useful:
- `http`: Show all HTTP traffic
- `icmp || dns`: Show all ICMP and DNS packets
- `tcp.port == 80`, `udp.port == 1234`: Show traffic on a certain port number
- `ip.len > 1000`: Show all IP packets > 1000 bytes in size
- `http.request.method == "GET"`: Show all HTTP GET requests

To read more about Wireshark filters, see [here](https://wiki.wireshark.org/DisplayFilters).

### Exploring packets

The main packet list shows the most important information about each packet, but we can also look further to see what each byte of the packet means. Wireshark contains hundreds of packet *dissectors*, which are programs that know how to decode various network protocols and display the information for you.

For example, Wireshark knows these packets use the ICMP protocol because it has a built-in dissector to recognize these packets.

To explore further:
1. Click on one of the ICMP packets from the previous step
2. Look in Wireshark's lower-left pane. This shows *decoded view* for the packet, which is what Wireshark's dissectors found when analyzing the packet. The decoded view has a tree-like structure: each part of the tree pertains to a different packet header, roughly corresponding to the different protocol layers we've been leaning about in lecture (eg. link-layer, IP, ...).
To practice this, **expand some of the headers and look at the different fields**. As you click on them, you should see some data highlighted in the pane to the right--these are the actual bytes in the packet that match this field!

For example, each ICMP packet has an *identifier* field, so that it's possible to uniquely differentiate between two ping packets. Here's what it looks like in decoded and bytes view:


## Decoding HTTP traffic

Now that we've seen the basics, let's explore some of Wireshark's more powerful features for decoding more complex traffic. To do this:

1. If you already have a live capture running from the previous step, stop it by selecting **Capture > Stop** from the menu
1. Download **[this capture file](https://brown-csci1660.github.io/files/assignments/juice-demo.pcapng)** and open it in Wireshark with **File > Open**. *(You may get a prompt asking if you want to save your previous capture. If so, you can continue without saving--you will not need this data.)*

This file contains a saved capture of a request to an insecure website (you might even find it familiar...) via HTTP. If you scroll through the file, you should see some traffic that represents fetching a web page in a browser.

Recall from the Flag project that a web page contains many elements and resources: browsers fetch an initial web page and then need to issue additional requests for other assets on the page (eg. images, fonts, etc.). Most of the packets here result from loading a single web page! In particular, if you scroll through the capture, you will see:
- Some DNS queries for the main site (`juice.cs1660.net`), as well as various other domains referenced in URLs. (To see this, filter with `dns`)
- Lots of HTTP traffic on port 80, for the main web page and various other assets on the page (Filter with `http` or `tcp.port == 80`)
- More web traffic using HTTP and HTTPS (on port 443) for external resources used by the web page (eg. fonts, libraries). The HTTPS traffic is encrypted, so instead of seeing the request in the clear, we see the setup process for a TLS connection.

Wireshark can tell us more about the web page and the HTTP request process. To see this:
1. **Scroll down to packet 619** (based on the number in the leftmost column in the packet view). This packet should be a `GET` request for the URL `/assets/public/images/products/fruit_press.jpg`
2. **Click on this packet and expand the HTTP header** in the decoded view. You should be able to see all of the HTTP headers and cookies sent with the packet, which should look like this:


Think back to how you once viewed this same information in your browser's Developer Tools--now you're seeing the actual bytes as they're sent over the network!

3. Under the HTTP headers are some lines that look like links. These are added by Wireshark as it analyzes all of the requests and responses in the capture. For example, Wireshark can figure out if the server responded to this request, and where the response is located in the capture. To see this, **click on the link "Response in frame..."** to jump to the response, which should look like this:


Some things to note about this message:
- The note from wireshark "4 reassembled TCP segments": means that the HTTP response was actually sent to the browser in 4 TCP packets. TCP's job is to *reassemble* these packets into the response that the browser sees: Wireshark can read the TCP information on the packet and reassemble the response, just as your browser does!
- Take a look at the data in the response: Wireshark is looking at the content and recognizes this is a JPG file, which matches what we would expect based on the URL (`.../images/products/fruit_press.jpg`)

### Exporting HTTP objects

In addition to showing us HTTP requests and responses, Wireshark can also *export* the page elements for us to view! To do this:

1. With the Juice Shop capture file open (from the previous section), go to **File > Export Objects... > HTTP**. You should see a window that looks like this:


This is a view of all the HTTP data that was returned in HTTP responses and would have been loaded by the browser. Since all the data was sent in the clear via HTTP, we can view all of this content! :eyes::eyes::eyes:

2. **Click on one of the images.** You should see Wireshark jump to the packets where the image appeared in the capture.

3. Click **Save** to save the image to your computer.
*If you get an error saying the filesystem is read-only, make sure you are saving to a path in your user folder--for some reason, Wireshark might select an unwritable system path by default.*

Congrats, you successfully extracted data from a packet capture, just like a network eavesdropper might be able to do! :sunglasses: :tada:

## What to submit: a final challenge

Now that you've learned some basic skills for exploring capture files, packets and filters, demonstrate your skills by doing the following:

1. In your homework submission, **include one of the images you extracted from the capture file**, per the [Exporting HTTP objects](#Exporting-HTTP-objects) section.
2. Somewhere in the capture file, there is an unencrypted `POST` request where a user logs in. **Find this request and include the user's credentials (email and password) in your submission.** To do this, remember [what you learned about filters](#Filtering-traffic) to search for this request, then look at the request content to find the credentials.

There is no particular format for your submission, so long as you include these items.

We hope you found this initial tutorial on Wireshark useful. For more guides and demos, we recommend checking out [Wireshark's documentation](https://www.wireshark.org/docs/), which has a lot of guides and tutorial videos to learn more!

<!---

## Wireshark Overview

The first screen that we are greeted by when opening Wireshark is the main page that will allow us to specify our interface(s) as well as apply filters to narrow down traffic that we are capturing.


Here you can see that I have multiple interfaces to filter from you may have more or fewer interfaces than I have. From here we can choose whether we want to perform a live capture on our interface(s) or load a PCAP for analysis.

It is useful to note that the graphs next to the interface names show the activity on the interface, if an interface has a flat bar it may be useless to attempt to capture on it (as no data on that interface is being picked up by the Wireshark client).

### Live Packet Captures

If we begin by navigating to the green ribbon in Wireshark and select Manage Capture Filters we can view a list of available filters.


You do not have to select a filter, it will only help to bring down the number of packets being brought in and organize the capture. This is only a brief introduction to filters for more information about filters go to Task 12 or go to the [Wireshark Website](https://wiki.wireshark.org/CaptureFilters).

Once you have any capture filters you want selected, you can begin a capture on an interface by double-clicking the interface or by right-clicking and navigating to Start Capture.

Depending on the network activity you may see no packets coming in or you may see packets streaming in very quickly.

Once you're done gathering the packets you need or want, you can click the red square to stop capturing, and then you can begin your analysis.


Looking at the screenshot above we see a sample capture. This screen is where you will do most of your analysis and dissection of packets. To open a packet capture go to File > Open > and select what PCAP you want to analyze.

From this screen, Wireshark gives us some important info about each packet including:

- Packet Number
- Time
- Source
- Destination
- Protocol
- Length
- Packet Info

Along with quick packet information, Wireshark also color codes packets in order of danger level as well as protocol to be able to quickly spot anomalies and protocols in captures.


This quick glance at packet information can be useful to track down exactly what you're looking for during analysis.

Play around with the menus and various features of Wireshark to get a feel for it, some of the features we will be going into further detail within later tasks.

## Filtering Captures

Packet Filtering is a very important part of packet analysis especially when you have a very large number of packet sometimes even 100,000 plus. In task 3 capture filters were briefly covered however there is a second type of filter that is often thought of as more powerful and easier to use. This second method is known as display filters, you can apply display filters in two ways: through the analyze tab and at the filter bar at the top of the packet capture.

### Filtering Operators

Wireshark's filter syntax can be simple to understand making it easy to get a hold of quickly. To get the most out of these filters you need to have a basic understanding of boolean and logic operators.

Wireshark only has a few that you will need to be familiar with:

- and - operator: and / &&
- or - operator: or / ||
- equals - operator: eq / ==
- not equal - operator: ne / !=
- greater than - operator: gt / >
- less than - operator: lt / <

Wireshark also has a few other operators that go beyond the power of normal logical operators. These operators are the contains, matches, and bitwise_and operators. These operators can be very useful when you have a large capture and need to pinpoint a single packet. They are out of scope for this room however I recommend doing your own research, the [Wireshark Filtering Documentation](https://www.wireshark.org/docs/wsug_html_chunked/ChWorkBuildDisplayFilterSection.html) can be a great starting point.

## Basic Filtering

Filtering gives us a very large scope of what we can do with the packets, because of this there can be a lot of different filtering syntax options. We will only be covering the very basics in this room such as filtering by IP, protocol, etc. for more information on filtering check out the [Wireshark filtering documentation](https://wiki.wireshark.org/DisplayFilters).

There is a general syntax to the filter commands however they can be a little silly at times. The basic syntax of Wireshark filters is some kind of service or protocol like ip or tcp, followed by a dot then whatever is being filtered for example an address, MAC, SRC, protocol, etc.

Filtering by IP: The first filter we will look at is ip.addr, this filter will allow you to comb through the traffic and only see packets with a specific IP address contained in those packets, whether it be from the source or destination.

Syntax: `ip.addr == <IP Address>`


This filter can be handy in practical applications, say when you are threat hunting, and have identified a potentially suspicious host with other tools, you can use Wireshark to further analyze the packets coming from that device.

Filtering by SRC and DST: The second filter will look at is two in one as well as a filter operator: `ip.src` and `ip.dst`. These filters allow us to filter the traffic by the source and destination from which the traffic is coming from.

Syntax: `ip.src == <SRC IP Address> and ip.dst == <DST IP Address>`


Similar to the first filter we can see that Wireshark is combing through the packets and filtering based on the source and destination we set.

Filtering by TCP Protocols: The last filter that we will be covering is the protocol filter, this allows you to set a port or protocol to filter by and can be handy when trying to keep track of an unusual protocol or port being used.

It is worthwhile to mention that Wireshark can filter by both port numbers as well as protocol names.

Syntax: `tcp.port eq <Port #> or <Protocol Name>`


Filtering by UDP Protocols: You can also filter by UDP ports by changing the prefix from tcp to udp.

Syntax: `udp.port eq <Port #> or <Protocol Name>`

That is the end of filtering for this task however I recommend you play around with other filters and operators on your own. Once you're ready move on to Task 5.

## Packet Dissection

This section covers how Wireshark uses OSI layers to break down packets and how to use these layers for analysis. It is expected that you already have background knowledge of what the OSI model is and how it works.


### Packet Details

You can double click on a packet in capture to open its details. Packets consist of 5 to 7 layers based on the OSI model. We will go over all of them in an HTTP packet from a sample capture.


Looking above we can see 7 distinct layers to the packet: frame/packet, source `[MAC]`, source `[IP]`, protocol, protocol errors, application protocol, and application data. Below we will go over the layers in more detail.

- Frame (Layer 1) -- This will show you what frame / packet you are looking at as well as details specific to the Physical layer of the OSI model.


- Source `[MAC]` (Layer 2) -- This will show you the source and destination MAC Addresses; from the Data Link layer of the OSI model.


- Source `[IP]` (Layer 3) -- This will show you the source and destination IPv4 Addresses; from the Network layer of the OSI model.


- Protocol (Layer 4) -- This will show you details of the protocol used (UDP/TCP) along with source and destination ports; from the Transport layer of the OSI model.


- Protocol Errors -- This is a continuation of the 4th layer showing specific segments from TCP that needed to be reassembled.


- Application Protocol (Layer 5) -- This will show details specific to the protocol being used such HTTP, FTP, SMB, etc. From the Application layer of the OSI model.


- Application Data -- This is an extension of layer 5 that can show the application-specific data.


Now that we understand what a general packet is composed of, move on to looking at various application protocols and their specific details.

## ARP Traffic

### ARP Overview

ARP or Address Resolution Protocol is a Layer 2 protocol that is used to connect IP Addresses with MAC Addresses. They will contain REQUEST messages and RESPONSE messages. To identify packets the message header will contain one of two operation codes:

- Request (1)
- Reply (2)

Below you can see a packet capture of multiple ARP requests and replies.


It is useful to note that most devices will identify themselves or Wireshark will identify it such as Intel_78, an example of suspicious traffic would be many requests from an unrecognized source. You need to enable a setting within Wireshark however to resolve physical addresses. To enable this feature, navigate to View > Name Resolution > Ensure that Resolve Physical Addresses is checked.

Looking at the below screenshot we can see that a Cisco device is sending ARP Requests, meaning that we should be able to trust this device, however you should always stay on the side of caution when analyzing packets.


### ARP Traffic Overview

ARP Request Packets:

We can begin analyzing packets by looking at the first ARP Request packet and looking at the packet details.


Looking at the packet details above, the most important details of the packet are outlined in red. The Opcode is short for operation code and will you tell you whether it is an ARP Request or Reply. The second outlined detail is to where the packet is requesting to, in this case, it is broadcasting the request to all.

ARP Reply Packets:


Looking at the above packet details we can see from the Opcode that it is an ARP Reply packet. We can also get other useful information like the MAC and IP Address that was sent along with the reply since this is a reply packet we know that this was the information sent along with the message.

ARP is one of the simpler protocols to analyze, all you need to remember is to identify whether it is a request or reply packet and who it is being sent by.

### Practical ARP Packet Analysis

Now that you know what ARP packets and normal traffic look, let's dive into an exercise. Start the AttackBox, and go to the folder/root/Rooms/Wireshark101 and double click the task7.pcap file to open it in Wireshark; you can also download the provided PCAP on the task.

This capture has multiple protocols so you may need to use your knowledge of filtering from previous tasks; once you're ready, begin analysis of the capture.

:::danger
TODO: add PCAP file link for downloading
:::
Download the PCAP file here and answer the below questions.

:::success
**Questions:**
1. What is the opcode for Packet 6?
2. What is the source MAC address of Packet 19?
3. What 4 packets are Reply packets?
4. What IP address is at 80\:fb\:06\:f0\:45\:d7?
:::

## TCP Traffic

### TCP Overview

TCP or Transmission Control Protocol handles the delivery of packets including sequencing and errors. You should already have an understanding of how TCP works, if you need a refresher check out the [IETF TCP Documentation](https://tools.ietf.org/html/rfc793).

Below you can see a sample of a Nmap scan, scanning port 80 and 443. We can tell that the port is closed due to the RST, ACK packet in red.


When analyzing TCP packets, Wireshark can be very helpful and color code the packets in order of danger level. If you can't remember the color code go back to Task 3 and refresh on how Wireshark uses colors to match packets.

TCP can give useful insight into a network when analyzing however it can also be hard to analyze due to the number of packets it sends. This is where you may need to use other tools like RSA NetWitness and NetworkMiner to filter out and further analyze the captures.

### TCP Traffic Overview

A common thing that you will see when analyzing TCP packets is known as the TCP handshake, which you should already be familiar with. It includes a series of packets: syn, synack, ack; That allows devices to establish a connection.


Typically when this handshake is out of order or when it includes other packets like an RST packet, something suspicious or wrong is happening in the network. The Nmap scan in the section above is a perfect example of this.

### TCP Packet Analysis

For analyzing TCP packets we will not go into the details of each individual detail of the packets; however, look at a few of the behaviors and structures that the packets have.

Below we see packet details for an SYN packet. The main thing that we want to look for when looking at a TCP packet is the sequence number and acknowledgment number.


In this case, we see that the port was not open because the acknowledgment number is 0.

Within Wireshark, we can also see the original sequence number by navigating to edit > preferences > protocols > TCP > relative sequence numbers (uncheck boxes).



Typically TCP packets need to be looked at as a whole to tell a story rather than one by one at the details.

## DNS Traffic

### DNS Overview

DNS or Domain Name Service protocol is used to resolves names with IP addresses. Just like the other protocols, you should be familiar with DNS; however, if you're not you can refresh with the [IETF DNS Documentation](https://www.ietf.org/rfc/rfc1035.txt).

There are a couple of things outlined below that you should keep in the back of your mind when analyzing DNS packets.

- Query-Response
- DNS-Servers Only
- UDP

If anyone of these is out of place then the packets should be looked at further and should be considered suspicious.

Below we can see a packet capture with multiple DNS queries and responses.


Instantly looking at the packets we can see what they are querying, this can be useful when you have many packets and need to identify suspicious or unusual traffic quickly.

### DNS Traffic Overview

DNS Query:

Looking at the below query we really have two bits of information that we can use to analyze the packet. The first bit of information we can look at is where the query is originating from, in this case, it is UDP 53 which means that this packet passes that check, if it was TCP 53 then it should be considered suspicious traffic and needs to analyzed further. We can also look at what it is querying as well, this can be useful with other information to build a story of what happened.


When analyzing DNS packets you really need to understand your environment and whether or not the traffic would be considered normal within your environment.

DNS Response:

Below we see a response packet, it is similar to the query packet, but it includes an answer as well which can be used to verify the query.


### Practical DNS Packet Analysis

:::danger
TODO: update to not include attackbox + provide link for download
:::

Now that we understand the basics of how DNS traffic looks and interacts. Go to the folder `/root/Rooms/Wireshark101` on the AttackBox and double click the `task10.pcap` file to open it in Wireshark; you can also download the pcap on this task.

This capture only has two protocols so it is up to you whether or not you decide to filter the ICMP protocol or not.

:::success
**Questions:**
1. What is being queried in packet 1?
2. What site is being queried in packet 26?
3. What is the Transaction ID for packet 26?
:::

## HTTP Traffic

HTTP or Hypertext Transfer Protocol is a commonly used port for the world wide web and used by some websites. However, its encrypted counterpart (HTTPS) is more common; we will discuss it in the next section. HTTP is used to send GET and POST requests to a web server in order to receive things like webpages. Knowing how to analyze HTTP can be helpful to quickly spot things like SQLi, web shells, and other web-related attack vectors.

### HTTP Traffic Overview

You should already have a general understanding of how HTTP works before completing this room; however, if you need a refresher you can read the official paper by the [IETF on HTTP methods](https://www.ietf.org/rfc/rfc2616.txt).

HTTP is one of the most straight forward protocols for packet analysis, the protocol is straight to the point and does not include any handshakes or prerequisites before communication.


Above we can see a sample HTTP packet. Looking at an HTTP packet like this one, we can easily gather information as the data is not encrypted (unlike in an HTTPS packet). Some of the important information we can gather from the packet are the Request URI, File Data, and Server.

Now that we understand the basic structure of an HTTP packet we can move on to looking at a sample HTTP packet capture to get hands-on with the packets.

### Practical HTTP Packet Analysis

:::danger
TODO: update to remove attackbox instructions and add local instructions
:::

To get an understanding of the flow of HTTP packets and get hands-on with the packets, we can analyze the http.cap file. Go to the folder `/root/Rooms/Wireshark101` on the AttackBox and double click the `task11.pcap` file to open it in Wireshark; you can also download the pcap on this task.


After opening the PCAP we can see that this is just a simple HTTP packet capture with a few requests.

Navigating deeper into the packet capture we can look at the details of one of the HTTP requests for example packet 4.


From this packet we can identify some very important information like the host, user-agent, requested URI, and response.

We can use some of Wireshark's built-in features to help digest all of this data and organize it for further future analysis. We can begin by looking at a very useful feature in Wireshark to organize the protocols present in a capture the Protocol Hierarchy. Navigate to Statistics > Protocol Hierarchy.


This information can be very useful in practical applications like threat hunting to identify discrepancies in packet captures.

The next feature in Wireshark we will look at is the Export HTTP Object. This feature will allow us to organize all requested URIs in the capture. To use Export HTTP Object navigate to file > Export Objects > HTTP.


Similar to the Protocol Hierarchy this can be useful to quickly identify possible discrepancies in captures.

The last feature we will cover in this section of this room is Endpoints. This feature allows the user to organize all endpoints and IPs found within a specific capture. Just like the other features, this can be useful to identify where a discrepancy is originating from. To use the Endpoints feature navigate to Statistics > Endpoints.


HTTP is not a common protocol to see too much as HTTPS is now more commonly used; however, HTTP is still used often and can be very easy to analyze if given the opportunity.

:::success
**Questions:**
1. What percent of packets originate from Domain Name System?
2. What endpoint ends in .237?
3. What is the user-agent listed in packet 4?
4. Looking at the data stream what is the full request URI from packet 18?
5. What domain name was requested from packet 38?
6. Looking at the data stream what is the full request URI from packet 38?
:::

## HTTPS Traffic

HTTPS or Hypertext Transfer Protocol Secure can be one of the most annoying protocols to understand from a packet analysis perspective and can be confusing to understand the steps needed to take in order to analyze HTTPS packets.

## HTTPS Traffic Overview

Before sending encrypted information the client and server need to agree upon various steps in order to make a secure tunnel.

1. Client and server agree on a protocol version
2. Client and server select a cryptographic algorithm
3. The client and server can authenticate to each other; this step is optional
4. Creates a secure tunnel with a public key

We can begin analyzing HTTPS traffic by looking at packets for the handshake between the client and the server. Below is a Client Hello packet showing the SSLv2 Record Layer, Handshake Type, and SSL Version.


Below is the Server Hello packet sending similar information as the Client Hello packet however this time it includes session details and SSL certificate information


Below is the Client Key Exchange packet, this part of the handshake will determine the public key to use to encrypt further messages between the Client and Server.


In the next packet, the server will confirm the public key and create the secure tunnel, all traffic after this point will be encrypted based on the agreed-upon specifications listed above.


The traffic between the Client and the Server is now encrypted and you will need the secret key in order to decrypt the data stream being sent between the two hosts.


### Practical HTTPS Packet Analysis

:::danger
TODO: update instructions for downloading pcap
:::

In order to practice and get hands-on with HTTPS packets, we can analyze the `snakeoil2_070531` PCAP and decryption key. Go to the folder `/root/Rooms/Wireshark101` on the AttackBox and extract the folder `task12.zip`; you can also download this on this task.

We first need to load the PCAP into Wireshark. Navigate to File > Open and select the snakeoil2 PCAP.


From looking at the above packet capture we can see that all of the requests are encrypted. Looking closer at the packets we can see the HTTPS handshake as well as the encrypted requests themselves. Let's take a closer look at one of the encrypted requests: Packet 11.


We can confirm from the packet details that the Application Data is encrypted. You can use an RSA key in Wireshark in order to view the data unencrypted. In order to load an RSA key navigate to `Edit > Preferences > Protocols > TLS > [+]` . If you are using an older version of Wireshark then this will be SSL instead of TLS. You will need to fill in the various sections on the menu with the following preferences:

IP Address: 127.0.0.1

Port: start_tls

Protocol: http

Keyfile: RSA key location


Now that we have an RSA key imported into Wireshark, if we go back to the packet capture we can see that the data stream is now unencrypted.


We can now see the HTTP requests in unencrypted data streams. Looking further at one of the details of the packet we can see the unencrypted data stream closer.


Looking at the packet details we can see some very important information such as the request URI and the User-Agent which can be very useful in practical applications of Wireshark such as threat hunting and network administration.

We can now use other features in order to organize the data stream, like using the export HTTP object feature, to access this feature navigate to File > Export Objects > HTTP


:::success
**Questions:**
1. Looking at the data stream what is the full request URI for packet 31?
2. Looking at the data stream what is the full request URI for packet 50?
3. What is the User-Agent listed in packet 50?
:::

:::danger
TODO: conclusion
:::

-->