New https ideas for Google Gmail

Original link: http://www.williamlong.info/archives/2058.html

Recently, Google's attack on Gmail, the full default enabled the always HTTPS access to Gmail. However, for hackers who can use the power of the entire country, from the network communication data (this does not discuss the user computer Trojan hack https, Only discuss the method of cracking HTTPS in network communication data) crack HTTPS except brute force hack (brute force https even if the current cluster computing power still needs hundreds of to tens of thousands of years) outside of the law is there really no other? That is not the case.

We know that the security of HTTPS is mainly guaranteed by the public and private keys in the SSL certificate. When the browser communicates with the server through HTTPS (regardless of how the SSL proxy requires the user to submit the certificate, we are now talking about the browser access to the Web site, which is independent of the SSL proxy) and will follow these steps to ensure the security of the communication:

1. The browser connects to the server and the server sends the public key of the SSL certificate to the browser

2. The browser verifies that the domain in this certificate is consistent with the domain accessed (for example, when a user accesses https://mail.google.com/, the browser verifies that the domain in the public key of the SSL certificate sent by the server is mail.google.com or *. google.com) has not expired

3. If the browser fails to authenticate, the browser notifies the user that there is a problem with the certificate and lets the user choose whether to continue

4, if the browser verification is successful, then the browser randomly generates a symmetric key and use the public key of the received SSL certificate to encrypt and send to the server

5. The server decrypts the received information through the private key of the SSL certificate and obtains a randomly generated symmetric key from the browser.

6. The last server and browser are communicating through this symmetric key (why not use the public and private keys to communicate directly?). Because asymmetric encryption is less efficient than symmetric encryption)

This scenario looks perfect, but it is not able to withstand a man-in-the-middle attack, and the attacker can take the following steps to intercept all data in HTTPS traffic:

1, the attacker forged a Gmail SSL certificate, the domain is mail.google.com or *.google.com, and set the appropriate certificate expiration time

2. When an attacker waits for a visitor's browser to access Gmail, it can be accessed to the attacker's server via DNS hijacking or IP forgery (which is a breeze for hackers with router control privileges)

3. The attacker sends a fake SSL certificate public key to the browser

4, the browser to verify the SSL certificate domain and expiration time is right, think that the access to the Gmail itself, so that the symmetric key sent to the hacker server

5. The hacker server encrypts the fake Gmail webpage by encrypting the received symmetric key and sends it to the browser.

6, the visitor enters the Gmail account through the browser, sends to the hacker server, the hacker server obtains the visitor's Gmail password successfully through the received symmetric key decryption

To protect against this man-in-the-middle attack, SSL certificates need to be issued by a trusted SSL certification authority to form a chain of certificates (such as Gmail's certificate chain: The bottom is the domain mail.google.com, the previous layer is the Thawte SGC CA certification Authority, The top tier is a well-known VeriSign certification authority). In addition, the browser needs to verify the domain and validity period, but also to check the certificate chain of the parent certificate public key is valid, the superior certificate public key is valid until the root certificate public key. This can effectively avoid the man-in-the-middle attack, because the root certificate public key is preinstalled in the operating system, if the hacker is not brute force, unable to get the root certificate of the private key, if the hacker himself generated a private key, When the browser verifies the root certificate's public key, it discovers that the public key cannot be decrypted by encrypting the data with the public key preinstalled in the operating system, and thus determines that it is invalid. This scenario is also the usual scenario for HTTPS communication.

So is this the HTTPS communication solution that all browsers are using now? The answer is still negative. We can see that in the latter scenario, the security of HTTPS requires a strong assurance of the credibility of the certification authority to play a role. If the certificate authority has not verified the hacker for Mail.google.com's bearer, has issued the domain to the hacker the mail.google.com certificate, then the hacker's man-in-the-middle attack can implement smoothly:

1. An attacker from an SSL certification authority that does not verify the mail.google.com holder wosign there is a domain-mail.google.com certificate, the certificate chain is: The lowest level is the domain mail.google.com, the previous layer certification authority is wosign, the top level certificate Book issuing agency for VeriSign

2/3, second, third step the second and third steps of the man-in-the-middle attack of one programme

4, the browser to verify the SSL certificate domain and expiration time is correct, continue to verify the certificate chain:

4.1, the bottom of the domain mail.google.com Certificate public key is not in the operating system, can not verify that they are accessing the Gmail itself, continue to verify the previous level of certification authority

4.2, the previous level certification Authority Wosign's public key is not in the operating system, still cannot verify its validity, continue to verify the previous level of certification authority

4.3, the browser sees the top-level certification Authority VeriSign's public key in the operating system, the certificate chain is considered valid, thus the symmetric key sent to the hacker server

5/6, V, sixth steps the fifth and sixth steps of the man-in-the-middle attack of a programme. Hackers successfully get the visitor's Gmail password

However, failure to verify that the name holder has issued a certificate is unlikely to happen abroad, but not necessarily at home. Against the target, the domestic certification authority wosign (in this case is only a relatively well-known domestic certification authority wosign, does not mean that wosign will do so in the future) it is possible for the superior request issued a certificate to non-domain name holders of hackers, So that the target of the Gmail password hack intercepted.

So, the domestic target is not to use HTTPS Gmail also can not guarantee security? Welcome to discuss with me.

Source: Reader lehui99 contributions, contributors email: [Email protected],google wave: [email protected].

New https ideas for Google Gmail