On Tue, Jun 19, 2018 at 08:30:32PM -0400, Felipe Gasper wrote: > Having read over the history of TLS-SNI as reported in the draft > spec, I feel like it might be prudent to mention that a > significant part of the failure of TLS-SNI was Apache httpd and > its (nonsensical, IMO) behavior of sending certificates for domains > that don’t match the SNI request. > > The write-up mentions “service providers”; for what it’s worth, I > feel like a more complete and accurate picture would also indicate > that “popular server software” (e.g., Apache … maybe others?) will > happily serve up a certificate that has no connection with the SNI > request, and that this is also a significant part of why TLS-SNI did > not work.
My understanding was that catastrophic problem was not the default- vhost behavior of Apache or Nginx, altough that could casue security issues. But instead, the problem was that many hosting provoders let one claim arbitrary hostnames on FCFS basis. This let attacker upload arbitrary validation certificates to be served, and due to how TLS-SNI worked, this lead to misvalidation. TLS-ALPN addresses the latter problem by requiring the server_name to match the validation target (which is AFACIT also required by the Baseline Requirements). This stops claiming arbitary names from allowing misvalidations. The TLS-SNI-01 included was default-vhost countermeasures, but those were dropped from TLS-SNI-02, and from what I can tell, were not actually used. -Ilari _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
