Can a HTTPS connection be compromised because of a rogue DNS server

In order to connect to any website, through https or not, you need the ip address of the site, and you ask your DNS server for it using the domain name of your site. If your DNS server has not cached the answer, it will try to resolve your request by asking a whole series of DNS servers (the root dns server, the top level domain handler ... until the dns server that is authorative for the domain).

An attacker that controls any of those servers can respond to you with a fake IP address for that website, and this is what your browser will try to visit. This IP address in the general case will have a replica of the website hosted, to make it look the same as the original one, or just act as a silent forwarder of your connection to the correct site after capturing what it needs.

Now on to more details: If the website is HTTPS protected there will be many pitfalls. The normal website will have a certificate issued that binds details of the domain name to the website, but this is done using assymetric encryption.

What this means is that through the process of SSL handshake, the website has to prove that it has knowledge of the private key that is associated with the public key in the certificate. Now, the malicious party can very well serve you the original certificate of the website when you try to access the wrong IP under the correct hostname, but he will not have knowledge of the private key so the SSL handshake will never complete.

But there are ways for the interceptor to make the whole thing work, I can think of four:

1) The simplest solution is to serve you a self-signed certificate instead of a normal one. This will be issued by the attacker itself. Normally your browser will warn you about that, and if you run a recent browser version the warnings will be all over the place, but users tend to click-through that kind of stuff..

2) Another approach, used in the Stuxnet attacks, is to steal the private keys used for a valid certificate from the organization that you want to impersonate.

3) Another solution, that has happened in a couple of cases (we are not talking about the average attacker here) is that he exploits some fault in the registration procedure that certificate authorities (or registration authorities) use, and manages to issue a certificate for a website that does not belong to him. There have been cases that RAs simply did not do enough checks and issued certificates for google.com ..

4) Similar to the above: A competent attacker 'hacks' a certificate or registration authority and manages to issue some certificates under whatever name he wants. It happened in May of 2011 (the famous comodo-hack) and July of 2011 (the DigiNotar hack). See more details at How feasible is it for a CA to be hacked? Which default trusted root certificates should I remove? - IT Security.

5) Finally the most scary tecnique is the one that three letter agencies and similar parties can use: If a government controls a Certificate Authority, in theory it can force it to issue certificates at will, for whatever site. Now think that Certificate Authorities are spread throughout the world, some being in countries where this can seem very possible. An example to watch here is the CA operated by the Emirates Telecommunications Corporation (Etisalat), 60% owned by the United Arab Emirates (UAE) government. Etisalat once rolled out an innocuous looking BlackBerry patch that inserted spyware into RIM devices, enabling monitoring of e-mail.

In addition, if the client still supports the old SSL 2.0 protocol, a MITM can downgrade the SSL connection and use either a weaker symmetric encryption algorithm or a weaker key exchange.

So to sum up, if the attacker controls the DNS server he can do very malicious things, but for intercepting SSL encrypted traffic he needs something more than that.

And to answer your last question: The CA's site does not need to be resolved each time you visit a site: The website usually serves you the public certificate it uses itself, but it is possible that you get it from the CA instead. This does not change any of the mentioned things above though.


It shouldn't be possible. If the attacker is able to control you DNS he might redirect you to a compromised server. But your browser will (if configured correctly) warn you about a broken certificate.

But indeed it's possible! In the case the server doesn't have a valid cert, your browser will warn when you connect to the real server and when you connect to the attackers machine. You are not able to decide whether this warning is critical.
In another scenario the attacker was able to grab the valid cert of the server (see for example here). So he is able to redirect you to a compromised server and your browser won't say anything..


In addition to @John's excellent answer, a rogue DNS server can cause other damage, besides any affect on the current HTTPS connection (though this is strictly outside the scope of your question, I think it is still relevant). There are types of damage it can do, besides trying to eavesdrop on your current connection.

If you are asking a malicious DNS server to resolve addresses for you, it can give you answers you did not ask for, thus affecting any other connections you create - even after you stop using the rogue DNS.
E.g. using DNS poisoning techniques. (See also my answer to this question.)

Also, the malicious DNS can purposely redirect you to another server, e.g. a victim server that will now get flooded by fake requests.

Besides all that, who guarantees you actually make the SSL connection? Most users don't bother typing in "aich tee tee pee ESS(!) colon whack whack... "... They'll just type in the domain name (e.g. "mybank") and hit ctrl+enter, or have the search engine pop it up, or... and in all those cases, it is likely that the user's initial request won't even be HTTPS at all. (Of course, if you do specifically type it in, that's different, so YMMV on that point).

I also suggest taking a look at some of the answers at "What's involved in taking over someone else's domain name?"