On 17 July 2019, many Internet subscribers in Kazakhstan received an SMS message from their ISPs, asking them to install (and trust) a government-issued certificate on all of their Internet-connected devices for ‘security’ purposes. On the same day, Kazakhstan started intercepting HTTPS traffic in the economy through a Man-in-the-Middle (MitM) attack using a custom root CA. The interception, which was termed as a ‘pilot’, covered large portions of the economy’s network and was active intermittently until being shut down on 7 August 2019.
But exactly how large was this interception? What type of traffic was affected? What were the consequences?
While the interception was active, our research group at the University of Michigan performed measurements to understand the working of the interception system, and which websites were targeted. Ultimately, supported by our findings, two major browser vendors, Mozilla Firefox and Google Chrome, blocked the use of Kazakhstan’s custom root CA.
Scale and targets
The initial measurements from our global censorship observatory, Censored Planet, showed that the HTTPS interception can be triggered remotely from outside Kazakhstan’s borders, and that only certain domains and networks were affected. To study the interception in-depth, we performed large-scale measurements from the University of Michigan and from a virtual private server (VPS) inside Kazakhstan to 6,736 TLS hosts in 85 ASes in Kazakhstan. To identify the services that were targeted, we performed TLS handshakes with the TLS hosts, setting the Server Name Indication (SNI) to different domains from the Alexa Top 10k domains list.
Overall, we found that 7-24% of the 6,736 TLS hosts in Kazakhstan measured experienced TLS interception. A majority of these hosts were located in AS9198 (Kazakhtelecom). In all of these cases, the certificate we observed was signed at the root by Qaznet Trust Network, the custom root CA set up by Kazakhstan. We found that a total of 37 domains triggered the interception, and this list included popular social media and communication websites from Google, Facebook, Mail.ru and Twitter. We found several necessary conditions for the interception to be triggered:
- The client had to send a TLS SNI header containing one of the affected domains.
- The server had to present a valid browser-trusted TLS certificate, but not necessarily a certificate for the domain provided in the SNI header.
- The connection path had to pass through a particular part of AS9198 (Kazakhtelecom).
Location and fingerprint
We performed traceroute-like TTL-limited measurements to discover the exact network location where the interception was being performed. For each TLS host where we were able to trigger interception, we made repeated connections with varying values for the IP time-to-live (TTL) field in the packet containing the SNI header, and we recorded the smallest TTL for which we received an injected certificate response.
We found that 95% of the time, the last hop before the certificate was injected was 92.47.151.210 or 92.47.150.198, and the hop after injection was 95.56.243.92 or 95.59.170.59. All of these addresses are in AS9198 Kazakhtelecom, suggesting a centralized design in which this AS was the only location responsible for HTTPS interception.
We also use TLS fingerprinting techniques to record the TLS fingerprint of the interception system. The fingerprint of the interception system is unique, and thus can be used by service providers to tell when a connection is being intercepted, and warn their users accordingly.
Duration
We continued performing TLS measurements to the 6,736 TLS hosts in Kazakhstan over time, until the interception was halted on 7 August 2019. The interception was switched on and off throughout the measurement period, and we observed several changes to the logic, indicating that the system was being tested or tuned. We also noticed some periodic trends because of routing changes.
Finally, on 7 August 2019, the interception system was shut down, following an announcement from the government that the pilot test of the interception system was successfully completed and that the interception would be switched on again whenever there is a threat to national security.
Implications
Kazakhstan’s HTTPS interception attacks represent an escalation in efforts by various actors to gain access to encrypted communications. It covered a wide network space and lasted for weeks, potentially compromising credentials and other sensitive information for thousands of users. Users in Kazakhstan who were connected to networks affected by the interception had little choice; they either trusted the certificate and gave the MitM access to all of their encrypted communication, or were effectively blocked from accessing these popular services (since most of the affected services have strict transport security enabled).
Informed by our findings, two major browser vendors, Mozilla Firefox and Google Chrome, responded on 21 August 2019, shipping changes that completely blocked use of the Qaznet root, even if manually installed. This would prevent the certificate from being used for MitM attacks in the future. We advocate for an even quicker response if there are similar incidents in the future. Additionally, we recommend further research into and higher adoption of defence mechanisms against large-scale MitM attacks in the HTTPS ecosystem. Network operators and content providers can also share data to enable quicker detection of MitM attempts.
Can it happen again?
Yes and it already has. The large-scale interception attack in July-August 2019 was neither the first nor the last attempt by Kazakhstan at gaining visibility into encrypted communications. As recently as December 2020, the Kazakhstan government performed another drill of their interception system, this time using a new root CA, Information Security Certification Authority (ISCA). According to our ongoing measurements, the interception was only active on 6 December 2020, and targeted the same domains as the earlier attempt, while the scale of the interception increased slightly. Our research lab will continue to track large-scale HTTPS interception attacks, and we urge the Internet community to prepare for such events, by performing closer monitoring and by instituting policies for how to respond.
Ram Sundara Raman is a PhD Candidate at the University of Michigan, USA whose research focuses on global measurement of network interference and censorship.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.