Back in 2011 a hacker managed to generate legitimate signed certificates for gmail.com and other communication domains.

Practically speaking, is that enough for him to eavesdrop on any person's communication? My understanding is that the attacker would at the very least need DNS spoofing to lure victims to "bad" gmail.com and then need "bad" gmail.com to mimic actual gmail.com to fool people into entering passwords/sending mails. If the attacker controls a network (such as wifi at a cafe), he could configure an SSL proxy with this "bad" certificate and get all the communication, but lets assume that isn't the case.

My question is: How can legitimate certificates obtained by bad guys for known domains cause a problem on their own?

1 Answer 1


DNS spoofing is just one of the available means to perform a Man-In-The-Middle.

You can for example perform an ARP cache poisoning attack if you are on the same network than the victim, set up a fake open WiFi access point, or perform BGP hijack to intercept some traffic that is routed to Gmail.

So yes, "bad" certificates are only a problem if the attacker can perform a MITM attack, but we recently learned that some companies were performing them at large scale. So bad certificates can cause harm.

  • Thanks for pointing out other MiTM attack vectors. But for browser to accept "bad" certificate, wouldn't the DNS still need to be compromised so that the canonical name on the certificate matches the DNS record mail.google.com? If the attacker can't spoof DNS replies, would that entirely defeat his intentions (provided user is smart enough and takes browser certificate warnings seriously?)
    – RedBaron
    Sep 26, 2016 at 6:03
  • All the techniques I talked about succeed in that case, DNS spoofing is not the only mean. If mail.google.com is routed through the attacker's machine (BGP hijack, or any other I described), he will have the ability to never forward the packets to Gmail, to reply in place of Gmail, and then to use his "bad" cert, even if DNS record is legitimate.
    – Jyo de Lys
    Sep 27, 2016 at 5:47
  • Ah..OK so the browser will think it is connecting to mail.google.com and DNS will resolve correctly to actual gmail IP X.X.X.X, but the packets sent to X.X.X.X will instead reach Y.Y.Y.Y and hence when the "bad" domain sends its certificate, the browser will accept it because the generated reference identifiers (i.e. mail.google.com or gmail.com) will match the ones sent by the "bad" website.
    – RedBaron
    Sep 27, 2016 at 6:55
  • Yes that's it. To be considered valid; the certificate must have been signed by a trusted CA, must be valid the current day (not expired), must have the hostname of the server either in CommonName field or SubjectAltNames extension, and must not have been revoked.
    – Jyo de Lys
    Sep 28, 2016 at 4:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .