Hi Martin,

On Thu, Jul 12, 2018 at 6:55 PM, Martin RADEL <
martin.ra...@rbinternational.com> wrote:

> Hi all,
>
>
>
> we have a strange situation with our HAProxy, running on Version 1.8.8
> with OpenSSL.
>
> (See the details in the setup listed below - some lines are missing by
> intention. It’s a config snippet with just the interesting parts mentioned)
>
>
>
> Initial situation:
>
> We run a HAProxy instance which enforces mutual TLS on the frontend,
> allowing only clients to connect to it when they will present a specific
> certificate.
>
> The HAPRoxy also does mutual TLS to the backend, presenting its frontend
> server certificate to the backend as a client certificate.
>
> The backend only allows connections when the HAProxy’s certificate is
> presented to it.
>
> To have a proper TLS handshake to the backend, and to be able to identify
> a man-in-the-middle scenario, we use the “verify required” directive
> together with the “verifyhost” directive.
>
>
>
> The HAProxy is not able to resolve the backend’s real DNS-hostname, so
> it’s using the IP of the server instead (10.1.1.1)
>
> The backend is presenting a wildcard server certificate with a
> DNS-hostname looking like “*.foo.bar”
>
>
>
>
>
> In this configuration, one could assume that there is always a certificate
> name mismatch with the TLS handshake:
>
> Backend server will present its server certificate with a proper DNS
> hostname in it, and the HAProxy will find out that it doesn’t match the
> initially used connection name “10.1.1.1”.
>
>
>

​Just checking if the IP hasn't been by any chance included in the
certificate subjectAlternateNames ?
​

>
>
> Issue:
>
> In fact the connection to the backend works all the time, even when there
> is a name mismatch and even if we use the “verify required” option together
> with “verifyhost”.
>
> Seems as if HAProxy completely ignores the mismatch, as if we would use
> the option “verify none”.
>
>
>
>
>
> According to HAProxy documentation, this is clearly a not-expected
> behavior:
>
> http://cbonte.github.io/haproxy-dconv/1.8/configuration.html#5.2-verify
>
>
>
>
>
> Can somebody please share some knowledge why this is working, or can
> confirm that this is a bug?
>
>
>
>
>
> #---------------------------------------------------------------------
>
> # Global settings
>
> #---------------------------------------------------------------------
>
> global
>
>     log         /dev/log local2
>
>     pidfile     /run/haproxy/haproxy.pid
>
>     maxconn     20000
>
>     ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+
> AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!
> aNULL:!MD5:!DSS:!RC4
>
>     ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11
>
>     stats socket /var/lib/haproxy/stats
>
>
>
> #---------------------------------------------------------------------
>
> # common defaults that all the 'listen' and 'backend' sections will
>
> # use if not designated in their block
>
> #---------------------------------------------------------------------
>
> defaults
>
>     mode                    http
>
>     log                     global
>
>     option                  http-server-close
>
>     option                  redispatch
>
>     retries                 3
>
>     maxconn                 20000
>
>     errorfile 503           /etc/haproxy/errorpage.html
>
>     default-server          init-addr last,libc,none
>
>
>
> # ====================================================
>
> #  HAPROXY CONFIG WITH WILDCARD CERTIFICATE ON BACKEND
>
> # ====================================================
>
> # --- FRONTEND1 (TLS with mutual authentication) ---
>
> frontend FRONTEND1
>
>     option                  forwardfor except 127.0.0.0/8
>
>     acl authorizedClient ssl_c_s_dn(cn) -m str -f /etc/haproxy/authorized_
> clients.cfg
>
>     bind *:443 ssl crt /etc/haproxy/certs/frontend-server-certificate.pem
> ca-file /etc/haproxy/certs/frontend-ca-certificates.crt verify required
>
>     use_backend BACKEND1 if authorizedClient frontend
>
>
>
> # --- BACKEND1
>
> backend BACKEND1
>
>     option                  forwardfor except 127.0.0.0/8
>
>     server BACKEND1-server 10.1.1.1:443 check inter 30s  verify required
> ssl verifyhost *.foo.bar <http://www.foo.bar> ca-file
> /etc/haproxy/certs/backend-ca-certificates.crt crt
> /etc/haproxy/certs/frontend-server-certificate.pem
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> This message and any attachment ("the Message") are confidential. If you
> have received the Message in error, please notify the sender immediately
> and delete the Message from your system, any use of the Message is
> forbidden. Correspondence via e-mail is primarily for information purposes.
> RBI neither makes nor accepts legally binding statements via e-mail unless
> explicitly agreed otherwise. Information pursuant to § 14 Austrian
> Companies Code: Raiffeisen Bank International AG; Registered Office: Am
> Stadtpark 9
> <https://maps.google.com/?q=Am+Stadtpark+9&entry=gmail&source=g>, 1030
> Vienna,Austria; Company Register Number: FN 122119m at the Commercial Court
> of Vienna (Handelsgericht Wien).
>


​Regards,
Igor​

Reply via email to