Hi,

The certificate subject and subject alternate name are set to “*.foo.bar” (I’m 
replacing real DNS name here with foo.bar here because of security reasons).
There is no IP address included in the server’s certificate.

We are not using SNI on our clients.

BR
Martin


From: ig...@encompasscorporation.com<mailto:ig...@encompasscorporation.com> 
[mailto:ig...@encompasscorporation.com]
Sent: Freitag, 13. Juli 2018 03:27
To: Martin RADEL 
<martin.ra...@rbinternational.com<mailto:martin.ra...@rbinternational.com>>
Cc: haproxy@formilux.org<mailto:haproxy@formilux.org>
Subject: Re: TLS handshake works with certificate name mismatch using "verify 
required" and "verifyhost"

On Fri, Jul 13, 2018 at 11:08 AM, Igor Cicimov 
<ig...@encompasscorporation.com<mailto:ig...@encompasscorporation.com>> wrote:
Hi Martin,

On Thu, Jul 12, 2018 at 6:55 PM, Martin RADEL 
<martin.ra...@rbinternational.com<mailto: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<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcbonte.github.io%2Fhaproxy-dconv%2F1.8%2Fconfiguration.html%235.2-verify&data=02%7C01%7Cmartin.radel%40rbinternational.com%7C7e7f5dccd90b4745bc0408d5e8601877%7C9b511fdaf0b143a5b06e1e720f64520a%7C1%7C1%7C636670421783654330&sdata=jl8aPpmP%2BtWoT2D4pjEqtU710EQxZg7LLNr3gTh4nEM%3D&reserved=0>


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<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2F127.0.0.0%2F8&data=02%7C01%7Cmartin.radel%40rbinternational.com%7C7e7f5dccd90b4745bc0408d5e8601877%7C9b511fdaf0b143a5b06e1e720f64520a%7C1%7C1%7C636670421783664338&sdata=%2FUqCo%2BIaPk3YnRAJYvRZAKykLc0yfzj42pufo2BrJ20%3D&reserved=0>
    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<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2F127.0.0.0%2F8&data=02%7C01%7Cmartin.radel%40rbinternational.com%7C7e7f5dccd90b4745bc0408d5e8601877%7C9b511fdaf0b143a5b06e1e720f64520a%7C1%7C1%7C636670421783674347&sdata=wobKyu3xkU37ZUyXsF0gXQv9Q28ARYEJZhPD8VDjrkg%3D&reserved=0>
    server BACKEND1-server 
10.1.1.1:443<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2F10.1.1.1%3A443&data=02%7C01%7Cmartin.radel%40rbinternational.com%7C7e7f5dccd90b4745bc0408d5e8601877%7C9b511fdaf0b143a5b06e1e720f64520a%7C1%7C1%7C636670421783674347&sdata=gCEQKcTBQ%2B%2Fc2MKr%2BLfkTQz7%2BIJjI7y1tz8jnZoIfYQ%3D&reserved=0>
 check inter 30s  verify required ssl verifyhost 
*.foo.bar<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.foo.bar&data=02%7C01%7Cmartin.radel%40rbinternational.com%7C7e7f5dccd90b4745bc0408d5e8601877%7C9b511fdaf0b143a5b06e1e720f64520a%7C1%7C1%7C636670421783684355&sdata=ezWoVH71QZNaXLwrqDe8PD%2FcWjWD3AxS3VgtSMPHKrE%3D&reserved=0>
 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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaps.google.com%2F%3Fq%3DAm%2BStadtpark%2B9%26entry%3Dgmail%26source%3Dg&data=02%7C01%7Cmartin.radel%40rbinternational.com%7C7e7f5dccd90b4745bc0408d5e8601877%7C9b511fdaf0b143a5b06e1e720f64520a%7C1%7C0%7C636670421783694363&sdata=hrkVo4P3Z84EemtrrMr5qeZLzAjkTn2%2Fxt9kW8ye974%3D&reserved=0>,
 1030 Vienna,Austria; Company Register Number: FN 122119m at the Commercial 
Court of Vienna (Handelsgericht Wien).


​Regards,
Igor​

​
Ah, another thing I forgot to ask and might be relevant, are you using SNI 
enabled client for the testing or not?​

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, 1030 
Vienna,Austria; Company Register Number: FN 122119m at the Commercial Court of 
Vienna (Handelsgericht Wien).

Reply via email to