Kazakhstan Attempts to MITM Its Citizens

• Government of Kazakhstan asks its citizens to install digital certificate
• The request comes under the pretext of improving the nation’s security
• Installing the certificate allows the government to intercept and decrypt traffic of any website it wishes
• Citizens must choose between having their web traffic intercepted or face being blocked from accessing the web’s most popular sites such as Google and Facebook
• This tactic of mass surveillance will have many unintended negative consequences that will be felt for years to come

An increasing number of businesses are legitimately intercepting encrypted traffic on their networks. It’s pretty much a necessity today. As the amount of encrypted web traffic surpasses 90%, it’s essential to inspect all traffic to ensure that Joe in Marketing isn’t accidentally downloading malware onto his corporate laptop during a lunch break.¹ While many organisations will allow some encrypted traffic to bypass security filters (such as employees’ visits to banking and healthcare sites) the risk of not intercepting web browsing traffic is just too high since malware often uses encryption to evade security controls. Without decrypting web traffic, products such as anti-virus scanners and data leakage prevention (DLP) tools are all but useless since each one alone is often unable to perform decryption. Crucially, this interception of encrypted traffic by businesses is not only contractually permitted, it’s easy for them to conduct since they own the assets and the working time of the employee.

Whether a cybercriminal is trying to steal data or a national government is attempting to perform mass surveillance, without direct control over end user devices (such as laptops and mobile phones), it’s much more difficult to intercept encrypted traffic. To be able to legitimately intercept encrypted traffic, is it essential to install a trusted digital certificate on to the device in question.

For years the nation of Kazakhstan has asked Mozilla to add the nations root certificate to the list of other root certificates² in their popular Firefox web browser. Fearing government overreach and misuse, Mozilla have always declined. And for good reason. There are many examples when root certificates have been abused allowing potentially anyone to spy on the encrypted web traffic of others.^{3, 4}

Last week, however, Kazakhstan gave up asking nicely and instead simply instructed its citizens to manually install the national security certificate which, in a flash of social engineering inspiration, is simply called “Security Certificate.”

You may be surprised to see the comforting symbol of the green padlock and be asking yourself why no security warnings were shown. Browsers are constantly on the lookout for rogue certificates and malicious interception. However, when someone installs a root certificate, they are explicitly telling their browser that they trust any certificate that this new root certificate then subsequently signs. So, the browser has no reason to distrust this certificate for www.google.com.

What Happened

First spotted on July 18, 2019, some citizens in Kazakhstan began receiving notifications from their ISPs that they were required to install a security certificate or face interruption to their web traffic. European telecommunications operator Tele2 sent SMS messages to its customers¹ (see Figure 2) and also created a web page to explain how to install the “safety certificate.”

Figure 2. SMS message sent from Tele2 to one of its customers in Kazakhstan

The website at http://qca.kz hosts a simple page allowing visitors to automatically or manually install the required root certificate signed by Qaznet. Although the page was unavailable at the time of this writing, Google’s cached and translated copy can be seen in Figures 3 and 4.

As shown in Figure 5, citizens are instructed that they must manually install the certificate on every device they own. Separate instructions are given for iOS and Android, and Chrome, Firefox, and IE web browsers.¹

Each ISP is responsible for contacting its own customers and providing instructions for how to install the certificate, some of which are listed in Table 1.

Table 1. Kazakh telecommunications providers and links to their instructions on installing the new root certificate

* Activ appear to be making use of its own root certificate kcell-ca.crt in order to perform SSL interception.

By installing the Qaznet root certificate, each citizen’s device or web browser will trust any intermediate certificate authority. In all observed cases, the intermediate certificate has been named “Security Certificate.” This, in turn, signs the forged certificate for sites that the government wishes to intercept.

Affected Sites

Not every site on the web is being intercepted by Kazakhstan’s Internet service providers. In fact, the list is actually very small. It’s been claimed that not all ISPs are yet performing the interception. Other reports state that only citizens of the nation’s capital are having their traffic snooped. Determining exactly which sites are on the target list is, therefore, not that easy. To observe the interception, we needed to make a request whilst on the network of an affected ISP. To accomplish this, we had a few options:

• Stand up a virtual server in a local cloud provider
• Find a VPN endpoint that terminates in the affection region
• Find an open web proxy to send traffic out on our behalf

Having no luck with the first two options, we were forced to settle on the third option: finding an open proxy (which are typically slow and unreliable). So, pointing some SSL/TLS testing tools at the Alexa top 1000 sites and 50 of the most popular news and social media platforms hosted in Kazakhstan, these are the sites we were able to determine were being actively intercepted:

• android.com
• facebook.com
• fb.com
• g.co
• goo.gl
• google.com
• instagram.com
• googleusercontent.com
• mail.ru
• ok.ru
• twitter.com
• vk.com
• vkontakte.ru
• youtu.be
• youtube.com

The list looks relatively small but contains some of the most popular sites on the web. Interception of google.com, android.com and mail.ru allows the Kazakh government to intercept and read some of the most popular messages services on the Internet. Curiously, some very popular messaging and social media sites, such as WhatsApp, Telegram, and WeChat were not being actively intercepted when we performed our scans. The threat that Kazakh citizens face is that once they have installed the nation’s security certificate, the government may remove or add sites to the intercept list with no obvious notification to the citizens.

It is worth noting that the platforms currently being intercepted are ones that helped facilitate revolutions in the past. It’s likely that the next revolutionary/terror cell will use other platforms such as Discord or Telegram.

Despite being limited to the use of open proxies, our results do, reassuringly, closely match those found by the University of Michigan in its recent report for Censored Planet.¹ The use of open proxies severely limits the testing and probing that’s possible. Censored Planet’s report gives a little more information on the affected networks and routes.

Setting a Trend or Following One?

This is not the first time a government has attempted to intercept the encrypted communications of its citizens, but it is the first blatant and transparent attempt. In August 2014, it was reported that the Chinese government was behind the interception of SSL/TLS traffic to Google from the country’s education network, CERNET.² This followed the interception of traffic to Github just one year prior. 

In contrast to the recent move in Kazakhstan, however, the Chinese government did not have root certificates installed on end user’s devices. Due to this, security warnings were always present when interception was occurring, as can be clearly seen in Figure 9.

Depending on the success of the security certificate roll-out in Kazakhstan, we may well see other countries around the world implementing, similar policies.

Security Controls

As of now, it’s a personal decision of each Kazakhstan citizen whether they install this certificate. Users who choose not to install the certificate, or simply don’t know how to, will face browser warnings when they attempt to visit any site the government wishes to eavesdrop on. It is likely that many users will click through warnings they see, unaware that, in doing so, they are still allowing access to their encrypted communications.

1. User attempts to browse to a controlled website, such as google.com, and sees a security warning.
2. Clicking on Advanced allows the user to accept an exception, thereby ignoring the warning.
3. The user is able to browse to the website as normal, albeit with all encrypted traffic accessible to the ISP and any government surveillance.

For organisations that wish to ensure that their Kazakh visitors are not having their traffic intercepted, it is worth understanding what can and can’t be done using HTTP Security Headers.

HTTP Security Headers

Security headers, such as HTTP Strict Transport Security (HSTS) and HTTP Public-Key Pinning (HPKP) both permit this kind of interception – indeed organisations that make use of SSL intercepting proxies utterly rely on this capability.¹ If this interception were never permitted by industry standards, then security devices such as anti-virus and data leakage prevention (DLP) technologies simply wouldn’t work. The fact is that the root certificate installed by the user provides an anchor of trust which the HSTS and HPKP protocols allow.

In order to prevent interception and also prevent the user from bypassing any warnings, a standalone client must be used—one that does not share the root certificate store with the web browser or device. Only in this situation will the HSTS and HPKP protocols prevent the user from bypassing a security warning. However, this will have the effect of completely preventing access to the application.

In-App Testing

Since the HSTS and HPKP protocols allow for genuine interception of SSL by trusted certificates, nothing can be done to warn end users that their communications are being intercepted. For those that need to inform their users of interception, in-app testing could be considered. By performing an additional SSL/TLS handshake, using Javascript within the webpage, it is possible to compare the certificate fingerprint being sent to the client with the one that is configured on the web server. These should always match, but with SSL/TLS interception, even when the certificate name matches, the fingerprints will be different.

Researchers at Carnegie Mellon University used a similar technique to spot SSL/TLS interception in the wild. By implementing additional TLS handshakes within hidden Flash applets, researchers were able to detect and capture forged certificates for visitors of Facebook.¹

The level of effort to implement this kind of detection may not be worthwhile, however, since a site being intercepted can no longer be trusted.

End User Testing of SSL/TLS Interception

For citizens concerned with SSL/TLS interception, various tools exist to test for its use, including OpenSSL and SSLyze. These are complex command line tools, however. A simple website worth considering is found on GRC’s website: https://www.grc.com/fingerprints.htm.

Risks of Nationwide Interception

Installing this root certificate is not law in Kazakhstan and, in fact, a government official has said that users do not have to install the certificate at all.² This is certainly true and it’s actually very unlikely that most citizens will have the technical competency to complete this task across all devices they own. Those that do understand will also very likely understand what it will mean.

But what happens when users visit a website being intercepted and they don’t have the nation’s digital certificate installed? The first thing users will see is a security warning presented by their browsers. They will be forced to make one of two choices:

1. Heed the warning and proceed no further
2. Ignore the warning (accepting this untrusted certificate) and proceed to the website

It’s reasonable to assume that most non-tech savvy users will simply ignore the warning and continue on with their web browsing. At this point, however, all of their web traffic is still being intercepted and monitored.

This poses two other significant issues. First, users being “trained” into accepting untrusted certificates plays a significant role in desensitising users to the security warnings that are presented to them. If users are accustomed to ignoring security warnings, then we cannot expect them to take any of them seriously.

Secondly, once this root certificate is installed, it will almost certainly never be removed. Since the Qaznet certificate has such as long lifespan (it expires in 2046) there are almost three decades over which threat actors could compromise the private key and begin using it to attack Kazakh citizens.

Finally, and perhaps the biggest problem, is that strong cryptography is not something that can be controlled. While the mass majority may not understand how to “roll their own” crypto, those that have a specific reason to do so—the organised cybercriminal and the terrorist—certainly do. Whether it be a messaging app such as Threema³ that lets users control their own encryption keys, or a bespoke piece of software, tools exist to make cryptographically secure messaging that is impossible to intercept (at least during transit, because interception of communications on the device itself is certainly possible and far more likely).

It will be interesting to follow the developments in Kazakhstan. It would come as no surprise if the country’s leaders were to introduce a law that required the installation of their root certificate on to any new devices sold, thereby solving the challenge of how to load the certificate on devices of non-technical users.

IOCs

It would be disingenuous to talk about indicators of “compromise” when citizens must manually install the root certificate. For academic purposes, however, details of the root and intermediate certificates are shown below:

Root certificate:

Intermediate certificate: