Re: minor nit in mod_ssl
On Thu, Sep 20, 2018 at 4:41 AM Plüm, Rüdiger, Vodafone Group < ruediger.pl...@vodafone.com> wrote: > Can we have set it to info? Debug is very verbose for SSL just to find out > why a HTTP request was replied to with a 403. > Whatever is appropriate on startup/graceful restart is fine, but 400's must be deciphered out by examining the debug log. The vast number of any class of 400 requests are caused by robot or malicious traffic, so please, nothing stronger than a debug emit for these incidental, undesired TCP connections.
RE: minor nit in mod_ssl
> One would need something like "SSLNameIndicator x.internal.net" to make that > disconnect clear, it seems. If going so far as to add a new directive, I would personally prefer disabling the check rather than adding another to get around this. That could be done with a Boolean directive. For a more flexible approach going forward in 2.6, what do you all think about the idea of adding a new directive to re-define a log statement's level at runtime? This would have made both these log issues a minor inconvenience for end users and easily addressable via the documentation for my specific case. Something like this: LogMessageReduce If such directives are present, log entries would consult a table and substitute the logging level inside ap_log_error for any matches. I can't see this working without an interface change in ap_log_error to get directly at the number, however. Obviously, this function is called a LOT, so there is potential for slowdown depending on how it's written. I would personally write this as a reduce only function, so the lookup checks never happen unless a log message would have been written, in which case it would be overshadowed by the log write itself. Rick Houser Web Engineer > -Original Message- > From: Stefan Eissing > Sent: Thursday, September 20, 2018 09:57 > To: dev@httpd.apache.org > Subject: Re: minor nit in mod_ssl > > EXTERNAL EMAIL > > > > Am 20.09.2018 um 15:31 schrieb Houser, Rick : > > > >> Envision a TCP load balancer routing TLS-crypted traffic across a number > >> of internal hosts, with each of the named virtual hosts presenting the > correct > >> certificate, and known to httpd by their ServerAlias on the outer-facing > interface. > >> Not terminated at the edge balancer. > > > > We are using IP/port based vhosts and ServerName directive, but yes, > that's one example. In our current config, the load balancer is talking to a > lot > of vhosts using TLS with a single host-specific certificate. > > > > From my perspective, the underlying problem is merely attempting to > associate the ServerName with the certificate at all, since they belong at > different places in the protocol stack. The ServerName needs to be set to > the externally facing endpoint of the infrastructure (the encapsulated HTTP > traffic), and the certificate needs to be correct for the local TLS link. I > know of > no reason from a technical/protocol perspective that there couldn't be a > dozen different hops in between (ex. application-layer firewalls, virus > scanner, reverse proxies, etc.). > > > > My understanding is that using ServerAlias instead of ServerName would > potentially leak information about the host, via server generated content. > The documentation seems to reinforce this > (https://httpd.apache.org/docs/2.4/mod/core.html#servername ). > > You are correct. Using the externally visible name for ServerName seems > best in your scenario. Thanks for explaining your setup. > > > From a pragmatic approach, lay users will not be encountering this type of > configuration, so keeping the message at a more verbose level still makes > some sense and could help identify a legitimate misconfiguration. IMO, a > production system should be able to run with info level logs without blowing > up on false positives, however. > > Totally agree. When using local TLS links between balancers/terminators and > httpd boxes, it seems not possible to map that onto the existing > configuration concepts that easily. > > Basically, the TLS is not end-to-end, but a tunnel to a "worker" httpd host > that has its own name and own certificate which is used to serve requests for > another hostname. In this scenario, the normally desired link between > certificate alt names and servername gets in the way. > > One would need something like "SSLNameIndicator x.internal.net" to make > that disconnect clear, it seems. > > -Stefan >
Re: minor nit in mod_ssl
> Am 20.09.2018 um 15:31 schrieb Houser, Rick : > >> Envision a TCP load balancer routing TLS-crypted traffic across a number >> of internal hosts, with each of the named virtual hosts presenting the >> correct >> certificate, and known to httpd by their ServerAlias on the outer-facing >> interface. >> Not terminated at the edge balancer. > > We are using IP/port based vhosts and ServerName directive, but yes, that's > one example. In our current config, the load balancer is talking to a lot of > vhosts using TLS with a single host-specific certificate. > > From my perspective, the underlying problem is merely attempting to associate > the ServerName with the certificate at all, since they belong at different > places in the protocol stack. The ServerName needs to be set to the > externally facing endpoint of the infrastructure (the encapsulated HTTP > traffic), and the certificate needs to be correct for the local TLS link. I > know of no reason from a technical/protocol perspective that there couldn't > be a dozen different hops in between (ex. application-layer firewalls, virus > scanner, reverse proxies, etc.). > > My understanding is that using ServerAlias instead of ServerName would > potentially leak information about the host, via server generated content. > The documentation seems to reinforce this > (https://httpd.apache.org/docs/2.4/mod/core.html#servername ). You are correct. Using the externally visible name for ServerName seems best in your scenario. Thanks for explaining your setup. > From a pragmatic approach, lay users will not be encountering this type of > configuration, so keeping the message at a more verbose level still makes > some sense and could help identify a legitimate misconfiguration. IMO, a > production system should be able to run with info level logs without blowing > up on false positives, however. Totally agree. When using local TLS links between balancers/terminators and httpd boxes, it seems not possible to map that onto the existing configuration concepts that easily. Basically, the TLS is not end-to-end, but a tunnel to a "worker" httpd host that has its own name and own certificate which is used to serve requests for another hostname. In this scenario, the normally desired link between certificate alt names and servername gets in the way. One would need something like "SSLNameIndicator x.internal.net" to make that disconnect clear, it seems. -Stefan
RE: minor nit in mod_ssl
Vhosts have all the usual stuff with Document root, logging, etc. TLS is configured globally (serverhost.serverdomain.tld) , but if we were receiving connections on multiple IP addresses, I could see setting that up within each vhost to a value that does not match ServerName as well. Listen 8012 ServerName address1.example.com Listen 8013 ServerName address2.example.com I'd be happy to clarify if any specifics aren't clear, but I think this is a general problem related to scope clash with attributes from different parts of communication stack, not something related to the specific configuration. Please see my response to William about 20 mintues back for more clarification on that. Rick Houser Web Engineer > -Original Message- > From: Stefan Eissing > Sent: Thursday, September 20, 2018 05:03 > To: dev@httpd.apache.org > Subject: Re: minor nit in mod_ssl > > EXTERNAL EMAIL > > > > > Am 19.09.2018 um 17:17 schrieb William A Rowe Jr clan.net>: > > > > On Wed, Sep 19, 2018 at 6:39 AM Stefan Eissing > wrote: > > > > > Am 18.09.2018 um 15:44 schrieb Houser, Rick > : > > > > > > In the same vein, I’ve been running this patch on our builds to get around > a warning for certificates not matching the hostname. Certificates are not > expected to match the hostname with many load balancing/uptime > detection schemes, and this one logs a LOT when it trips on every vhost. > Perhaps this patch should share the same fate as decided for the TLS missing > SNI issue? > > > > Not sure I understand your setup here. Is this the ServerName from the > global server? Otherwise, in a VirtualHost why would you not set the > ServerName to the hostname you are serving? > > > > Envision a TCP load balancer routing TLS-crypted traffic across a number > > of internal hosts, with each of the named virtual hosts presenting the > correct > > certificate, and known to httpd by their ServerAlias on the outer-facing > interface. > > Not terminated at the edge balancer. > > > > There is the issue of keeping TLS session key encoding in sync across > > the backends, obviously. > > Yes, I can see that. But the mentioned APLOG_WARN only triggers for s- > >server_hostname, not the Alias list. > > I therefore imagine the setup to be like: > > tcp-balancer (x.domain.org) > - host a.internal.net > > ServerName a.internal.net > ServerAlias x.domain.org > SSLCertificateFile cert-for-x.domain.org.pem > > > - host b.internal.net > > ServerName b.internal.net > ServerAlias x.domain.org > SSLCertificateFile cert-for-x.domain.org.pem > > > and maybe that is nicer than writing > > ServerName x.domain.org > ServerAlias b.internal.net > SSLCertificateFile cert-for-x.domain.org.pem > > > or it has side-effects that I do not understand. Or, the config is like: > SSLCertificateFile cert-for-x.domain.org.pem > > ServerName b.internal.net > > > ServerName x.domain.org > > > Any way, I would like to understand the issue before removing the > APLOG_WARN about non-matching certificates. Which is a valid warning > and can prevent debug frustration. > > Rick, can you help me out here? > > -Stefan
RE: minor nit in mod_ssl
> Envision a TCP load balancer routing TLS-crypted traffic across a number > of internal hosts, with each of the named virtual hosts presenting the correct > certificate, and known to httpd by their ServerAlias on the outer-facing > interface. > Not terminated at the edge balancer. We are using IP/port based vhosts and ServerName directive, but yes, that's one example. In our current config, the load balancer is talking to a lot of vhosts using TLS with a single host-specific certificate. From my perspective, the underlying problem is merely attempting to associate the ServerName with the certificate at all, since they belong at different places in the protocol stack. The ServerName needs to be set to the externally facing endpoint of the infrastructure (the encapsulated HTTP traffic), and the certificate needs to be correct for the local TLS link. I know of no reason from a technical/protocol perspective that there couldn't be a dozen different hops in between (ex. application-layer firewalls, virus scanner, reverse proxies, etc.). My understanding is that using ServerAlias instead of ServerName would potentially leak information about the host, via server generated content. The documentation seems to reinforce this (https://httpd.apache.org/docs/2.4/mod/core.html#servername ). From a pragmatic approach, lay users will not be encountering this type of configuration, so keeping the message at a more verbose level still makes some sense and could help identify a legitimate misconfiguration. IMO, a production system should be able to run with info level logs without blowing up on false positives, however. Rick Houser Web Engineer
AW: minor nit in mod_ssl
Thanks. Regards Rüdiger > -Ursprüngliche Nachricht- > Von: Stefan Eissing > Gesendet: Donnerstag, 20. September 2018 11:58 > An: dev@httpd.apache.org > Betreff: Re: minor nit in mod_ssl > > Fair enough. Done in r1841455. > > > Am 20.09.2018 um 11:53 schrieb Plüm, Rüdiger, Vodafone Group > : > > > > Correct, but the issue is that as an admin you do not always get the > error page that a client sees and you have to search for the cause > without. > > Especially in this case as non SNI clients are often not browsers but > non interactive programs. > > > > Regards > > > > Rüdiger > > > >> -Ursprüngliche Nachricht- > >> Von: Stefan Eissing > >> Gesendet: Donnerstag, 20. September 2018 11:46 > >> An: dev@httpd.apache.org > >> Betreff: Re: minor nit in mod_ssl > >> > >> I am not opposed. However, there is an explanation added to the > request > >> error notes, which normally appears in the 403 response if I am not > >> mistaken? > >> > >> -Stefan > >> > >>> Am 20.09.2018 um 11:40 schrieb Plüm, Rüdiger, Vodafone Group > >> : > >>> > >>> Can we have set it to info? Debug is very verbose for SSL just to > find > >> out why a HTTP request was replied to with a 403. > >>> > >>> Regards > >>> > >>> Rüdiger > >>> > >>> Von: William A Rowe Jr > >>> Gesendet: Montag, 17. September 2018 22:27 > >>> An: httpd > >>> Betreff: Re: minor nit in mod_ssl > >>> > >>> On Mon, Sep 17, 2018 at 2:56 AM Stefan Eissing > >> wrote: > >>>> > >>>> mod_ssl/ssl_engine.kernel.c, 353: logs ERR (APLOGNO(02033)) when > >> strict_sni_vhost_check is enabled and a request comes in without SNI. > >>>> > >>>> Question: is a downgrade from ERR to INFO/DEBUG backportable or do > >> we consider this a break of compatibility? > >>> > >>> > >>> > >>> On Mon, Sep 17, 2018 at 10:43 AM William A Rowe Jr >> clan.net> wrote: > >>>> > >>>> It is entirely appropriate to turn down the volume. That's what > >> module-by-module loglevels are there for. > >>> > >>> > >>> This is the loglevel of typical garbage request streams; > >>> > >>> [Mon Sep 17 11:44:43.036820 2018] [core:debug] [pid 26317:tid > >> 140199172134656] protocol.c(965): (20014)Internal error (specific > >> information not available): [client 127.0.0.1:34974] Failed to read > >> request header line (null) > >>> [Mon Sep 17 11:44:43.036871 2018] [core:debug] [pid 26317:tid > >> 140199172134656] protocol.c(1318): [client127.0.0.1:34974] AH00567: > >> request failed: error reading the headers > >>> [Mon Sep 17 15:24:46.146311 2018] [core:debug] [pid 26413:tid > >> 140199180527360] protocol.c(860): [client127.0.0.1:35330] AH02418: > HTTP > >> Request Line; Unrecognized protocol 'HTTP/1.xx' (perhaps whitespace > was > >> injected?) > >>> > >>> It seems that TLS missing SNI fits this same debug-level pattern of > >> diagnostics. > >
Re: minor nit in mod_ssl
Fair enough. Done in r1841455. > Am 20.09.2018 um 11:53 schrieb Plüm, Rüdiger, Vodafone Group > : > > Correct, but the issue is that as an admin you do not always get the error > page that a client sees and you have to search for the cause without. > Especially in this case as non SNI clients are often not browsers but non > interactive programs. > > Regards > > Rüdiger > >> -Ursprüngliche Nachricht- >> Von: Stefan Eissing >> Gesendet: Donnerstag, 20. September 2018 11:46 >> An: dev@httpd.apache.org >> Betreff: Re: minor nit in mod_ssl >> >> I am not opposed. However, there is an explanation added to the request >> error notes, which normally appears in the 403 response if I am not >> mistaken? >> >> -Stefan >> >>> Am 20.09.2018 um 11:40 schrieb Plüm, Rüdiger, Vodafone Group >> : >>> >>> Can we have set it to info? Debug is very verbose for SSL just to find >> out why a HTTP request was replied to with a 403. >>> >>> Regards >>> >>> Rüdiger >>> >>> Von: William A Rowe Jr >>> Gesendet: Montag, 17. September 2018 22:27 >>> An: httpd >>> Betreff: Re: minor nit in mod_ssl >>> >>> On Mon, Sep 17, 2018 at 2:56 AM Stefan Eissing >> wrote: >>>> >>>> mod_ssl/ssl_engine.kernel.c, 353: logs ERR (APLOGNO(02033)) when >> strict_sni_vhost_check is enabled and a request comes in without SNI. >>>> >>>> Question: is a downgrade from ERR to INFO/DEBUG backportable or do >> we consider this a break of compatibility? >>> >>> >>> >>> On Mon, Sep 17, 2018 at 10:43 AM William A Rowe Jr > clan.net> wrote: >>>> >>>> It is entirely appropriate to turn down the volume. That's what >> module-by-module loglevels are there for. >>> >>> >>> This is the loglevel of typical garbage request streams; >>> >>> [Mon Sep 17 11:44:43.036820 2018] [core:debug] [pid 26317:tid >> 140199172134656] protocol.c(965): (20014)Internal error (specific >> information not available): [client 127.0.0.1:34974] Failed to read >> request header line (null) >>> [Mon Sep 17 11:44:43.036871 2018] [core:debug] [pid 26317:tid >> 140199172134656] protocol.c(1318): [client127.0.0.1:34974] AH00567: >> request failed: error reading the headers >>> [Mon Sep 17 15:24:46.146311 2018] [core:debug] [pid 26413:tid >> 140199180527360] protocol.c(860): [client127.0.0.1:35330] AH02418: HTTP >> Request Line; Unrecognized protocol 'HTTP/1.xx' (perhaps whitespace was >> injected?) >>> >>> It seems that TLS missing SNI fits this same debug-level pattern of >> diagnostics. >
AW: minor nit in mod_ssl
Correct, but the issue is that as an admin you do not always get the error page that a client sees and you have to search for the cause without. Especially in this case as non SNI clients are often not browsers but non interactive programs. Regards Rüdiger > -Ursprüngliche Nachricht- > Von: Stefan Eissing > Gesendet: Donnerstag, 20. September 2018 11:46 > An: dev@httpd.apache.org > Betreff: Re: minor nit in mod_ssl > > I am not opposed. However, there is an explanation added to the request > error notes, which normally appears in the 403 response if I am not > mistaken? > > -Stefan > > > Am 20.09.2018 um 11:40 schrieb Plüm, Rüdiger, Vodafone Group > : > > > > Can we have set it to info? Debug is very verbose for SSL just to find > out why a HTTP request was replied to with a 403. > > > > Regards > > > > Rüdiger > > > > Von: William A Rowe Jr > > Gesendet: Montag, 17. September 2018 22:27 > > An: httpd > > Betreff: Re: minor nit in mod_ssl > > > > On Mon, Sep 17, 2018 at 2:56 AM Stefan Eissing > wrote: > > > > > > mod_ssl/ssl_engine.kernel.c, 353: logs ERR (APLOGNO(02033)) when > strict_sni_vhost_check is enabled and a request comes in without SNI. > > > > > > Question: is a downgrade from ERR to INFO/DEBUG backportable or do > we consider this a break of compatibility? > > > > > > > > On Mon, Sep 17, 2018 at 10:43 AM William A Rowe Jr clan.net> wrote: > > > > > > It is entirely appropriate to turn down the volume. That's what > module-by-module loglevels are there for. > > > > > > This is the loglevel of typical garbage request streams; > > > > [Mon Sep 17 11:44:43.036820 2018] [core:debug] [pid 26317:tid > 140199172134656] protocol.c(965): (20014)Internal error (specific > information not available): [client 127.0.0.1:34974] Failed to read > request header line (null) > > [Mon Sep 17 11:44:43.036871 2018] [core:debug] [pid 26317:tid > 140199172134656] protocol.c(1318): [client127.0.0.1:34974] AH00567: > request failed: error reading the headers > > [Mon Sep 17 15:24:46.146311 2018] [core:debug] [pid 26413:tid > 140199180527360] protocol.c(860): [client127.0.0.1:35330] AH02418: HTTP > Request Line; Unrecognized protocol 'HTTP/1.xx' (perhaps whitespace was > injected?) > > > > It seems that TLS missing SNI fits this same debug-level pattern of > diagnostics.
Re: minor nit in mod_ssl
I am not opposed. However, there is an explanation added to the request error notes, which normally appears in the 403 response if I am not mistaken? -Stefan > Am 20.09.2018 um 11:40 schrieb Plüm, Rüdiger, Vodafone Group > : > > Can we have set it to info? Debug is very verbose for SSL just to find out > why a HTTP request was replied to with a 403. > > Regards > > Rüdiger > > Von: William A Rowe Jr > Gesendet: Montag, 17. September 2018 22:27 > An: httpd > Betreff: Re: minor nit in mod_ssl > > On Mon, Sep 17, 2018 at 2:56 AM Stefan Eissing > wrote: > > > > mod_ssl/ssl_engine.kernel.c, 353: logs ERR (APLOGNO(02033)) when > > strict_sni_vhost_check is enabled and a request comes in without SNI. > > > > Question: is a downgrade from ERR to INFO/DEBUG backportable or do we > > consider this a break of compatibility? > > > > On Mon, Sep 17, 2018 at 10:43 AM William A Rowe Jr > wrote: > > > > It is entirely appropriate to turn down the volume. That's what > > module-by-module loglevels are there for. > > > This is the loglevel of typical garbage request streams; > > [Mon Sep 17 11:44:43.036820 2018] [core:debug] [pid 26317:tid > 140199172134656] protocol.c(965): (20014)Internal error (specific information > not available): [client 127.0.0.1:34974] Failed to read request header line > (null) > [Mon Sep 17 11:44:43.036871 2018] [core:debug] [pid 26317:tid > 140199172134656] protocol.c(1318): [client127.0.0.1:34974] AH00567: request > failed: error reading the headers > [Mon Sep 17 15:24:46.146311 2018] [core:debug] [pid 26413:tid > 140199180527360] protocol.c(860): [client127.0.0.1:35330] AH02418: HTTP > Request Line; Unrecognized protocol 'HTTP/1.xx' (perhaps whitespace was > injected?) > > It seems that TLS missing SNI fits this same debug-level pattern of > diagnostics.
AW: minor nit in mod_ssl
Can we have set it to info? Debug is very verbose for SSL just to find out why a HTTP request was replied to with a 403. Regards Rüdiger Von: William A Rowe Jr Gesendet: Montag, 17. September 2018 22:27 An: httpd Betreff: Re: minor nit in mod_ssl On Mon, Sep 17, 2018 at 2:56 AM Stefan Eissing mailto:stefan.eiss...@greenbytes.de>> wrote: > > mod_ssl/ssl_engine.kernel.c, 353: logs ERR (APLOGNO(02033)) when > strict_sni_vhost_check is enabled and a request comes in without SNI. > > Question: is a downgrade from ERR to INFO/DEBUG backportable or do we > consider this a break of compatibility? On Mon, Sep 17, 2018 at 10:43 AM William A Rowe Jr mailto:wr...@rowe-clan.net>> wrote: > > It is entirely appropriate to turn down the volume. That's what > module-by-module loglevels are there for. This is the loglevel of typical garbage request streams; [Mon Sep 17 11:44:43.036820 2018] [core:debug] [pid 26317:tid 140199172134656] protocol.c(965): (20014)Internal error (specific information not available): [client 127.0.0.1:34974<http://127.0.0.1:34974>] Failed to read request header line (null) [Mon Sep 17 11:44:43.036871 2018] [core:debug] [pid 26317:tid 140199172134656] protocol.c(1318): [client 127.0.0.1:34974<http://127.0.0.1:34974>] AH00567: request failed: error reading the headers [Mon Sep 17 15:24:46.146311 2018] [core:debug] [pid 26413:tid 140199180527360] protocol.c(860): [client 127.0.0.1:35330<http://127.0.0.1:35330>] AH02418: HTTP Request Line; Unrecognized protocol 'HTTP/1.xx' (perhaps whitespace was injected?) It seems that TLS missing SNI fits this same debug-level pattern of diagnostics.
Re: minor nit in mod_ssl
> Am 19.09.2018 um 17:17 schrieb William A Rowe Jr : > > On Wed, Sep 19, 2018 at 6:39 AM Stefan Eissing > wrote: > > > Am 18.09.2018 um 15:44 schrieb Houser, Rick : > > > > In the same vein, I’ve been running this patch on our builds to get around > > a warning for certificates not matching the hostname. Certificates are not > > expected to match the hostname with many load balancing/uptime detection > > schemes, and this one logs a LOT when it trips on every vhost. Perhaps > > this patch should share the same fate as decided for the TLS missing SNI > > issue? > > Not sure I understand your setup here. Is this the ServerName from the global > server? Otherwise, in a VirtualHost why would you not set the ServerName to > the hostname you are serving? > > Envision a TCP load balancer routing TLS-crypted traffic across a number > of internal hosts, with each of the named virtual hosts presenting the correct > certificate, and known to httpd by their ServerAlias on the outer-facing > interface. > Not terminated at the edge balancer. > > There is the issue of keeping TLS session key encoding in sync across > the backends, obviously. Yes, I can see that. But the mentioned APLOG_WARN only triggers for s->server_hostname, not the Alias list. I therefore imagine the setup to be like: tcp-balancer (x.domain.org) - host a.internal.net ServerName a.internal.net ServerAlias x.domain.org SSLCertificateFile cert-for-x.domain.org.pem - host b.internal.net ServerName b.internal.net ServerAlias x.domain.org SSLCertificateFile cert-for-x.domain.org.pem and maybe that is nicer than writing ServerName x.domain.org ServerAlias b.internal.net SSLCertificateFile cert-for-x.domain.org.pem or it has side-effects that I do not understand. Or, the config is like: SSLCertificateFile cert-for-x.domain.org.pem ServerName b.internal.net ServerName x.domain.org Any way, I would like to understand the issue before removing the APLOG_WARN about non-matching certificates. Which is a valid warning and can prevent debug frustration. Rick, can you help me out here? -Stefan
Re: minor nit in mod_ssl
On Wed, Sep 19, 2018 at 6:39 AM Stefan Eissing wrote: > > > Am 18.09.2018 um 15:44 schrieb Houser, Rick : > > > > In the same vein, I’ve been running this patch on our builds to get > around a warning for certificates not matching the hostname. Certificates > are not expected to match the hostname with many load balancing/uptime > detection schemes, and this one logs a LOT when it trips on every vhost. > Perhaps this patch should share the same fate as decided for the TLS > missing SNI issue? > > Not sure I understand your setup here. Is this the ServerName from the > global server? Otherwise, in a VirtualHost why would you not set the > ServerName to the hostname you are serving? Envision a TCP load balancer routing TLS-crypted traffic across a number of internal hosts, with each of the named virtual hosts presenting the correct certificate, and known to httpd by their ServerAlias on the outer-facing interface. Not terminated at the edge balancer. There is the issue of keeping TLS session key encoding in sync across the backends, obviously.
Re: minor nit in mod_ssl
> Am 18.09.2018 um 15:44 schrieb Houser, Rick :
>
> In the same vein, I’ve been running this patch on our builds to get around a
> warning for certificates not matching the hostname. Certificates are not
> expected to match the hostname with many load balancing/uptime detection
> schemes, and this one logs a LOT when it trips on every vhost. Perhaps this
> patch should share the same fate as decided for the TLS missing SNI issue?
>
> --- httpd-2.4.10_backup/modules/ssl/ssl_engine_init.c 2015-09-30
> 07:50:30.0 -0400
> +++ httpd-2.4.10/modules/ssl/ssl_engine_init.c_new 2015-10-19
> 16:13:51.716000988 -0400
> @@ -1002,7 +1002,7 @@
>
> if (modssl_X509_match_name(ptemp, cert, (const char *)s->server_hostname,
> TRUE, s) == FALSE) {
> -ap_log_error(APLOG_MARK, APLOG_WARNING, 0, s, APLOGNO(01909)
> +ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s, APLOGNO(01909)
> "%s server certificate does NOT include an ID "
> "which matches the server name", key_id);
> }
>
Not sure I understand your setup here. Is this the ServerName from the global
server? Otherwise, in a VirtualHost why would you not set the ServerName to the
hostname you are serving?
-Stefan
>
> Rick Houser
> Web Engineer
>
> From: William A Rowe Jr
> Sent: Monday, September 17, 2018 16:27
> To: httpd
> Subject: Re: minor nit in mod_ssl
>
> EXTERNAL EMAIL
>
>
> On Mon, Sep 17, 2018 at 2:56 AM Stefan Eissing
> wrote:
> >
> > mod_ssl/ssl_engine.kernel.c, 353: logs ERR (APLOGNO(02033)) when
> > strict_sni_vhost_check is enabled and a request comes in without SNI.
> >
> > Question: is a downgrade from ERR to INFO/DEBUG backportable or do we
> > consider this a break of compatibility?
>
>
>
> On Mon, Sep 17, 2018 at 10:43 AM William A Rowe Jr
> wrote:
> >
> > It is entirely appropriate to turn down the volume. That's what
> > module-by-module loglevels are there for.
>
>
> This is the loglevel of typical garbage request streams;
>
> [Mon Sep 17 11:44:43.036820 2018] [core:debug] [pid 26317:tid
> 140199172134656] protocol.c(965): (20014)Internal error (specific information
> not available): [client 127.0.0.1:34974] Failed to read request header line
> (null)
> [Mon Sep 17 11:44:43.036871 2018] [core:debug] [pid 26317:tid
> 140199172134656] protocol.c(1318): [client127.0.0.1:34974] AH00567: request
> failed: error reading the headers
> [Mon Sep 17 15:24:46.146311 2018] [core:debug] [pid 26413:tid
> 140199180527360] protocol.c(860): [client127.0.0.1:35330] AH02418: HTTP
> Request Line; Unrecognized protocol 'HTTP/1.xx' (perhaps whitespace was
> injected?)
>
> It seems that TLS missing SNI fits this same debug-level pattern of
> diagnostics.
RE: minor nit in mod_ssl
In the same vein, I’ve been running this patch on our builds to get around a
warning for certificates not matching the hostname. Certificates are not
expected to match the hostname with many load balancing/uptime detection
schemes, and this one logs a LOT when it trips on every vhost. Perhaps this
patch should share the same fate as decided for the TLS missing SNI issue?
--- httpd-2.4.10_backup/modules/ssl/ssl_engine_init.c 2015-09-30
07:50:30.0 -0400
+++ httpd-2.4.10/modules/ssl/ssl_engine_init.c_new 2015-10-19
16:13:51.716000988 -0400
@@ -1002,7 +1002,7 @@
if (modssl_X509_match_name(ptemp, cert, (const char *)s->server_hostname,
TRUE, s) == FALSE) {
-ap_log_error(APLOG_MARK, APLOG_WARNING, 0, s, APLOGNO(01909)
+ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s, APLOGNO(01909)
"%s server certificate does NOT include an ID "
"which matches the server name", key_id);
}
Rick Houser
Web Engineer
From: William A Rowe Jr
Sent: Monday, September 17, 2018 16:27
To: httpd
Subject: Re: minor nit in mod_ssl
EXTERNAL EMAIL
On Mon, Sep 17, 2018 at 2:56 AM Stefan Eissing
mailto:stefan.eiss...@greenbytes.de>> wrote:
>
> mod_ssl/ssl_engine.kernel.c, 353: logs ERR (APLOGNO(02033)) when
> strict_sni_vhost_check is enabled and a request comes in without SNI.
>
> Question: is a downgrade from ERR to INFO/DEBUG backportable or do we
> consider this a break of compatibility?
On Mon, Sep 17, 2018 at 10:43 AM William A Rowe Jr
mailto:wr...@rowe-clan.net>> wrote:
>
> It is entirely appropriate to turn down the volume. That's what
> module-by-module loglevels are there for.
This is the loglevel of typical garbage request streams;
[Mon Sep 17 11:44:43.036820 2018] [core:debug] [pid 26317:tid 140199172134656]
protocol.c(965): (20014)Internal error (specific information not available):
[client 127.0.0.1:34974<http://127.0.0.1:34974>] Failed to read request header
line (null)
[Mon Sep 17 11:44:43.036871 2018] [core:debug] [pid 26317:tid 140199172134656]
protocol.c(1318): [client 127.0.0.1:34974<http://127.0.0.1:34974>] AH00567:
request failed: error reading the headers
[Mon Sep 17 15:24:46.146311 2018] [core:debug] [pid 26413:tid 140199180527360]
protocol.c(860): [client 127.0.0.1:35330<http://127.0.0.1:35330>] AH02418: HTTP
Request Line; Unrecognized protocol 'HTTP/1.xx' (perhaps whitespace was
injected?)
It seems that TLS missing SNI fits this same debug-level pattern of diagnostics.
Re: minor nit in mod_ssl
On Mon, Sep 17, 2018 at 2:56 AM Stefan Eissing wrote: > > mod_ssl/ssl_engine.kernel.c, 353: logs ERR (APLOGNO(02033)) when strict_sni_vhost_check is enabled and a request comes in without SNI. > > Question: is a downgrade from ERR to INFO/DEBUG backportable or do we consider this a break of compatibility? On Mon, Sep 17, 2018 at 10:43 AM William A Rowe Jr wrote: > > It is entirely appropriate to turn down the volume. That's what module-by-module loglevels are there for. This is the loglevel of typical garbage request streams; [Mon Sep 17 11:44:43.036820 2018] [core:debug] [pid 26317:tid 140199172134656] protocol.c(965): (20014)Internal error (specific information not available): [client 127.0.0.1:34974] Failed to read request header line (null) [Mon Sep 17 11:44:43.036871 2018] [core:debug] [pid 26317:tid 140199172134656] protocol.c(1318): [client 127.0.0.1:34974] AH00567: request failed: error reading the headers [Mon Sep 17 15:24:46.146311 2018] [core:debug] [pid 26413:tid 140199180527360] protocol.c(860): [client 127.0.0.1:35330] AH02418: HTTP Request Line; Unrecognized protocol 'HTTP/1.xx' (perhaps whitespace was injected?) It seems that TLS missing SNI fits this same debug-level pattern of diagnostics.
Re: minor nit in mod_ssl
It is entirely appropriate to turn down the volume. That's what module-by-module loglevels are there for. On Mon, Sep 17, 2018, 02:56 Stefan Eissing wrote: > Just a quick question, if we can reach consensus here: > > mod_ssl/ssl_engine.kernel.c, 353: logs ERR (APLOGNO(02033)) when > strict_sni_vhost_check is enabled and a request comes in without SNI. > > Question: is a downgrade from ERR to INFO/DEBUG backportable or do we > consider this a break of compatibility? > > > Rationale: This is annoying me in my logs where I scan for errors daily. > While I can filter this out, I'd rather have the server behave better by > default. The requests at my server are done by scanners, who monitor > responses on port 443. Nothing I can do about and they will not go away. > > Cheers, > > Stefan > >
minor nit in mod_ssl
Just a quick question, if we can reach consensus here: mod_ssl/ssl_engine.kernel.c, 353: logs ERR (APLOGNO(02033)) when strict_sni_vhost_check is enabled and a request comes in without SNI. Question: is a downgrade from ERR to INFO/DEBUG backportable or do we consider this a break of compatibility? Rationale: This is annoying me in my logs where I scan for errors daily. While I can filter this out, I'd rather have the server behave better by default. The requests at my server are done by scanners, who monitor responses on port 443. Nothing I can do about and they will not go away. Cheers, Stefan
