How does one protect themself from a DNS compromised site, which also has had their SSL private key stolen? Short of monitoring which IP the packets are being sent to.

Edit: Or even without the private key, could they not just use something like Zero SSL, provided they have full control the DNS server?

2 Answers 2


Detecting the use of a valid but somehow compromised certificate is hard:

  • If the target site has their private keys stolen and did not realize it yet then the attacker to spoof the site perfectly, i.e. the client will not realize the difference to the original site.
  • If the site has it's private key stolen and realized it then it should revoke the certificate. In theory the browser will check if the certificate was revoked and refuse to connect in this case. But in practice this check cannot really relied on except in special cases (like EV certificates or sites deemed important by the browser vendor) since browsers either don't to an revocation check with OCSP at all or will ignore errors during the check - where such errors might be caused by the attacker.
  • If an attacker managed to get a publicly trusted certificate for the site (for example by taking over the sites DNS long enough to get such a certificate, see recent issue with Fox-IT) it is also hard for the client to detect this as a problem since using a new certificate might actually be valid. Projects like Convergence might help in this case because they allow to detect if other users see a different certificate for the same site. Also, certificate pinning (HPKP) used by the site itself might help.

Since detecting the use the bad certificate is impossible in many cases this leaves only detecting the DNS spoofing:

  • IP monitoring like you suggested might help to detect if the attacker is using a target IP very different from the one usually used by the original site. Note that this does not help against ARP spoofing in local networks or internet wide BGP redirects since the target IP is not necessarily changed in this case - only rerouted.
  • If the site supports DNSSec it should be used to verify what the real IP is. Of course this only helps against local spoofing and not if the primary DNS server for the domain was hacked.
  • If the target does not employ DNSSec it might be useful to ask a DNS server which is not affected by the (local) DNS spoofing. For example one might use DNS over HTTPS so that the attacker is not able to spoof these DNS answers too. An attacker might of course try to make these sites unavailable for you in the hope that you fall back to the locally spoofed DNS.

There are various projects like DNSSEC and DNSCrypt that aim to prevent DNS poisoning, etc. Adoption of these sorts of technologies are increasing, but not quite there yet.

Let's differentiate between control of your DNS server, control of the domain name, and control of the web server though.

If an attacker has control of a DNS server, they can send you to their attack server, but they can't forge a trusted certificate. This is easy to see as you'll get a 'this site isn't trusted'.

However, if an attacker were to get your account info for your domain registrar, then they could register their own IP with your domain name, which they could then channel into getting trusted certificate for that domain.

If an attacker has control of the webserver, then they could get a trusted certificate for that domain; this is entirely independent of DNS.

For the later two attacks, it's very hard to detect. Monitoring IPs isn't very useful in most cases, as a lot of website use cloud hosted (amazon, azure, google) where their IP can change day to day. You could monitor the certificates, a new certificate would have a different fingerprint, which you could detect client side (and could probably be automated with a browser plugin). However, certificates legitimately change every few years -- certificates expire after a set period by design -- so this could produce lots of false positives.

In short, if an attacker can steal a websites identity either by hijacking the domain via the registrar or just getting access to the existing webserver, it is very hard for a client to detect that. It is up to the website admins to make sure they keep control of their identity.

To the last point about zeroSSL/let's encrypt/ and those sorts of automated certificate providers. There have been a number of high profile cases where these automated systems have been generating certificates they shouldn't be (certificates where control of the domain isn't being properly validated). In this case, the fault lies entirely on the CA (ZeroSSL/Let's Encrypt/etc.), and exposes the inherent problem with allowing algorithms to handle validation. It's fast and cheap, but algorithms can be tricked in ways that humans intuitively know are tricks.

  • Can you give references to your assertion: "There have been a number of high profile cases where these automated systems have been generating certificates they shouldn't be (certificates where control of the domain isn't being properly validated)." when speaking aout ZeroSSL/Let's Encrypt ? Dec 21, 2017 at 4:07
  • threatpost.com/comodo-issues-eight-forbidden-certificates/…, commodo issues certificates for things it shouldn't, news.netcraft.com/archives/2017/04/12/…, commodo and lets encrypt issue obviously (to a human) scam certs. Sorry, hit enter too quick on that first comment.
    – K.B.
    Dec 21, 2017 at 15:38
  • You have not proved your assertion that the certificates were delivered by ZeroSSL/Let's Encrypt where the domain isn't properly validated (and what you quote about Comodo and 8 certificates is an error that is very different from what you claim). Phishing is a completely different problem, and not the job of the CAs. Dec 21, 2017 at 16:01
  • It is absolutely the job of the CAs to not issue certificates to scam sites. A CAs authority is built on trust, that's literally their entire reason for existing, if scammer can get certificates that look like certs for other sites that diminishes the trust we can have in the CA. It's not the CAs job to take down a scam site, but it is their prerogative to not issue them a certificate.
    – K.B.
    Dec 21, 2017 at 17:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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