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
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
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
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
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
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
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
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
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
