On 07.02.2012 17:54, Ondrej Mikle wrote:
The phone calls would ensure that each registered person will be aware
of the certificate issuance.
This is getting very close to EV validation (Sovereign Keys have the
same issue).
I'd say making phone calls is less effort than checking business
documents, so I'm not convinced it's close to EV - because EV is out of
reach for anyone running a private server.
How do you plan on handling CDN services (ones with many certs)?
That's a reason why I propose vouchers to be IP specific.
In my understanding, each IP will have only a single certificate,
regardless from where in the world you connect to it.
Another weak point I see is the DNS server for the domain (only
exception for this seems to be Transparent Certificates and EV
validation; everything else is susceptible - DANE, Sovereign Keys...).
What about this attack scenario:
1. attacker compromises DNS server for domain.com or redirects NS record
2. now of course he can get DV-validated cert and MitM mails (in
contrary to the "attacker close to webserver", now it does not matter
where MX for domain.com pointed to)
EV doesn't help if the attacker simply decides to get a plain DV cert
and hopes that a sufficient amount of users won't notice the missing green.
Cert transparency requires that the domain owner constantly watches the
public logs for new certs, and then you have the problem that the cert
was already produced and appended to the log - you must wait for revocation.
In your exaple the attacker makes a global modification to DNS, to
ensure the route from CA will point to the attacker that is elswhere on
the web.
But if the domain is supposed to watch something anyway (e.g. cert
transparency log), then the domain owner could simply watch public DNS
for changes. They could ask a monitoring company to watch DNS and notify
them by phone if it changes. Or they could setup a watchdog on their own
on some hosted VPS elsewhere on the web. They could quickly detect the
DNS manipulation, and maybe even prevent the cert from being issued.
Maybe we should require that CAs must always send out multiple emails
whenever a certificate is being requested, even for EV. In addition to
the usual approval message to host/web/sslmaster@domain, it could be
mandatory that the CA sends notification emails to each of the email
addresses found in the domain registry. If the domain owners are smart,
they will use email addresses from secondary domains. Thus, even if the
attacker can hijack the DNS of the domain in question, the attacker
might be unable to do it for those secondary domains, too. If the domain
owners receive notification about a fraudulent certificate request, they
can quickly react. At least they will know which CA might soon issue a
false certificate - and the domain owner can contact that CA and request
cancellation or revocation.
If the CA were required to make phone calls to domain registry entries,
even for DV, whether owner is an organization or a private person, this
attack wouldn't succeed.
3. attacker tricks registrar into changing WHOIS data or transferring
domain. Feasibility of this step heavily depends on registrar's
procedures, but sometimes they just send some authcookie to mailbox
attacker controls. (There was also an incident with a registrar that
suffered from CSRF which could make victim unwittingly change
registration data.)
I think this attack is beyond the "CA's power are abused and it goes
undetected" attack vector, which is the primary problem I'm trying to
solve with the MECAI proposal.
Being able to modify WHOIS data and hijack a domain is a separate attack
and might require solutions from a different angle.
I think the best we can do in the short term is to achieve quick
detection of abused CA powers, and get certificates revoked, and make
revocation checks strict.
Kai
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
