On Fri, Sep 13, 2019 at 7:55 AM Tom Sommer <m...@tomsommer.dk> wrote:
> > On 2019-09-13 14:50, William A Rowe Jr wrote: > > > The same would likely apply to ssl traffic abuse. At this late date, > > clients connecting with 20 year old ssl semantics doesn't seem > > noteworthy. > > SNI-support does not exist in some 3rd party services, like Sucuri etc., > so it's sadly a very real thing in 2019 as well. > > The "problem" is that a 403 is logged in this case, but no accompanied > reason is logged in the ErrorLog, making it very hard to debug. > Services that don't speak modern TLS are certainly a real thing. Ignoring them isn't unreasonable. TLS 1.0 and 1.1 were deprecated a year ago and they do disappear mid-2020. I'd agree this is confusing. Asking operators to set loglevel debug (heck, in this case even loglevel info would suffice) is the very very very first step to debug any problem behavior in httpd, increasing the signal strength of errors outside of the operators control disturbs the other 99% of operators who've got this. Would we agree that the correct error response to any TLS handshake omission simply be a 400 error, and not an error that indicates some authnz configuration trouble? Does that make it more obvious that the error log needs to be inspected at info, or debug level? A 426 response would seem to be appropriate for TLS 1.0/1.1 but it doesn't have the granularity to ask that a legit TLS 1.2 connection missing SNI needs to upgrade. Seems 400 might be best.
