Re: SNI matching issue when hostname ends with trailing dot
Hello Warren, On Tue, 22 May 2018 at 15:48, Warren Rohner wrote: > The other day I inadvertently appended a trailing dot to the hostname > for one of our sites (e.g. https://www.example.com.), and when I did > this HAProxy returned the default cert to the browser rather than the > expected cert for that particular site. I'm not certain, but could > this be a possible bug in the HAProxy code that matches servername > provided by browser's TLS SNI extension against all loaded certificates? The browsers are supposed to strip the trailing dots from SNI, as per: https://tools.ietf.org/html/rfc6066#section-3 > The hostname is represented as a byte string using ASCII encoding > without a trailing dot. I know they currently don't, but that doesn't mean there is a bug in haproxy. curl does it correctly: https://github.com/curl/curl/commit/5de8d84098db1bd24e7fffefbe14e81f2a05995a Mozilla has a bug report about this here: https://bugzilla.mozilla.org/show_bug.cgi?id=1008120 There is also a discussion about the disparity between SNI and the http host header on the HTTP WG: https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0430.html However, none of this indicates that a *server* should drop the trailing dot from the incoming SNI and I agree. Looks like browser vendors are not very keen on fixing those edge cases, as can been seen from the bug reports, however I do not agree that we should be dropping the trailing dot in haproxy. If you need a workaround in haproxy, I suggest you configure this alternative SNI->cert mapping using crt-list: https://cbonte.github.io/haproxy-dconv/1.8/configuration.html#5.1-crt-list cheers, lukas
Re: SNI matching issue when hostname ends with trailing dot
Hi Warren, As far as I know this is by design. If you do not want this behavior you need to use strict-sni in your bind statement. Regards Sander > On 27 Jul 2018, at 12:47, Warren Rohner wrote: > > Hi HAProxy list > > Just thought I'd resend this report from May in case it was missed. If it's a > non-issue, I apologise. > > Regards > Warren > > At 15:47 2018/05/22, Warren Rohner wrote: >> Hi HAProxy list >> >> We use an HAProxy 1.7.11 instance to terminate SSL and load balance 100+ >> websites. >> >> The simplified bind line below specifies a default cert (i.e. >> secure.example.com.pem) as required in this HAProxy version, and a directory >> path to all other certs (i.e. ./): >> >> bind 127.0.0.1:443 ssl crt secure.example.com.pem crt ./ >> >> This configuration works as expected. HAProxy finds all certs and the >> correct one is used when TLS SNI extension is provided. For example, >> visiting https://secure.example.com/ and https://www.example.com/ (with SNI >> capable web browser) both work perfectly. >> >> The other day I inadvertently appended a trailing dot to the hostname for >> one of our sites (e.g. https://www.example.com.), and when I did this >> HAProxy returned the default cert to the browser rather than the expected >> cert for that particular site. I'm not certain, but could this be a possible >> bug in the HAProxy code that matches servername provided by browser's TLS >> SNI extension against all loaded certificates? >> >> As a further example of problem, I note that the issue can be reproduced on >> the haproxy.org website as follows using OpenSSL client: >> >> Works as expected, HAProxy returns correct cert for haproxy.org: >> openssl s_client -connect www.haproxy.org:443 -servername www.haproxy.org >> >> With trailing dot on servername, HAProxy returns what I think is the default >> cert (an invalid StarrCom-issued cert for formilux.org): >> openssl s_client -connect www.haproxy.org:443 -servername www.haproxy.org . >> >> Please let me know if I should provide any further information. >> >> Regards >> Warren
Re: SNI matching issue when hostname ends with trailing dot
Hi HAProxy list Just thought I'd resend this report from May in case it was missed. If it's a non-issue, I apologise. Regards Warren At 15:47 2018/05/22, Warren Rohner wrote: Hi HAProxy list We use an HAProxy 1.7.11 instance to terminate SSL and load balance 100+ websites. The simplified bind line below specifies a default cert (i.e. secure.example.com.pem) as required in this HAProxy version, and a directory path to all other certs (i.e. ./): bind 127.0.0.1:443 ssl crt secure.example.com.pem crt ./ This configuration works as expected. HAProxy finds all certs and the correct one is used when TLS SNI extension is provided. For example, visiting https://secure.example.com/ and https://www.example.com/ (with SNI capable web browser) both work perfectly. The other day I inadvertently appended a trailing dot to the hostname for one of our sites (e.g. https://www.example.com.), and when I did this HAProxy returned the default cert to the browser rather than the expected cert for that particular site. I'm not certain, but could this be a possible bug in the HAProxy code that matches servername provided by browser's TLS SNI extension against all loaded certificates? As a further example of problem, I note that the issue can be reproduced on the haproxy.org website as follows using OpenSSL client: Works as expected, HAProxy returns correct cert for haproxy.org: openssl s_client -connect www.haproxy.org:443 -servername www.haproxy.org With trailing dot on servername, HAProxy returns what I think is the default cert (an invalid StarrCom-issued cert for formilux.org): openssl s_client -connect www.haproxy.org:443 -servername www.haproxy.org. Please let me know if I should provide any further information. Regards Warren
SNI matching issue when hostname ends with trailing dot
Hi HAProxy list We use an HAProxy 1.7.11 instance to terminate SSL and load balance 100+ websites. The simplified bind line below specifies a default cert (i.e. secure.example.com.pem) as required in this HAProxy version, and a directory path to all other certs (i.e. ./): bind 127.0.0.1:443 ssl crt secure.example.com.pem crt ./ This configuration works as expected. HAProxy finds all certs and the correct one is used when TLS SNI extension is provided. For example, visiting https://secure.example.com/ and https://www.example.com/ (with SNI capable web browser) both work perfectly. The other day I inadvertently appended a trailing dot to the hostname for one of our sites (e.g. https://www.example.com.), and when I did this HAProxy returned the default cert to the browser rather than the expected cert for that particular site. I'm not certain, but could this be a possible bug in the HAProxy code that matches servername provided by browser's TLS SNI extension against all loaded certificates? As a further example of problem, I note that the issue can be reproduced on the haproxy.org website as follows using OpenSSL client: Works as expected, HAProxy returns correct cert for haproxy.org: openssl s_client -connect www.haproxy.org:443 -servername www.haproxy.org With trailing dot on servername, HAProxy returns what I think is the default cert (an invalid StarrCom-issued cert for formilux.org): openssl s_client -connect www.haproxy.org:443 -servername www.haproxy.org. Please let me know if I should provide any further information. Regards Warren