Weak HTTPS. Part 1

Sometimes technically untrained people selling an IT service or product to the question “what about the reliability of your system?” Answer: “Everything is protected by https”. If, on the other hand, the same technically untrained person, then the question is automatically closed, and everyone was satisfied with the level of security. He himself has repeatedly witnessed such a conversation. Was funny.

HTTPS is actively promoted by the Internet community and the main idea is to transfer the entire Internet to a specific year on encrypted traffic, the benefit of modern machines allow it. HTTPS is always good. But you need to know the pitfalls associated with it.
The goal of this article is to show the possibility of listening to the user's HTTPS traffic (let's call him Stepan), and so that he does not notice this.

We will not take the latest research and exploits in the field of HTTPS hacking. Let's go better to the basics and consider the long-known and simple ways.
')
HTTPS is HTTP + SSL. Http is an open data transfer protocol, open means that data is transmitted in open form. SSL is a protocol that provides a secure connection through encryption. That is, our task is precisely to intercept the pure traffic of our Stepan and bring him to clear water, what kind of XXX sites he watches in the evenings. But we are not like our Stepan and we don’t look at XXX, so for example let's take the bing search engine, which can still work using https and http.

Below in the picture is an example of how intercepted traffic looks with WireShark on the same request in bing for HTTP and for HTTPS.





HTTPS truly encrypts all data including URLs that the client generates. But HTTPS is based on TCP / IP, that is, information about where the traffic is sent, can be obtained in an unencrypted form. We are talking about Mac addresses, IP addresses and ports.



Using online tools (for example, whois.domaintools.com) you can find out what the IP address is, who owns it, and with a simple request in bing you can find out which sites are running on this IP address (for example, www.bing.com/search ? q = ip : 204.79.197.200).

Let's continue and think about this. A web server can host several sites, and each can have its own SSL certificate. Therefore, the mere presence of an IP address is insufficient. The web server, when it receives the first request, needs to know with which site it is necessary to establish a connection. No encryption yet, because it still needs to be installed. This means that even before encryption begins, the client must somehow transmit information about the domain of the site so that the web server can bind the client request for the required resource. Therefore, it is necessary to look at the very first request from the client to the server, which initiates the beginning of the encryption itself. Again, take our favorite WireShark and see.





Here we can find something interesting:

1. The first request does contain the domain name of the site in an unencrypted form, with which an HTTPS connection will be initiated.
2. The second request returns the certificate itself in an unencrypted form to the client, which contains information for which domain it was issued. In the case of bing, the certificate also includes an extended Subject Alternative Name field, which lists the domains for which the certificate can be used (in the Bing certificate you can even find addresses on the staging environment).

HTTP proxies like Fiddler (in the figure above) already know how to extract this information from traffic.

It would seem that everything, but there is another way to find out, without resorting to HTTPS cracking, what resources Stepan used to go to. When in the browser it dials the address of the site, the first request goes not to the server, where the site is located, the first request goes to the DNS server to get the IP address for this domain. DNS requests are not encrypted, so only by listening to DNS traffic, you can make a history, what resources Stepan visited, and you can even determine where he was approximately at that time by the IP address of the DNS server.



It's time to bring the results:

1. Without breaking the traffic, we can still track what XXX resources (protected or not) our Stepan visits in the evening.
2. You can write a script to filter and keep the full story that Stepan visited, say, over the past year (we can’t say what he did there, but we can definitely say that he was there).
3. If I have direct access to the traffic (I am the admin who controls the routing, or I am the Internet provider through which the traffic flows), then I don’t even need to take any actions on the client machine to send traffic to me.
4. Wi-Fi or satellite Internet can be weakly protected, and, knowing the client’s address, you can determine with which resources it works.
5. And the most important thing. Stepan did not notice anything, and we are slowly gathering information about him.

But it’s still not enough for us to know what and when our Stepan visited. Our task is to find out what Stepan did on these resources (that is, to get access to HTTP information). To be continued in the second part.

Denis Koloshko, CISSP