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