Hi, Kai Engert wrote: > If the attacker is able to hack the router that is close to the > webserver (e.g. hack the ISP that hosts the webserver), then the > attacker might be able to simply apply for a certificate from a CA and > intercept the (plaintext) approval emails the CA sends to the domain's > mail server.
[...snip...] > 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). How do you plan on handling CDN services (ones with many certs)? Convergence and Perspectives suffer from that as well. 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) 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.) The rest is identical like in the "close to webserver" case, with an extra "bonus" that attacker may make the server appear working fine when sending DNS responses to original owner's home/work network using low TTL. The attacker can also fool Convergence this way, because he'll let the notaries see both original cert and fraudulent cert. Since question to Convergence is "Is this hash of domain.com OK?", Convergence notary looks into DB and says "Sure, seen it." In my clone of Perspectives server I simply store all seen certs with full chains, with possibly overlapping time periods (so operator could check it). An ad-hoc solution for DNS-hacking would be passive DNS database, but attacker must not know which IPs/networks belong to probes. (With so many observatories we are slowly moving towards Peter Gutmann's continuity idea.) Ondrej -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
