Inspired by an old question from PulpSpy, I'm trying to think of whether this is a significant weakness in the Certificate Authority system. Here are the attack methods that I think would work - please comment, critique, and add more that you can think of:

  1. Get a less-reputable CA to issue a basic HTTPS cert. Manipulate the target's DNS requests to direct traffic to a server you control, which will give the appearance of a "valid" HTTPS connection (in the absence of additional precautions e.g. Certificate Patrol) .

  2. Snipe an active domain, get a reputable CA to issue an EV cert. The existence of the EV cert can be used to delay/prevent the "true" owner from regaining control, because the domain snipers now have better proof of ownership.

I think DNSSEC will protect against #1 in cases where the trust anchors are deployed via browsers (e.g. Firefox), and the browser installer itself is signed. The obvious issue is that not many domains are DNSSEC-enabled. (Counterpoint: Many important domains are DNSSEC-enabled).

Are there any other attack methods?

2 Answers 2


For SSL itself, a fake certificate can only serve as a way to run a fake server. This requires intercepting the connections from some clients to the true server, and redirect them against your server. Manipulating the DNS is only one way to do that (admittedly, often the easiest) and DNSSEC is meant to protect against that (since DNSSEC is about "securing" with signatures what the DNS servers return). If the attacker controls a router/firewall between the client and the server, he can redirect all the traffic he wants without needing to change anything in the DNS.

Your point #2 is more a Denial-of-Service than anything else. It highlights that when heavier authentication procedures are put in place (e.g. the procedures which are conducted before issuing an EV certificates), it makes mishaps less probable (harder for the attacker) but also deeper (recovery might be longer). This is a point which must be taken into account in the whole security trade-off.


DNSSEC itself does not protect against any of this. DNSSEC just protects the DNS replies, so they can't be faked easily. But because the DNS can be trusted with DNSSEC, using DANE one can store a hash of the certificate in the DNS.

Sadly, at the moment almost no clients check this. For most Browsers there is a Addon which checks the DNSSEC/DANE records.

DANE allows the domain owner to either specify one (or more) certificates to be allowed for the domain, or to limit the CA from which certificates for the domain should be accepted. With full browser support, it would mean that there is no CA needed and DNSSEC/DANE is enough to verify the certificate.

For your second question: 1. you should ask every question separate on this site, 2. there are specific rule sets dealing with domain disputes, depending on TLD, country etc. I am not aware that holding a EV certificate would have any significance in any of them, but it might be.

You must log in to answer this question.

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