Hacker preaching: parsing man-in-the-middle attacks with SSL Spoofing

In the previous article, we have discussed four forms of man-in-the-middle attacks: ARP cache poisoning, DNS spoofing, and session hijacking. In this article, we will study SSL spoofing, which is also the most powerful form of man-in-the-middle attack, because SSL spoofing can launch attacks by using services trusted by people. First, we will discuss the theory of SSL connections and their security issues. Then, we will look at how SSL connections are used to launch attacks. Finally, we will share with you the detection and defense skills on SSL spoofing.

SSL and HTTPS

Secure Sockets Layer (SSL) or Transport Layer Security (TLS) is designed to provide security protection for network communication through encryption, this Protocol is usually used together with other protocols to ensure secure deployment of services provided by the Protocol, such as SMTPS, IMAPS, and the most common HTTPS. The ultimate goal is to create a secure channel in an insecure network.

In this article, we will focus on the attack on SSL through HTTP (that is, HTTPS), because this is the most common form of SSL. You may not realize that you are using HTTPS every day. Most mainstream email services and online banking programs rely on HTTPS to ensure secure communication between users' browsers and servers. Without HTTPS technology, anyone using a packet sniffer can steal user names, passwords, and other hidden information from the user's network.

HTTPS is used to ensure the security of data communication between servers, customers, and trusted third parties. For example, if a user tries to connect to a Gmail email account, this involves several different steps, as shown in 1.

Figure 1: HTTPS communication process

The process shown in Figure 1 is not particularly detailed, but describes the following basic processes:

1. The client browser uses HTTP to connect to the http://mail.google.com on port 80

2. The server tries to use HTTP code 302 to redirect the HTTPS version of the client.

3. The client connects to the site https://mail.google.com on port 443

4. The server provides the client with a certificate containing its electronic signature. The certificate is used to verify the website. 5. The client obtains the certificate and verifies the certificate based on the list of trusted Certificate Authorities.

6. establish encrypted communication

If the certificate verification process fails, the authenticity of the URL cannot be verified. In this way, the user will see a certificate verification error on the page, or they can choose to continue to visit the website at risk because the website they visit may be fraudulent.

HTTPS cracked

This process has been considered safe until several years ago, when an attacker successfully hijacked the communication process, it does not involve attacking SSL itself, it is an attack on the "bridge" between non-encrypted communication and encrypted communication.

Moxie Marlinspike, a well-known security researcher, argues that SSL has never been directly threatened in most cases. An SSL connection is usually initiated through HTTPS, because the user is located to HTTPS through the HTTP 302 response code or they click the connection to locate it to an HTTPS site, such as the login button. That is to say, If attackers attack the communication from a non-secure connection to a secure connection, that is, from HTTP to HTTPS, the actual attack is the "bridge", and the man-in-the-middle attack when the SSL connection has not yet occurred. To effectively describe this concept, Moxie has developed the SSLstrip tool, which we will use below.

This process is very simple. It is similar to the attack mentioned in the previous article, as shown in figure 2.

Figure 2. hijack HTTPS Communication

The process described in Figure 2 is as follows:

1. The traffic between the client and the web server is intercepted.

2. In case of https urs, sslstrip replaces it with the HTTP link and saves the ing of this change.

3. The attacker simulated client provides a certificate to the server.

4. receive traffic from the security website and provide it to the client

The process went smoothly, and the server thought it was still receiving SSL traffic, so the server could not identify any changes. Users can feel that the only difference is that the browser does not mark HTTPS, so some users can still see that something is wrong.