Re: SNI strict error logged as ssl:info, should be ssl:warm? (r1841455)
On 2019-09-13 18:48, Tom Sommer wrote: On 2019-09-13 15:25, William A Rowe Jr wrote: 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. I think this is a great idea and compromise. Is there something I can do to contribute, so this moves forward? A bug report or something? Thanks --- Tom
Re: SNI strict error logged as ssl:info, should be ssl:warm? (r1841455)
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 : > > 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 wrote: > On Fri, Sep 13, 2019 at 7:55 AM Tom Sommer 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 wrote: > > I think this is a great idea and compromise. > > > --- > Tom > > >
Re: SNI strict error logged as ssl:info, should be ssl:warm? (r1841455)
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 wrote: > On Fri, Sep 13, 2019 at 7:55 AM Tom Sommer 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 wrote: > > I think this is a great idea and compromise. > > > --- > Tom > > >
Re: SNI strict error logged as ssl:info, should be ssl:warm? (r1841455)
On 2019-09-13 15:25, William A Rowe Jr wrote: 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. I think this is a great idea and compromise. --- Tom
Re: SNI strict error logged as ssl:info, should be ssl:warm? (r1841455)
On Fri, Sep 13, 2019 at 7:55 AM Tom Sommer 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.
Re: SNI strict error logged as ssl:info, should be ssl:warm? (r1841455)
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. --- Tom
Re: SNI strict error logged as ssl:info, should be ssl:warm? (r1841455)
When we started rejecting more invalid traffic, e.g. malformed http request and header lines, we downgraded that all for plaintext traffic since there is no reason to collect garbage traffic reports in the normal error logging scenario. 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. Info exists to attempt to record a single point of failure on each transaction. Debug is for finer granularity. Warn is for correcting things that the *operator has control over* and can rectify. The operator has no control over what clients connect to the server, not the request they present, so handshake issues never belong at loglevel warn IMO. On Fri, Sep 13, 2019, 06:49 Tom Sommer wrote: > > On 2019-09-13 13:40, Tom Sommer wrote: > > > Would it not make sense to change this to APLOG_WARN? It used to be > > APLOG_ERR, which made more sense than APLOG_INFO/APLOG_DEBUG? > > Here is the change from ERR to DEBUG/INFO: > https://svn.apache.org/viewvc?view=revision=1841446 > > --- > Tom >
Re: SNI strict error logged as ssl:info, should be ssl:warm? (r1841455)
On 2019-09-13 13:40, Tom Sommer wrote: Would it not make sense to change this to APLOG_WARN? It used to be APLOG_ERR, which made more sense than APLOG_INFO/APLOG_DEBUG? Here is the change from ERR to DEBUG/INFO: https://svn.apache.org/viewvc?view=revision=1841446 --- Tom
SNI strict error logged as ssl:info, should be ssl:warm? (r1841455)
Hi All I see SNI strict errors are logged as APLOG_INFO, ref: https://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c?r1=1841455=1841454=1841455 Would it not make sense to change this to APLOG_WARN? It used to be APLOG_ERR, which made more sense than APLOG_INFO/APLOG_DEBUG? HTTPD rejects the request with forbidden, but does not provide any reason in the error log, with the default LogLevel? Thanks -- Tom
