On 11/01/2017 19:17, Patrick Figel wrote:
On 11/01/2017 19:06, Nick Lamb wrote:
For those who haven't (unlike Patrick) sat down and read the ACME
specification, ACME http-01 won't get tripped here because the
checked content of the URL is very much not the random string (it's a
JWS signature over a data structure containing that random string,
thereby proving it was made by whoever the ACME server is talking
to). But yes, doing something that _looks_ superficially like the
ACME style of validation without such subtlety will trip you up.
Thanks, that's a better way of phrasing what I was trying to say. ;-)
In this very particular case, where the affected validation was
specific to web servers, it seems extremely likely that almost all of
the legitimate certificates (which may be, and we hope is, all of
them) were subsequently put into use on a web server.
Why go to the bother of setting up a web server on say,
smtp.example.com, only to get yourself a certificate, and then turn
off the web server and use the certificate for SMTP? It's not
impossible, but it would be very much the exception.
I don't know this specifically for GoDaddy, but many commercial CAs I've
dealt with in the past typically only validate the "registered domain"
portion (e.g. example.com) of the FQDN and then give you certificates
for any subdomain (e.g. smtp.example.com) under that domain. I think the
approach used by Let's Encrypt, where each FQDN has to be validated
individually, is not all that common otherwise.
For your information, here are the ones I have encountered:
AlphaSSL (Globalsign sub) and one other (a Symantec sub, as far as I
recall) verify control of the corresponding hostmaster e-mail address
for the second level domain (hostmas...@example.com).
Google (for non-certificate purposes) used to verify a url that just
had to return a string that said "google-site-verification: URL" where
URL was the file name part of the Url, this may or may not have been
foolable. This was done per exact domain.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
