Lifting a post from the users discussion list. Should we revisit the error responses we make to demanding SSLRequireSSL, requiring SNI hostname matching, etc as 400 protocol violations, rather than "Permission Denied" with no further explanations?
On Fri, Sep 13, 2019 at 8:25 AM William A Rowe Jr <wr...@rowe-clan.net> wrote: > 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. > > On Fri, Sep 13, 2019 at 11:48 AM Tom Sommer <m...@tomsommer.dk> wrote: > > I think this is a great idea and compromise. > > > --- > Tom > > >
