Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

If I'm visiting (just a desktop pc, client side) a site that has a valid HTTPS cert/connection, that can it be compromised if I'm using [not with free will, so e.g.: I'm "attacked"] a rouge DNS server?

I'm thinking about e.g.: the CA's site (to check the HTTPS connection) is resolved by my nameserver (the compromised one)?

share|improve this question

7 Answers 7

up vote 19 down vote accepted

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.

share|improve this answer
1  
Good summary. Another scenario is that the attacker steals the actual private key in use on the site they want to impersonate. –  nealmcb May 16 '11 at 18:27
    
+1, very good answer. Yet another scenario, is serving the bogus HTTPS site over downgraded SSL connection. E.g. answering the client request with SSL v.2 only - if the client supports that, there are numerous additional pitfalls. –  AviD May 16 '11 at 19:05
    
    
Didn't stuxnet use code signing certs that were stolen from the organizations themselves, not a hack on the CA or RA? Great answer though besides that small point. –  getahobby May 19 '11 at 1:52
    
Yes they were not hacked, who knows how they got them though. –  john May 19 '11 at 11:24

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..

share|improve this answer
5  
In the comodo attack you reference, the attacker didn't "grab the valid cert of the server" - that is public info. Nor did they grab the private key of the valid cert. They instead made a second valid cert, using their own private key and the CA of their choice. –  nealmcb May 16 '11 at 18:26

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?"

share|improve this answer
    
Auto-fill causes even worse habits. I've noticed an odd quirk in Firefox that it will store different passwords for the http:// and https:// versions of the same site (probably different IPs). Amazon for instance let's you browse in non-HTTPS mode, but when you go to purchase something you have to reauthenticate over HTTPS. I had at some time setup a completely different Amazon account that I was using for browsing because their usernames are not required to be unique. I found this one day on accident when I discovered my second wishlist (and browsing history). –  AbsoluteƵERØ Jun 20 '13 at 20:17
    
also worth mentioning EvilGrade attacks –  Vincent Jul 27 at 5:58

Some corporate proxies (that operate via DNS redirection or a variety of other means) may inspect the contents of an SSL connection. In addition the users of a managed desktop will not recieve a browser warning if the MITM certificate has been installed into the local store.

Depending on who is managing the proxy, and how its logs are used, this may be acceptable or a bad thing from your perspective.

For more information on how SSL interception is done, see this link:

When the SSL Proxy intercepts an SSL connection, it presents an emulated server certificate to the client browser. The client browser issues a security pop-up to the end-user because the browser does not trust the issuer used by the ProxySG. This pop-up does not occur if the issuer certificate used by SSL Proxy is imported as a trusted root in the client browser's certificate store.

The ProxySG makes all configured certificates available for download via its management console. You can ask end users to download the issuer certificate through Internet Explorer or Firefox and install it as a trusted CA in their browser of choice. This eliminates the certificate popup for emulated certificates...

More information...

share|improve this answer

One other point - an attacker that owns your DNS resolver can misdirect OCSP or CRL requests to a black hole, and virtually all browsers will treat that as evidence that the certificate has not been revoked. So, if a bad guy happens to steal a valid cert but the good guy revokes it, the bad guy can prevent clients from seeing that revocation by black-holing the OCSP/CRL request.

share|improve this answer

In your case, the question is NO, the HTTPS connection CANNOT be compromised.

Now, let's find out why.

  1. Your browser has public keys of the CA. Trusted public keys.

  2. Assuming that the attacker not only able to control the DNS, but also the servers themselves, in this case, both the CA and the targeted HTTP servers.

  3. The attacker CANNOT fake the CA because he does not have matching private keys as your browser.

  4. The attacker CANNOT fake the HTTP server either, because his certificate will not have a stamped of a trusted CA.

In the extreme case that the attacker can obtain a certificate for the domain that he doesn't control/own, then the previous point is invalid. And the attacker can do whatever his imagination can conjure up. The thing is, this violates our very assumption that the CA is trustable! It is the fault of the CA who grants the attacker such a certificate. And when CA is not trustable anymore, SSL is only a paper-tiger.

share|improve this answer
3  
Unfortunately, compromises of various CAs over time has demonstrated that your final point (SSL is only a paper-tiger) is true at times, invalidating your initial point. –  nealmcb May 16 '11 at 18:32
1  
Also, "trusted public keys" - go into your browser's CA list, and see how many CAs are there. Do you trust all those CAs? Well, you do, but you're probably not aware of this. (Note that some of the CA companies also run ISP services, so it would be theoretically simple to decrypt and re-sign all HTTPS traffic with their own (forged) certificates for their customers; as some ISPs already did similar things with DNS NX and plain HTTP, this is technically feasible); that's not to mention various banks implementing HTTPS with "just install FooBar Bank CA certificate in your browser" (yuck). –  Piskvor May 22 '11 at 16:55
    
We're talking about the working principle here. You gotta trust someone for security to work, right? In PKI, that's the CA. That's the assumption one has to live with. That's why when that assumption fails, everything breaks. –  Nam Nguyen May 22 '11 at 17:12

There is a blended attack that would fool most folks http://www.h-online.com/security/news/item/Black-Hat-new-ways-to-attack-SSL-740173.html

The attacker acts as a man in the middle and sets up an unencrypted link to the victum that shows http://... in the browser but the padlock is set and green so folks miss the lack of https://...

share|improve this answer
4  
The padlock icon is not set in this attack, a new favicon is provided for the page that looks like a padlock so users may mistake it. Another option is to use a homomorphic url that has both https and a real certificate - but is not the real url. –  john May 16 '11 at 16:05
    
Thanks for updating. –  zedman9991 May 16 '11 at 17:14

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.