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 a rogue DNS server (not deliberately, I'm concerned about an attack on the DNS service)?

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

8 Answers
8

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

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.

Good summary. Another scenario is that the attacker steals the actual private key in use on the site they want to impersonate.
–
nealmcbMay 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

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 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.
–
nealmcbMay 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).

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

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.

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

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.

The general idea is sound, impersonations are due to improper issuance of certs. If you could be sure that everyone else out there, when faced with a cert, had the exact same cert, then the likelihood that it is a phishing site, would be close to zero. The astounding part of the research is the number of leaf nodes and CAs out there that are trusted by the browser.

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

Now, let's find out why.

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

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.

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

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.

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.
–
nealmcbMay 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).
–
PiskvorMay 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 NguyenMay 22 '11 at 17:12

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.
–
johnMay 16 '11 at 16:05