On 02/07/2012 09:58 PM, Kai Engert wrote: > 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.
Sure, provided that you call the right owner. >> 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. It's not true in general. There are services hidden with a load-balancer behind a single IP. An example - 3m.com: % dig +short 3m.com 192.28.34.26 #note: it's not fast-flux, TTL is 86400 % openssl s_client -tls1 -connect 192.28.34.26:443 -servername 3m.com </dev/null 2>/dev/null | openssl x509 -noout -fingerprint -sha256 -issuer -subject SHA256 Fingerprint=0A:F6:9B:2A:7C:C5:7C:7E:36:1F:49:02:EF:A4:8B:1E:4D:F6:44:43:CF:AF:8F:22:75:E8:BA:B8:61:49:A0:65 issuer= /C=US/O=Thawte, Inc./CN=Thawte SSL CA subject= /C=US/ST=Minnesota/L=Saint Paul/O=3M Company/OU=3M Company - P9/CN=*.3m.com % openssl s_client -tls1 -connect 192.28.34.26:443 -servername 3m.com </dev/null 2>/dev/null | openssl x509 -noout -fingerprint -sha256 -issuer -subject SHA256 Fingerprint=40:21:0B:40:1F:1E:7D:61:D5:8B:C9:60:6C:07:1D:F0:1B:85:55:4D:5A:95:14:16:84:45:42:AD:82:44:97:CE issuer= /C=US/O=Thawte, Inc./CN=Thawte SSL CA subject= /C=US/ST=Minnesota/L=Saint Paul/O=3M Company/OU=3M Company - P11/CN=*.3m.com % openssl s_client -tls1 -connect 192.28.34.26:443 -servername 3m.com </dev/null 2>/dev/null | openssl x509 -noout -fingerprint -sha256 -issuer -subject SHA256 Fingerprint=7A:0F:F7:50:9E:8A:67:57:5A:6E:08:16:0C:A4:C2:11:D6:DD:A0:79:78:FC:49:23:8F:9A:30:B6:F6:0E:05:98 issuer= /C=US/O=Thawte, Inc./CN=Thawte SSL CA subject= /C=US/ST=Minnesota/L=Saint Paul/O=3M Company/OU=3M Company - P10/CN=*.3m.com Here's a survey on CDNs done around November 2011 that shows the CDN services (IPs are not recorded, but a simple script could check which ones are just behind single IP): http://constructibleuniverse.net/CDN/CDN_hosts.csv It's CSV with '|' delimiter, fields: domain, DB id, issuer Org, issuer CN, first seen, last seen. > 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. Maybe I wasn't clear before: I'm not saying EV certs would help, just that the administrative demands/costs of verification process in MECAI/SK are getting close to EV validation. (Technically, we could talk about OV/IV validation instead of EV.) > 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. Yes. The difference between the "attacker close to webserver" and "compromised DNS" is just in the available attack vectors: - with DNS, it makes it easier if MX points to other machine than webserver and makes attacking registrar as an option, whereas - attacker "close to webserver" requires that MX points to the webserver and that active attacker can do downgrade attack to SMTPS (if SMTPS is used; or the webserver itself is compromised). > 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. I'd also add that the secondary domain should be registered with different registrar than primary domain. > Being able to modify WHOIS data and hijack a domain is a separate attack > and might require solutions from a different angle. It's a separate attack, but unfortunately very feasible (I am inclined to say that it's generally easier than attacking a CA). Ondrej -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
