On Wednesday, 11 January 2017 16:42:31 UTC, Patrick Figel wrote: > There wasn't really a standard way to do this, so some CAs (like > GoDaddy) might have implemented something resembling the ACME http-01 > challenge type, where part of the request URL is a random string (and > which suffers from this vulnerability if you only look for that random > string in the response body)
I had to read this twice to understand what you were getting at here. 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. > It would not give you the full picture since any number of those certificates > could've been deployed on non-public servers, or on TLS servers that > censys does not scan for 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. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
