You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Yann Ylavic <yl...@gmail.com> on 2018/10/19 13:27:41 UTC

Re: [users@httpd] SNI extension for healthchecks

Hi Dominik,

sorry for the late response.

On Tue, Oct 16, 2018 at 12:44 PM Dominik Stillhard
<Do...@united-security-providers.ch> wrote:
>
> I face the problem, that the sni extension is not set on healthcheck-requests to a backend using tls. Because healthchecks are negative, this leads to ordinary requests also beeing denied.
>
> on the backend server i have the following error:
>
> AH02033: No hostname was provided via SNI for a name based virtual host
>
> I’ve also investigated it with wireshark, the extionsion is defenitely not set.

It should not, see below.

>
> My config looks as follows:
[]
>
>   <Proxy balancer://mycluster lbmethod=byrequests>
>     BalancerMember https://127.0.0.1:8443
>     BalancerMember https://127.0.0.1:8444

https://tools.ietf.org/html/rfc6066#section-3 :
    ...
    Literal IPv4 and IPv6 addresses are not permitted in "HostName".

So httpd won't set the SNI in your case, I guess "localhost" instead
of 127.0.0.1 would work...

>
>     ProxyPreserveHost On

While this is meaningful for forwarded client requests (their "Host:"
header can be preserved on the backend side, instead of using the one
from the ProxyPass/BalancerMember directive), it does not apply to
healthcheck where connections/requests are created on the httpd proxy
and there is nothing to preserve, so the only hostname/SNI to use in
the one from ProxyPass/BalancerMember here.

So for healthcheck requests to be accepted by your backend (name based
virtual host), you need to set real hostnames in BalancerMember(s)
above, or use "localhost" provided that "ServerAlias localhost" is
configured on the backend for the relevant vhost.


Regards,
Yann.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


AW: [users@httpd] SNI extension for healthchecks

Posted by Dominik Stillhard <Do...@united-security-providers.ch>.
Oh thanks i will try this!

> -----Ursprüngliche Nachricht-----
> Von: Yann Ylavic <yl...@gmail.com>
> Gesendet: Freitag, 19. Oktober 2018 15:28
> An: users@httpd.apache.org
> Betreff: Re: [users@httpd] SNI extension for healthchecks
> 
> Hi Dominik,
> 
> sorry for the late response.
> 
> On Tue, Oct 16, 2018 at 12:44 PM Dominik Stillhard <Dominik.Stillhard@united-
> security-providers.ch> wrote:
> >
> > I face the problem, that the sni extension is not set on healthcheck-requests to a
> backend using tls. Because healthchecks are negative, this leads to ordinary requests
> also beeing denied.
> >
> > on the backend server i have the following error:
> >
> > AH02033: No hostname was provided via SNI for a name based virtual
> > host
> >
> > I’ve also investigated it with wireshark, the extionsion is defenitely not set.
> 
> It should not, see below.
> 
> >
> > My config looks as follows:
> []
> >
> >   <Proxy balancer://mycluster lbmethod=byrequests>
> >     BalancerMember https://127.0.0.1:8443
> >     BalancerMember https://127.0.0.1:8444
> 
> https://tools.ietf.org/html/rfc6066#section-3 :
>     ...
>     Literal IPv4 and IPv6 addresses are not permitted in "HostName".
> 
> So httpd won't set the SNI in your case, I guess "localhost" instead of 127.0.0.1 would
> work...
> 
> >
> >     ProxyPreserveHost On
> 
> While this is meaningful for forwarded client requests (their "Host:"
> header can be preserved on the backend side, instead of using the one from the
> ProxyPass/BalancerMember directive), it does not apply to healthcheck where
> connections/requests are created on the httpd proxy and there is nothing to preserve,
> so the only hostname/SNI to use in the one from ProxyPass/BalancerMember here.
> 
> So for healthcheck requests to be accepted by your backend (name based virtual
> host), you need to set real hostnames in BalancerMember(s) above, or use "localhost"
> provided that "ServerAlias localhost" is configured on the backend for the relevant
> vhost.
> 
> 
> Regards,
> Yann.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org


AW: [users@httpd] SNI extension for healthchecks

Posted by Dominik Stillhard <Do...@united-security-providers.ch>.
Hi Yann,

I solved it. The environment variable is read out by mod_ssl correctly. 
The Problem was that mod_proxy_hchceck does not use ap_proxy_determine_connection (which normally sets backend->ssl_hostname), but has it's own function hc_determine_connection.
so the backend->ssl_hostname, to which the environment variable is set, was null and therefore still no SNI.
It can be solved by setting backend->ssl_hostname in hc_get_backend. 

-------------------------------------------------------------
   TLSv1 Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 222
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 218
            Version: TLS 1.0 (0x0301)
            Random: d316a98e1b71beceba455598bdb3e8a23797ff2cf3202563...
            Session ID Length: 0
            Cipher Suites Length: 102
            Cipher Suites (51 suites)
            Compression Methods Length: 1
            Compression Methods (1 method)
            Extensions Length: 75
            Extension: server_name (len=22)
            Extension: ec_point_formats (len=4)
            Extension: supported_groups (len=28)
            Extension: SessionTicket TLS (len=0)
            Extension: heartbeat (len=1)
-------------------------------------------------------------

I have attached your patch with this addition included.

Regards,
Dominik


> -----Ursprüngliche Nachricht-----
> Von: Stillhard, Dominik
> Gesendet: Dienstag, 23. Oktober 2018 16:15
> An: users@httpd.apache.org
> Betreff: AW: [users@httpd] SNI extension for healthchecks [signed OK]
> 
> Hi Yann,
> 
> I've tested your patch. It doesn't solve the problem. Still no SNI in healthchecks...
> 
> Regards Dominik
> 
> 
> > -----Ursprüngliche Nachricht-----
> > Von: Yann Ylavic <yl...@gmail.com>
> > Gesendet: Montag, 22. Oktober 2018 15:15
> > An: users@httpd.apache.org
> > Betreff: Re: [users@httpd] SNI extension for healthchecks
> >
> > Hi Dominik,
> >
> > On Mon, Oct 22, 2018 at 1:49 PM Dominik Stillhard <Dominik.Stillhard@united-
> security-
> > providers.ch> wrote:
> > >
> > > I've tested the configuration you proposed.
> > > Unfortunately the problem is not solved by using hostnames.
> >
> > Yes, sorry, I was looking at 2.5/trunk code, while 2.4.x is missing one commit
> > (http://svn.apache.org/r1818726).
> > Without this change in 2.4.x, hostnames work for proxied request but not for
> > healthcheck (supposedly).
> >
> > Could you please try with the attached patch (a backport of r1818726 to 2.4.x)?
> >
> > Regards,
> > Yann.

AW: [users@httpd] SNI extension for healthchecks

Posted by Dominik Stillhard <Do...@united-security-providers.ch>.
Hi Yann,

I've tested your patch. It doesn't solve the problem. Still no SNI in healthchecks...

Regards Dominik


> -----Ursprüngliche Nachricht-----
> Von: Yann Ylavic <yl...@gmail.com>
> Gesendet: Montag, 22. Oktober 2018 15:15
> An: users@httpd.apache.org
> Betreff: Re: [users@httpd] SNI extension for healthchecks
> 
> Hi Dominik,
> 
> On Mon, Oct 22, 2018 at 1:49 PM Dominik Stillhard <Dominik.Stillhard@united-security-
> providers.ch> wrote:
> >
> > I've tested the configuration you proposed.
> > Unfortunately the problem is not solved by using hostnames.
> 
> Yes, sorry, I was looking at 2.5/trunk code, while 2.4.x is missing one commit
> (http://svn.apache.org/r1818726).
> Without this change in 2.4.x, hostnames work for proxied request but not for
> healthcheck (supposedly).
> 
> Could you please try with the attached patch (a backport of r1818726 to 2.4.x)?
> 
> Regards,
> Yann.

Re: [users@httpd] SNI extension for healthchecks

Posted by Yann Ylavic <yl...@gmail.com>.
Hi Dominik,

On Mon, Oct 22, 2018 at 1:49 PM Dominik Stillhard
<Do...@united-security-providers.ch> wrote:
>
> I've tested the configuration you proposed.
> Unfortunately the problem is not solved by using hostnames.

Yes, sorry, I was looking at 2.5/trunk code, while 2.4.x is missing
one commit (http://svn.apache.org/r1818726).
Without this change in 2.4.x, hostnames work for proxied request but
not for healthcheck (supposedly).

Could you please try with the attached patch (a backport of r1818726 to 2.4.x)?

Regards,
Yann.

AW: [users@httpd] SNI extension for healthchecks

Posted by Dominik Stillhard <Do...@united-security-providers.ch>.
Hi Yann,

I've tested the configuration you proposed. 
Unfortunately the problem is not solved by using hostnames.

I still cannot see an SNI-Extension with wireshark:
Secure Sockets Layer
    TLSv1 Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 189
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 185
            Version: TLS 1.2 (0x0303)
            Random: d0d713b41985eb8a78e657e12b9913bb77c97e7a0d1fce85...
            Session ID Length: 0
            Cipher Suites Length: 56
            Cipher Suites (28 suites)
            Compression Methods Length: 1
            Compression Methods (1 method)
            Extensions Length: 88
            Extension: ec_point_formats (len=4)
            Extension: supported_groups (len=12)
            Extension: SessionTicket TLS (len=0)
            Extension: encrypt_then_mac (len=0)
            Extension: extended_master_secret (len=0)
            Extension: signature_algorithms (len=48)
 
My configuration is very simple:
Proxy Config:
--------------------------------------------------------------------------------------------
LogLevel debug
LogLevel ssl_module:debug
LogLevel proxy_hcheck:debug
Listen 127.0.0.1:443
ServerName www.localhost.com
SSLSessionCache nonenotnull

<VirtualHost 127.0.0.1:443>
    ServerName www.localhost.com
    ServerAlias localhost.com
    SSLCertificateFile /etc/httpd/ssl/ca.crt
    SSLCertificateKeyFile /etc/httpd/ssl/ca.key
    SSLEngine on
    SSLProxyEngine on

    ProxyHCExpr isok {%{REQUEST_STATUS} =~ /^[23]/}
    ProxyHCTemplate template hcinterval=4 hcexpr=isok hcmethod=get hcuri=/index.html

  <Proxy balancer://mycluster lbmethod=byrequests >
    BalancerMember https://sesdev.tarsec.com:10030 hctemplate=template
    BalancerMember https://sesdev.tarsec.com:10031 hctemplate=template 
    SSLProxyCheckPeerName off
    SSLProxyCheckPeerExpire off
    SSLProxyProtocol  TLSv1
  </Proxy>

  <Location />
    ProxyPass  balancer://mycluster/
    ProxyPassReverse  balancer://mycluster/
  </Location>


</VirtualHost>
--------------------------------------------------------------------------------------------


Backends Configuration:
--------------------------------------------------------------------------------------------
ServerName            sesdev.tarsec.com
Listen                127.0.0.1:10030
DocumentRoot           ${SERVER_ROOT}/htdocs
ServerRoot             ${SERVER_ROOT}
TypesConfig            ${SERVER_ROOT}/conf/mime.types

LogLevel               debug
ErrorLog               ${SERVER_ROOT}/logs/error_log
TransferLog            ${SERVER_ROOT}/logs/access_log
PidFile                ${SERVER_ROOT}/logs/pid

SSLSessionCache nonenotnull

SSLCertificateFile     ${TEST_ENV}/../testca/CaRoot/certs/sesdev.tarsec.com.cert.pem  
SSLCertificateKeyFile  ${TEST_ENV}/../testca/CaRoot/keys/sesdev.tarsec.com.key.pem
SSLProtocol TLSv1
SSLEngine              on

  
<VirtualHost sesdev.tarsec.com:10030>
  SSLEngine              on
  ServerName             sesdev.tarsec.com
  ServerAlias            sesdev.tarsec.com
  <Location />
  
  </Location>
</VirtualHost>
--------------------------------------------------------------------------------------------


Thanks! Regards Dominik



> -----Ursprüngliche Nachricht-----
> Von: Yann Ylavic <yl...@gmail.com>
> Gesendet: Freitag, 19. Oktober 2018 15:28
> An: users@httpd.apache.org
> Betreff: Re: [users@httpd] SNI extension for healthchecks
> 
> Hi Dominik,
> 
> sorry for the late response.
> 
> On Tue, Oct 16, 2018 at 12:44 PM Dominik Stillhard <Dominik.Stillhard@united-
> security-providers.ch> wrote:
> >
> > I face the problem, that the sni extension is not set on healthcheck-requests to a
> backend using tls. Because healthchecks are negative, this leads to ordinary requests
> also beeing denied.
> >
> > on the backend server i have the following error:
> >
> > AH02033: No hostname was provided via SNI for a name based virtual
> > host
> >
> > I’ve also investigated it with wireshark, the extionsion is defenitely not set.
> 
> It should not, see below.
> 
> >
> > My config looks as follows:
> []
> >
> >   <Proxy balancer://mycluster lbmethod=byrequests>
> >     BalancerMember https://127.0.0.1:8443
> >     BalancerMember https://127.0.0.1:8444
> 
> https://tools.ietf.org/html/rfc6066#section-3 :
>     ...
>     Literal IPv4 and IPv6 addresses are not permitted in "HostName".
> 
> So httpd won't set the SNI in your case, I guess "localhost" instead of 127.0.0.1 would
> work...
> 
> >
> >     ProxyPreserveHost On
> 
> While this is meaningful for forwarded client requests (their "Host:"
> header can be preserved on the backend side, instead of using the one from the
> ProxyPass/BalancerMember directive), it does not apply to healthcheck where
> connections/requests are created on the httpd proxy and there is nothing to preserve,
> so the only hostname/SNI to use in the one from ProxyPass/BalancerMember here.
> 
> So for healthcheck requests to be accepted by your backend (name based virtual
> host), you need to set real hostnames in BalancerMember(s) above, or use "localhost"
> provided that "ServerAlias localhost" is configured on the backend for the relevant
> vhost.
> 
> 
> Regards,
> Yann.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org


Re: [users@httpd] SNI extension for healthchecks

Posted by Yann Ylavic <yl...@gmail.com>.
Hi,

On Mon, Oct 22, 2018 at 3:58 PM Sanjay Kumar Sahu
<sa...@gmail.com> wrote:
>
> Currently we are facing critical Apache/Kerberos authentication issue in our RHEL7 server running with Apache/2.4 upon changing Keytab with Crypto type=AES256. Previously it's Crypto type=all. Please check following with the details.

This is unrelated to this thread, please open a new one.

Regards,
Yann.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Re: [users@httpd] SNI extension for healthchecks

Posted by Sanjay Kumar Sahu <sa...@gmail.com>.
HI All !

Currently we are facing critical Apache/Kerberos authentication issue in
our RHEL7 server running with Apache/2.4 upon changing Keytab with Crypto
type=AES256. Previously it's Crypto type=all. Please check following with
the details.

We are using mod_auth_kerb on Red Hat Enterprise Linux  for our application
MediaWiki 1.30.0 running in Apache/2.4
And we never face such issue related to kerberos authentication since we
used the keytab with following cipher algorithm in the encryption method.

(des-cbc-crc)
(des-cbc-md5)
(aes256-cts-hmac-sha1-96)
(aes128-cts-hmac-sha1-96)

Later, the DES crypto type is catagoried in weak crypto type and it's
denied to use in Produciton for security reason.

And we are asked to use the keytab using Advanced Encryption Standard (AES)
Cryptography with either of types (AES128 or AES265) for following cipher
algorithm.

(aes256-cts-hmac-sha1-96)
(aes128-cts-hmac-sha1-96)

But, unfortunately neither of the keytab encrypted with AES Crypto (AES128
or AES265) are working under Apache/2.4 and throws following error in HTTPD
server Error_log.


Error_log
-----------------
gss_accept_sec_context() failed: Unspecified GSS failure. Minor code may
provide more information (, No key table entry found for the SPN)

Please let us know if there is any solution to resolve for the issue.

On Fri, Oct 19, 2018 at 6:57 PM Yann Ylavic <yl...@gmail.com> wrote:

> Hi Dominik,
>
> sorry for the late response.
>
> On Tue, Oct 16, 2018 at 12:44 PM Dominik Stillhard
> <Do...@united-security-providers.ch> wrote:
> >
> > I face the problem, that the sni extension is not set on
> healthcheck-requests to a backend using tls. Because healthchecks are
> negative, this leads to ordinary requests also beeing denied.
> >
> > on the backend server i have the following error:
> >
> > AH02033: No hostname was provided via SNI for a name based virtual host
> >
> > I’ve also investigated it with wireshark, the extionsion is defenitely
> not set.
>
> It should not, see below.
>
> >
> > My config looks as follows:
> []
> >
> >   <Proxy balancer://mycluster lbmethod=byrequests>
> >     BalancerMember https://127.0.0.1:8443
> >     BalancerMember https://127.0.0.1:8444
>
> https://tools.ietf.org/html/rfc6066#section-3 :
>     ...
>     Literal IPv4 and IPv6 addresses are not permitted in "HostName".
>
> So httpd won't set the SNI in your case, I guess "localhost" instead
> of 127.0.0.1 would work...
>
> >
> >     ProxyPreserveHost On
>
> While this is meaningful for forwarded client requests (their "Host:"
> header can be preserved on the backend side, instead of using the one
> from the ProxyPass/BalancerMember directive), it does not apply to
> healthcheck where connections/requests are created on the httpd proxy
> and there is nothing to preserve, so the only hostname/SNI to use in
> the one from ProxyPass/BalancerMember here.
>
> So for healthcheck requests to be accepted by your backend (name based
> virtual host), you need to set real hostnames in BalancerMember(s)
> above, or use "localhost" provided that "ServerAlias localhost" is
> configured on the backend for the relevant vhost.
>
>
> Regards,
> Yann.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>

-- 
*Thanks & Regards,*


*Sanjay Kumar Sahu*