
Most recently I happened to stumble upon a very
curious overseas article . I would like to compare the facts stated there with the Russian experience. Feel free to share your thoughts in comments. Spoiler: chef, everything is gone!
In this article we will look at the problem of intercepting encrypted web traffic and its impact on online security. According to a study published in
NDSS 2017 , today between 4% and 10% of HTTPS traffic is intercepted. Analysis of interceptions has shown that although they do not always do harm, nevertheless, interception tools often weaken the encryption used to ensure the security of communications, which increases the risks for users.
')
How is encrypted traffic intercepted?

As shown in the illustration, the traffic is intercepted by a “
mediator attack ”. Special software redirects an encrypted connection to itself and pretends to be the requested site. The interceptor then opens a new encrypted connection to the target site and proxies the data through itself, between the two connections, which makes the interception mostly “invisible”. Since the interceptor gains access to unencrypted data within the connection, it can read, modify and block any content transmitted or received by the client.
There are two main ways to intercept connections: local and remote.
Local interception : when the interceptor is executed directly on the user's computer, the network stack of the operating system is modified to intercept and redirect connections to the interceptor. This approach is commonly used by antivirus software to monitor network connections to identify malicious downloads and attempts by malware to steal data or embed advertising.
Remote interception : performed by inserting into the network monitoring path connecting the user's computer to the site accessed by the user. For example, this can be done by redirecting network traffic to the interceptor through firewall policies. Network interception is usually performed by “security blocks” (the security box) that attempt to detect attacks or monitor corporate data leaks from all computers on the network. These devices are also often used to intercept and analyze e-mail.

An important aspect of interception is how applications impersonate sites, and user browsers do not notice substitution. Usually, when an HTTPS connection is established, the browser authenticates the site by checking the certificate presented on it. If the certificate fails validation, then the browser issues a warning, as in the picture above, that the connection is potentially unsafe. Therefore, the “impossibility of falsifying” TLS certificates is the cornerstone of online security. This is a technical tool that gives us confidence that we communicate with the right side, and not with an impostor.

The question arises, how can HTTPS interceptors generate valid certificates for all sites if they were created as non-existent? The answer lies in the procedure for determining by the browser the validity of the certificate. If in general, when installing a new connection, the browser looks to see whether the certificate presented on the site is signed by one of the certification authorities. Center certificates are stored locally on a computer,
in a trusted store , so any certificate of a certification authority that is added there can be used to generate a valid certificate for any site.
Therefore, it is easiest for an interceptor to forge certificates not through some sophisticated cryptographic attack, but by adding its own “root” certificate to the storage on the computer. Then the browser will trust any certificate signed by the interceptor. This is not a vulnerability, because adding a certificate is, of course, possible only if the interceptor has access to the computer's file system, or if the certificate has been installed by the sysadmin.
How common is HTTPS interception?
Measuring the number of interceptions is not an easy task, because interceptors do not advertise themselves. So for recording the facts of interception, we used an improved version of the network fingerprint technology, known as TLS fingerprinting. This allowed us to determine which software makes the connection (interceptor or browser). The technology evaluates the design of the client welcome TLS packet (for example, cipher suites and TLS options) and compares it with a database of known fingerprints. Their reliability is very high, especially compared to the user-agent advertised in the HTTP request.

Researchers evaluated the work of a large online store, the Cloudflare site and the Firefox update servers. Estimated amount of browser traffic intercepted by their services. It is important to have a lot of “points of view”, because the result varies depending on where you look from. For example, in general, the proportion of intercepted HTTPS connections varies from 4% to 10%. This is a lot, but it is important to remember that not all interceptions are performed by intruders.

Having smashed the traffic on Cloudflare and the online store by operating systems, it turned out that it intercepts with Windows much more often than with MacOS. Traffic from Android and iOS is intercepted much less frequently than from desktop OS. The full partition can be viewed on page 13 of our report (link at the beginning of the article).

Splitting Firefox update traffic capturing shows a very different picture. Most often intercept mobile providers involved. In part, this can be explained by the fact that the desktop version of Firefox uses a separate storage for root SSL certificates, which makes it a less likely candidate for interception compared to other browsers.
Who and why is engaged in interception on communications?
Contrary to popular belief, intercepting traffic is not necessarily harmful. According to the study, traffic is usually intercepted for two opposite reasons:
•
Improved security : Antivirus and some corporate firewalls / IPS intercept traffic to protect their users. They want to scan encrypted traffic, trying to prevent the penetration of malware or monitor data leakage. Some parent software and ad blockers use a similar approach to block traffic to certain sites.
•
Malicious activity : at the other end of the spectrum is malicious software that intercepts in order to embed advertising or steal confidential data.

Having identified the "prints" of well-known products, the researchers were able to attribute to their account a considerable share of interceptions. In this case, several applications still could not be determined, which may well be malicious software.
How does interception of HTTPS traffic affect security?
If the interception is not done for selfish purposes, then why can it weaken online security at all?

The main reason is that most interception products do not use the best cryptography. And when interception is performed, the connection from the interceptor to the site uses unsafe user data encryption instead of more robust algorithms used in modern browsers.

And because of weak / vulnerable encryption, traffic becomes more vulnerable to attacks. Hackers can also intercept encrypted connections and steal data such as documents, emails and instant messengers. In some cases, for example, with Komodia, the
implementation of cryptography is so bad that an attacker can intercept any encrypted communications with minimal effort.

To calculate the effect of HTTPS interceptions on connection security, researchers analyzed the security of cryptographic stacks used by interceptors. In general, 65% of intercepted connections to Firefox update servers have reduced security, and 37% were easily vulnerable to “intermediary attacks” due to vulgar cryptographic errors (for example, certificates were not validated) [65.7% + 36.8% = 102, 5%, but in the original - approx. translator]. Not much better was the situation with traffic on Cloudflare.
To finish on a “positive” note, you need to mention that in rare cases (4.1% from an online store and 14% from Cloudflare), interception increases the security of connections. But this is mostly a consequence of the ranking of weaker ciphers (RC4 and 3DES).
In general, HTTPS intercepts are more common than expected (4% -10%), and they entail serious risks because they degrade the quality of encryption. Moreover, the HTTPS implementations used to intercept do not have the same automatic update mechanisms as in browsers, which makes the use of fixes less likely. Passive and intercepting intermediate devices
also affected the delayed release of TLS 1.3 in browsers.
We hope that drawing attention to this problem will help software vendors who rely on interception to realize the riskiness of this practice. Well, we have another topic for discussion.