400 seems to fit better, since 403 claims authority over a resource the server does not handle. The "deceptive" might not apply here, but the routing is in error, from the server's point of view at least.
- Stefan RFC 7231: 6.5.1. 400 Bad Request The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing). > Am 13.09.2019 um 21:05 schrieb William A Rowe Jr <[email protected]>: > > 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 <[email protected]> wrote: > On Fri, Sep 13, 2019 at 7:55 AM Tom Sommer <[email protected]> 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 <[email protected]> wrote: > > I think this is a great idea and compromise. > > > --- > Tom > > >
