###### tags: `finished`
:::success
# SNN Lab 5 - TLS
:::

## Task 1 - TLS handshake
#### Inspect TLS handshake:

:::info
1. Using openssl , establish a TLS connection to facebook.com . Look at the parameters of your connection and briefly describe them in your report.
:::

Using this command, we establish a connection to Facebook via port 443.

openssl s_client --connect www.facebook.com:443

<center>

Figure 1 - TLS connection
</center>

After execution, the command shows two certificates (they are in the first two lines). Below is a chain of certificates and a server certificate in base 64 encoding.

<center>

Figure 2 - TLS connection
</center>

To be honest, in [this source](https://www.feistyduck.com/library/openssl-cookbook/online/ch-testing-with-openssl.html) the output of the command is described in such detail that all you should do is simply rewrite the TLS version (in our case TLSv1.3) and the cipher suite used (TLS_CHACHA20_POLY1305_SHA256).

Another interesting detail is the verification code, which in our case takes the value 0, which means that the verification was successful and the server with a valid public certificate does not have incorrectly configured trusted roots.

:::info
2. Establish the connection again and intercept TLS handshake using tcpdump/wireshark. Describe all packets involved in the TLS connection in your report.
:::

I used Wireshark to intercept TLS handshakes. Facebook's IP address is 157.240.205.35.

<center>

Figure 3 - Wireshark
</center>

As you can see in the screenshot above, the connection to this IP address is via TCP. As you can see in the screenshot above, the connection to this IP address is via TCP. We observed the same connection algorithm in the 6th CIA laboratory work when we checked the security of our own server.

<center>

Figure 4 - Something like that
</center>

After the connection security check is over, the handshaking process begins. External TLS handshake is a greeting from the client. Then the server sends a return greeting and encrypts all subsequent handshake messages (this is a feature of 1.3). The server selects the encryption method, adds its certificate and sends a response to the client. The client verifies the received certificate and initiates key exchange. The server then checks the client's MAC and sends the "finished" message to the client in encrypted form. The client decrypts the received message, checks the MAC. After that, the client and server exchange application data.

:::info
3. What version of TLS is used? Describe which versions are not safe to use and under which conditions.
:::

In our case, TLS v 1.3 is used, this is the latest version. The creators claim that the final version of TLS 1.3 is more secure and productive: all known (to date) TLS 1.2 vulnerabilities are closed in its encryption algorithms, and the "handshake" process is twice as fast as its predecessor (thanks to 0-RTT).

The old versions of SSL 2.0, SSL 3.0, TLS 1.1, TLS 1.2 (this version is still used on some older systems) are already insecure and out of use.

For example, [one of the recent vulnerabilities](https://raccoon-attack.com/RacoonAttack.pdf) allows you to define a pre-master key that can be used to decrypt TLS connections, including HTTPS, when intercepting transit traffic (MITM). affects only connections using ciphers based on the DH key exchange protocol (Diffie-Hellman, TLSDH"). With ECDH ciphers, the problem does not manifest itself, and they remain secure. Only TLS protocols up to and including version 1.2 are vulnerable.

:::info
4. What ciphersuite is used? Make a small list of ciphersuite that you would recommend to use and why.
:::

Сiphersuite uses TLS_CHACHA20_POLY1305_SHA256.

> **Encryption:** AEAD ChaCha stream cipher and Poly1305 authenticator (CHACHA20 POLY1305)
**Hash:** Secure Hash Algorithm 256 (SHA256)

For TLSv1.3 defined Cipher suites is:
1. TLS_AES_128_CCM_8_SHA256
1. TLS_AES_128_CCM_SHA256
1. TLS_AES_128_GCM_SHA256
1. TLS_AES_256_GCM_SHA384
1. TLS_CHACHA20_POLY1305_SHA256

Algorithms numbered 4 and 5 (TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256 ) are the best solutions at the moment, thanks to security and speed. They are also more often installed by default in systems .

In this case, it is easier to immediately focus on those that the OpenSSL community moved the problematic "TL_DH_*" ciphers in [release 1.0.2](https://www.openssl.org/news/secadv/20200909.txt) to the category of ciphers with an insufficient level of protection disabled by default ("weak-ssl-ciphers"). I do not recommend using them 100%, and everything else is optional.

## Task 2 - Man In The Middle

:::info
1. Setup a TLS proxy - mitmproxy
a. There are several modes it can operate. You should use transparent mode.
b. Describe setup steps and show that are able to read transmitted data.
:::

Install mitmproxy:

sudo apt install mitmproxy
mitmproxy --mode transparent

Initially, you can see that mitmproxy listens to port 8080, so we will change the proxy settings in the browser. And add the certificate `~/.mitmproxy/mitmproxy-ca-cert.cer`.

<center>


Figure 5 - Browser's settings
</center>

After adding the mitmproxy certificate, FIrefox loads the requested pages.

<center>


Figure 6 - Result
</center>

:::info
2. Intercept TLS handshake before proxy and after proxy and describe how MITM is performed.
a. When do you think TLS proxy is used for security purposes in the industry?
b. What are techniques that are used to protect applications (desktop, web, mobile, etc.) from TLS proxying?
:::

<center>

Figure 7 - Traffic without proxy



Figure 8 - Traffic with proxy
</center>

Since the proxy in my case listens via port 8080 (localhost), you can see that the loopback interface is involved in transmitting traffic between the responses of my host 10.1.1.207 and the Facebook server 157.240.205.35.

:::info
a. When do you think TLS proxy is used for security purposes in the industry?
:::

It is needed so that no one can listen to you and find out some important information (most often passwords, if we talk about working on the network). And also in order to protect against tampering and modification of traffic during transmission. It is in these two things that the purpose of TLS consists.

:::info
b. What are techniques that are used to protect applications (desktop, web, mobile, etc.) from TLS proxying?
:::

Well, the first method that is used in Russia is a restriction on the use of proxies at the legislative level. This is more than logical, because 100% of the methods of protection do not exist.

However, the more you look for information about protection from proxying, the more you find examples of useful use of proxies, for example, this article talks about [using proxies to solve corporate tasks](https://infatica.io/blog/how-residential-proxies-are-useful-for-businesses-six-real-use-cases/).

It seems to me that proxies are most often run on Linux and BSD, and are used more often under Windows. Users often do not think about changing the User-Agent, which includes the OS used, in the browser, and this may be useful to us.

For example, Project [p0f](https://lcamtuf.coredump.cx/p0f3/) passively listens to traffic, it can determine the OS, MTU and browser, notify about the mismatch of the OS of the package creator and the OS in the User-Agent. Now this utility is available in Kali Linux.

:::info
3. Proxy allows you not only to read data, but also modify it on the fly. Think of a scenario when it can be dangerous and try to demonstrate that.
:::

I really liked one scenario, so I want to implement it for the current moment. Let's replace some student's request about the weather in Innopolis with the weather, say, in Krasnodar, in order to deceive his expectations and force him to go outside without a hat.

to do this, we need to enter the necessary information for interception `[~u /Innopolis & -q]`, in particular, when someone wants to refer to the weather of Innopolis, we will receive the following requests in the traffic flow:

<center>

Figure 9 - Сaught request
</center>

After that, you need to press "e" to select what we want to edit. I choose the "path" and press "enter".

<center>

Figure 10 - Edit request

Figure 11 - Edit needed component of request and press "esc"
</center>

We enter Krasnodar instead of Innopolis.

<center>

Figure 12 - New request
</center>

And press `a` to resume the intercepted flow.

<center>

Figure 13 - Result
</center>

The only thing is, until the request intercepted in mitmproxy is edited and confirmed for connection, the user's page will be loaded indefinitely. So it's faster for a student to look out the window or look at the weather on another resource than I have time to edit the request, huh.

## References:
1. [OpenSSL Cookbook: Chapter 2. Testing TLS with OpenSSL](https://www.feistyduck.com/library/openssl-cookbook/online/ch-testing-with-openssl.html)
2. [Rfc8446](https://datatracker.ietf.org/doc/html/rfc8446)
3. [TLS proxy](https://avinetworks.com/glossary/tls-proxy/)