Hacking – Is SSL really secure with Root CA ?

Some days ago, I heard about a Root CA was attacked and some CAs was faked up which leads to a serious security vulnerabilities that internet users lose their sensible data although they used https:// for communicating to web server. This issue made me think about a case study that “What would happen if a Root CA was controlled by a government ? Will I be attacked by Man-In-The-Middle in https:// ? Can I protect myself from being attacked like that ? Is SSL really secure at all ?”. So I try myself to find the answers for these questions and think that it can be interesting for you.

A normal user may be does not know anything about https:// or HTTP Secure, for example my wife says simply there is one more “s” in compare to http:// and that’s all. My friend says it’s address of website. We must enter correctly with the “s” at the end otherwise we’ll be prompted for wrong URL. They are perfect, innocent answers, aren’t they? As advanced users, we all know that there is a term of “Man-In-The-Middle” attack in which an attacker acts as a repeater and sniffs all transferred data between user and web server. So if we send and receive data in clear text, he can read our sensible data (username, password) and what he would do with this data, only God knows. Therefore a requirement as well as a solution for encrypting data before sending out of internet world was born, that is HTTP Secure.

HTTP Secure – Hypertext Transfer Protocol Secure (HTTPS) is a combination of the Hypertext Transfer Protocol with the SSL/TLS protocol to provide encrypted communication and secure identification of a network web server. This secure protocol bases on the Public-Private-Key infrastructure which allows to send/receive data over an insecure environment without worrying that someone can listen in. For example, if a user goes to a https:// website, the browser will require the web server to identify itself. The server sends back a copy of its certificate. The browser then checks if it can trust this certificate. If yes, it will generate a public-private key pair, send a message OK with only public-key to web server. The web server receives this message, sends back a digitally signed acknowledgement with its public key back to browser with agreement to start SSL connection. After handshake was successful, encrypted data can be transferred between them.

HTTPS Protocol

If you want to read more about SSL, I would like to introduce you to read this book

SSL and TLS: Designing and Building Secure Systems

The handshake seems to be perfectly secure. But is it really ? No, let’s look at step 3 where the browser validates web server certificate. In each of browser there is a list of trust CA which will be used to check if the certificate of server is the correct one (that means “Did the server really register this certificate before?”). For example in Firefox 4 you can find this list under Options –> Options –> Advanced –> Encryption –> Show Certificate.

Firefox 4 Certificate

In this list, you can see that some CAs was marked as Root, the others are class 2,3. When the browser validates a certificate with class 2,3. At first it will check if the signature of certificate is right, when certificate will be out of date, if the URL is correct… Then it validates the CA with his parent CAs until he meets the Root CA. It sounds complicated, doesn’t it?. Let’s make an example: We have a CA tree like this

Root CA_A
———– CA_B Class 2
———– ————– CA_C Class 3
———– ————– https://catree.com

The browser will check website with CA_C then check CA_C with CA_B and CA_C with CA_A. Because CA_A is root CA, the browser will stop its validation process. If all validations are correct, browser will trust the CA of the web server. These root CAs are established by independent cooperation and responsible for all of released CAs over the world. They are secure, transparent and not controlled by any government as we believe. However what will happen if the root CA was take over by a government like this case “ISP may be controlled by government” http://www.theregister.co.uk/2011/03/23/facebook_traffic_china_telecom/ ? Then it can be very dangerous because the data can be easily decrypted.

For example, I am now living in Germany and use an internet provider ABC which is supported secretly by government ABC. This government ABC has impact on one root CA_ABC too. Then I can be attacked like a case study below.

When I login to Gmail https://gmail.com, as usual I should be resolved to IP in California, USA but my ISP ABC receives an order from the government ABC that I must be resolved to a faked website https://gmail.com hosted in . Now my browser start to verify the certificate of this faked website. It’ll verify with the root CA_ABC which is also compromised by government ABC. Of course this root gives back a “Yes” for validation process. I believe that I am now secure with SSL and start to login. After I entered my username and password, the faked website notices my data and send me back to the real one so that I can login to my mail box. That means I am attacked by MITM and lose my password although I am using SSL. It seems to be very complicated but all of governments can make the attack above if they have their root CA in trust lists of browsers.

Can I protect myself from this art of attacking? Yes, of course. There are some solutions with disadvantages to avoid being attacked in SSL, for example saving IP of web server with certificate or remember certificate path and popup warning when it was changed. However this warning will be poped up too when web server changes its IP or gets a new certificate and we must manually check if we were state-driven or the server changes itself which is time-consuming.

When I was a cracker, I always say that a protection scheme is only secure when a cracker does not enough resources to crack it (time, money…) and SSL now is the same. SSL is only secure when hacker do not have enough resources to hack it.

At the end there are some interesting links for you

Leave a comment

Your email address will not be published. Required fields are marked *