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 
dev-security-policy mailing list

Reply via email to