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)?
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?"
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).
Jun 20, 2013 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.
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...
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.
Because it's difficult to differentiate phishing sites. Here's the EFFs SSL observatory.
https://www.eff.org/observatory
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.
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://...
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.
Its highly unlikely, unless you click to allow a suspicious certificate; Other than hacking a poorly configured or old browser with weak ssl, its a pretty tall order. They could have a massive database of mixed content ip addresses used on common major websites that resolve to insecure addresses that use java, fonts or other potentially dangerous files and mitm everything there with malicious content; hence why disabling mixed content is a great idea esp in these days.
