HTTPS MITM of various GitHub IP addresses in China #27
Description
On 2020-03-26, users in China reported an HTTPS MITM of pages.github.com. I found this out from #ooni IRC.
@tomac4t archived the MITM certificates and uncovered more details:
https://gist.github.com/tomac4t/396930caa8c32f97c80afd9567b4e704
DNS resolution is not being tampered with. The MITM is IP address–based, not domain-based, and affects at least these IP addresses:
- 185.199.108.153
- 185.199.109.153
- 185.199.110.153
- 185.199.111.153
It affects at least the following domains:
- pages.github.com
- *.github.io
- desktop.github.com
- githubstatus.com
- developer.github.com
- services.github.com
The list notably does not include other GitHub domains such as github.com, api.github.com, gist.github.com, and others. @tomac4t reports that it's possible to domain-front one of the affected domains with one of the unaffected domains.
The discussion on #ooni says that other IP addresses are affected, besides GitHub ones.
- 157.185.169.208 (www.jd.com) discussion thread (archive)
- 210.61.181.25 (www.jd.com)
- 104.27.175.29 discussion thread (archive)
The most peculiar feature of the MITM certificates is
emailAddress = 346608453@qq.com
Also interesting:
Not Before: Sep 26 09:32:37 2019 GMT
Not After : Sep 23 09:32:37 2029 GMT
Here is an article about the situation and a translation into English:
Today, many Chinese netizens have complained that accessing Github Pages from a Chinese IP will load an invalid certificate, while using a foreign IP access will load a normal certificate, suspecting that the domain has been attacked by a middleman.
Man-in-the-middle attack (English: man-in-the-middle attack, abbreviated: MITM) in the field of cryptography and computer security refers to an attacker creating separate connections with each end of a communication and exchanging the data it receives so that both ends of the communication think they are talking directly to each other over a private connection, when in fact the entire session is completely controlled by the attacker. In a man-in-the-middle attack, an attacker can intercept calls from both sides of the communication and insert new content. In many cases this is simple (for example, a man-in-the-middle attacker in the receiving range of an unencrypted Wi-Fi wireless access point can insert himself as a man-in-the-middle into this network).
The prerequisite for a man-in-the-middle attack to be successful is that the attacker can disguise himself as each of the participating endpoints of the session and not be recognized by the other endpoints. A man-in-the-middle attack is an attack of (lack of) mutual authentication. Most encryption protocols specifically incorporate some special authentication methods to block man-in-the-middle attacks. For example, the SSL protocol can verify that the certificate used by one or both parties involved in the communication is issued by an authoritative and trusted digital certificate authority and can perform two-way identity authentication.
In a nutshell, so-called man-in-the-middle attacks are carried out by intercepting normal network communication data and performing data tampering and sniffing, without the knowledge of the parties to the communication.
The IP address resolution of pages.github.com is not a problem, the IP address resolved from China is 185.199.111.153, which belongs to Github.
Opening this untrusted certificate shows that the issuer of the certificate is 346608453@qq.com.
Establishing secure HTTPS communication that prevents man-in-the-middle attacks requires the following steps.
- The server is correctly configured with the corresponding security certificate
- Client sends request to server
- The server returns the public key and certificate to the client
- The client will verify the security of the certificate upon receipt, and if passed, a random number will be generated, encrypted with the public key, and sent to the server
- The server will use the private key to decrypt the encrypted random number and then use the random number as the private key to symmetrically encrypt the data to be sent.
- The client receives the encrypted data using a private key (i.e. the generated random value) to decrypt the data and parse the data to present the results to the client
- SSL encryption established
Thanks to @tomac4t for reviewing a draft of this post.