Re: SSL Labs says my server isn't doing ssl session resumption
On Sun, Jun 20, 2021 at 05:20:41PM -0600, Shawn Heisey wrote: > On 6/20/2021 3:16 PM, Lukas Tribus wrote: > > It's a haproxy bug, affecting 2.4 releases, I've filed an issue in our > > tracker: > > > > https://github.com/haproxy/haproxy/issues/1297 > > Almost always when I report a problem I'm having with a mature piece of > software, I expect the issue to be PEBCAK, not an actual bug. Either way, I > really enjoy being a part of an open source community. Hehe we have no business trying to hide bugs, as they'll affect all of us. It's much better to humbly recognize them and fix them :-) > It took me a while to figure out how to get the proper code branch with git > for 2.4 development. 2.4 is not in development anymore, it's stable (and LTS -- long term supported). Please don't try to do any development on 2.4, you'll only waste your time, because if you want to propose some changes, you'll first be requested to rebase your changes on top of latest development and that could take you a while in certain areas. The right way to participate is to pull the development branch, and update it once in a while (e.g. every time you're going back to your developments, such as once a week). This way if something breaks, chances are that the person who did the breaking change still has fresh memories about it and will be able to help, and instantly fix the trouble or explain how to adapt your code. Do not worry too much for the risk of instabilities, the published code is tested and even the haproxy.org site runs on it. It's quite sufficient for development and even for either a personal site, or one that is properly monitored and operated by skilled admins. > I don't think it's on github. This is the first time > I've seen completely separate repositories for different versions. Not > complaining ... I bet there's a very good reason for it. It precisely is because we don't want to receive pull reqs nor issues on the wrong branch, and github doesn't offer sufficient flexibility to allow to disable PRs on certain branches nor repos. I can't blame them too much for this, it's their core business, they have no reason to offer free hosting and resources with no hopes to see forks and PRs in return that indirectly bring them new users. But overall the current model looks like a good balance offering a good efficiency to everyone. > I wish I knew C a lot better than I do ... That's what about half of the long time contributors started to say before become regular ones, welcome! You'll get back to it easily, do not worry. C is easy to learn (or it wouldn't have lasted 50+ years), it just has a number of traps, but those not using it all day long are extra careful and generally do not fall into them. It's like with parachutes, accidents only affect those routinely using them and who are less careful. > though I expect that for TLS > code, even very strong C skills would leave me clueless without spending > several weeks or months doing a deep dive. I agree. Cryptography code is cryptic, that's the part I understand the least. In addition, OpenSSL is even older than haproxy and has 2.5 decades of evolving API, naming schemes, coding styles and incompatible features behind, that inevitably leave some confusion at plenty of places. HAProxy itself is not exempt from this (it's only in 2.4 that we finally renamed all "sess*" functions that were acting on streams and not sessions). But that's why there are comments in the code to explain what the developer tries to do and why. If you find some areas that are too cryptic and not commented enough, feel free to ask here for precisions. You can even use "git blame" on the file then "git show" on the commit IDs to see who worked last on the lines you don't understand. Sometimes you'll find more explanations in the commit message. If you don't, feel free to ask, that's how it works! Willy
Re: OT: About WebPageTest results (was Re: SSL Labs says my server isn't doing ssl session resumption)
> Am 21.06.2021 um 18:25 schrieb Shawn Heisey : > > On 2021-06-20 06:03, Shawn Heisey wrote: >> Unrelated, and off topic because it's mostly about Apache, but strange: >> I've been doing some tests with webpagetest.org, and seeing REALLY >> long load times for some resources in their waterfall graph. I see no >> speed problems when I load the pages from my workstation at home. > > Followup on this, information which others here might find useful: > > By default WebPageTest defaults to traffic shaping of 5 Mbps down and 1 Mbps > up, which it thinks simulates a cable connection. That's laughable -- I get > 460 Mbps down and 12 Mpbs up on my cable connection, and I'm not even paying > for the maximum bandwidth I COULD get. > > Long story short, hitting a web page with about 25 megabytes of images takes > over 40 seconds for WebPageTest to render. If I switch from that default > "5/1 Mbps Cable" traffic shaping to native (no traffic shaping at all) the > render takes 1.8 seconds, which is approximately what I see when I hit the > page myself. Server in AWS. > > When I do the math, 40 seconds is actually quite fast for downloading those > images on a 5 megabit connection. So there was no actual problem. WBT needs > to make the choice of traffic shaping a lot more prominent, and provide more > realistic options than what they have at the moment. To even see bandwidth > options, you have to open advanced settings. And the only option I could see > in their list that's faster than the default (aside from native) is FIOS, > which they've got at 20Mb down and 5Mb up. They have forums, I'll make > suggestions there. > > Thanks, > Shawn > It’s probably to make DDoSes more difficult (like basically everything these days) I never got around to host my own WPT instance (for work). I mainly use the public version to to get „a feeling“ for the speed and to weed out any caching effects of local browsers with pages too complex to use curl or httpie….
OT: About WebPageTest results (was Re: SSL Labs says my server isn't doing ssl session resumption)
On 2021-06-20 06:03, Shawn Heisey wrote: Unrelated, and off topic because it's mostly about Apache, but strange: I've been doing some tests with webpagetest.org, and seeing REALLY long load times for some resources in their waterfall graph. I see no speed problems when I load the pages from my workstation at home. Followup on this, information which others here might find useful: By default WebPageTest defaults to traffic shaping of 5 Mbps down and 1 Mbps up, which it thinks simulates a cable connection. That's laughable -- I get 460 Mbps down and 12 Mpbs up on my cable connection, and I'm not even paying for the maximum bandwidth I COULD get. Long story short, hitting a web page with about 25 megabytes of images takes over 40 seconds for WebPageTest to render. If I switch from that default "5/1 Mbps Cable" traffic shaping to native (no traffic shaping at all) the render takes 1.8 seconds, which is approximately what I see when I hit the page myself. Server in AWS. When I do the math, 40 seconds is actually quite fast for downloading those images on a 5 megabit connection. So there was no actual problem. WBT needs to make the choice of traffic shaping a lot more prominent, and provide more realistic options than what they have at the moment. To even see bandwidth options, you have to open advanced settings. And the only option I could see in their list that's faster than the default (aside from native) is FIOS, which they've got at 20Mb down and 5Mb up. They have forums, I'll make suggestions there. Thanks, Shawn
Re: SSL Labs says my server isn't doing ssl session resumption
On 6/20/2021 3:16 PM, Lukas Tribus wrote: It's a haproxy bug, affecting 2.4 releases, I've filed an issue in our tracker: https://github.com/haproxy/haproxy/issues/1297 Almost always when I report a problem I'm having with a mature piece of software, I expect the issue to be PEBCAK, not an actual bug. Either way, I really enjoy being a part of an open source community. It took me a while to figure out how to get the proper code branch with git for 2.4 development. I don't think it's on github. This is the first time I've seen completely separate repositories for different versions. Not complaining ... I bet there's a very good reason for it. I wish I knew C a lot better than I do ... though I expect that for TLS code, even very strong C skills would leave me clueless without spending several weeks or months doing a deep dive. Thanks, Shawn
Re: SSL Labs says my server isn't doing ssl session resumption
On Sun, Jun 20, 2021 at 11:31:10PM +0200, Willy Tarreau wrote: > On Sun, Jun 20, 2021 at 11:16:15PM +0200, Lukas Tribus wrote: > > Hello Shawn, > > > > On Sun, 20 Jun 2021 at 14:03, Shawn Heisey wrote: > > > > > > On 6/20/2021 1:52 AM, Lukas Tribus wrote: > > > > Can you try disabling threading, by putting nbthread 1 in your config? > > > > > > That didn't help. From testssl.sh: > > > > > > SSL Session ID support yes > > > Session Resumption Tickets: yes, ID: no > > > > It's a haproxy bug, affecting 2.4 releases, I've filed an issue in our > > tracker: > > > > https://github.com/haproxy/haproxy/issues/1297 Strangely, applying this method to haproxy.org still works for me: $ openssl s_client -connect haproxy.org:443 -reconnect -no_ticket -servername haproxy.org -tls1_2 2>/dev/null | grep -e "Cipher is" New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256 Reused, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256 Reused, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256 Reused, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256 Reused, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256 Reused, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256 So there might be something in the config or certificate that changes the behavior. Or it was accidently fixed in 2.5-dev but we've only recently upgraded it. Or maybe the libssl there. For now I have no idea what to check for so I think I'll first put a plain 2.4 there and try to reproduce. Willy
Re: SSL Labs says my server isn't doing ssl session resumption
On Sun, Jun 20, 2021 at 11:16:15PM +0200, Lukas Tribus wrote: > Hello Shawn, > > On Sun, 20 Jun 2021 at 14:03, Shawn Heisey wrote: > > > > On 6/20/2021 1:52 AM, Lukas Tribus wrote: > > > Can you try disabling threading, by putting nbthread 1 in your config? > > > > That didn't help. From testssl.sh: > > > > SSL Session ID support yes > > Session Resumption Tickets: yes, ID: no > > It's a haproxy bug, affecting 2.4 releases, I've filed an issue in our > tracker: > > https://github.com/haproxy/haproxy/issues/1297 Thanks Lukas! > Willy wrote: > > I don't know if the config is responsible for this but I've just tested > > on haproxy.org and it does work there: > > > > Session resumption (caching) Yes > > Session resumption (tickets) Yes > > demo.haproxy.org suggests code running is quite old though: > > # curl -s http://demo.haproxy.org/ | grep released > http://www.haproxy.org/; style="text-decoration: > none;">HAProxy version 1.7.12-84aad5b, released 2019/10/25 > # Yep this one is the old 1.7 I'm using at home. I guess you'll prefer this one: $ curl -s http://stats.haproxy.org/ | grep released http://www.haproxy.org/; style="text-decoration: none;">HAProxy version 2.5-dev0-b63dbb-142, released 2021/06/11 I should probably totally kill demo.haproxy.org by now, it used to provide a demo of the stats page, but by now it's totally outdated! Cheers, Willy
Re: SSL Labs says my server isn't doing ssl session resumption
Hello Shawn, On Sun, 20 Jun 2021 at 14:03, Shawn Heisey wrote: > > On 6/20/2021 1:52 AM, Lukas Tribus wrote: > > Can you try disabling threading, by putting nbthread 1 in your config? > > That didn't help. From testssl.sh: > > SSL Session ID support yes > Session Resumption Tickets: yes, ID: no It's a haproxy bug, affecting 2.4 releases, I've filed an issue in our tracker: https://github.com/haproxy/haproxy/issues/1297 Willy wrote: > I don't know if the config is responsible for this but I've just tested > on haproxy.org and it does work there: > > Session resumption (caching) Yes > Session resumption (tickets) Yes demo.haproxy.org suggests code running is quite old though: # curl -s http://demo.haproxy.org/ | grep released http://www.haproxy.org/; style="text-decoration: none;">HAProxy version 1.7.12-84aad5b, released 2019/10/25 # Regards, Lukas
Re: SSL Labs says my server isn't doing ssl session resumption
On 6/20/2021 1:52 AM, Lukas Tribus wrote: Can you try disabling threading, by putting nbthread 1 in your config? That didn't help. From testssl.sh: SSL Session ID support yes Session Resumption Tickets: yes, ID: no An upgrade to 2.4.1 would also be advisable, it actually fixes a locking issue with SSL session cache (not sure whether that could really be the root cause though). This actually is already running 2.4.1. I accidentally killed my basement server (with version 2.4.0), so until I can acquire what I need to fix it, I'm fiddling with the server I have in AWS. That server hosts my email and my "professional" web page. And I moved a small portion of my "main" website (which normally runs in my basement) to it as well. Today I upgraded haproxy from 1.8 to 2.4.1. - Unrelated, and off topic because it's mostly about Apache, but strange: I've been doing some tests with webpagetest.org, and seeing REALLY long load times for some resources in their waterfall graph. I see no speed problems when I load the pages from my workstation at home. Wondering if maybe webpagetest.org and AWS have trouble getting connected to each other. The haproxy logs seem to be telling me that the delay is in the backend connection, not the frontend. I've been fiddling with the Apache config... the backend connection is now http/2 and I've switched to the Event MPM. None of that has helped what webpagetest sees, though it did make a big difference in how quickly the page loads for me. Here's a portion of the haproxy log for one of the slow connections reported by webpagetest.org: 1/0/0/38833/59785 200 1074085 The image is a little over a megabyte, and it looks like it took nearly 39 seconds for Apache to get the HTTP headers in the response back to haproxy, then another 20 seconds to actually transfer the file, which matches what the waterfall graph says. That's absolutely nuts. If I load the same page from home, it takes a second or two for the whole page - with a lot of images that are larger than a megabyte. HTTP/2 makes them all load at the same time. As I said above, that's not really super-relevant for this list. But if anyone has any wisdom to share, I'd love to hear it, even if it's off-list. Thanks, Shawn
Re: SSL Labs says my server isn't doing ssl session resumption
Hello Shawn, On Sun, 20 Jun 2021 at 08:39, Shawn Heisey wrote: > This is what SSL Labs now says for the thing that started this thread: > > Session resumption (caching)No (IDs assigned but not accepted) > Session resumption (tickets)Yes > > I'd like to get the caching item fixed, but I haven't figured that out > yet. Can you try disabling threading, by putting nbthread 1 in your config? An upgrade to 2.4.1 would also be advisable, it actually fixes a locking issue with SSL session cache (not sure whether that could really be the root cause though). Lukas
Re: SSL Labs says my server isn't doing ssl session resumption
вс, 20 июн. 2021 г. в 11:43, Shawn Heisey : > On 6/17/2021 1:01 AM, Willy Tarreau wrote: > > I don't know if the config is responsible for this but I've just tested > > on haproxy.org and it does work there: > > > >Session resumption (caching) Yes > >Session resumption (tickets) Yes > > Many thanks to everyone who replied, and countless people who published > comments and articles on the Internet. You're awesome. > > I've managed to get my SSL Labs grade to A+. I really like testssl.sh. it is something loved by compliance people. for example, if you have to certify for PCI DSS, you have to setup A+ actually > > I've only got one remaining yellow item on the testssl report: > > BREACH (CVE-2013-3587)potentially NOT ok, "gzip" > HTTP compression detected. - only supplied "/" tested > > This is what SSL Labs now says for the thing that started this thread: > > Session resumption (caching)No (IDs assigned but not accepted) > Session resumption (tickets)Yes > > I'd like to get the caching item fixed, but I haven't figured that out > yet. Hoping that getting the tickets working is enough for most > clients. Not that I feel TLS is slow at all, seems zippy enough. Any > chance that the problem is my openssl library rather than haproxy? It's > stock Ubuntu 18. Here's the openssl info from haproxy -vv: > > Built with OpenSSL version : OpenSSL 1.1.1 11 Sep 2018 > Running on OpenSSL version : OpenSSL 1.1.1 11 Sep 2018 > > As for the list of functional clients that SSL Labs generates, people > using IE on anything older than Windows 10 are out of luck with my web > pages, as are those using Safari 8 and below. Java 6 and 7 are also > unsupported. I really do not care about people using those clients. > Upgrade your Java version or get a better browser. > unfortunately, TLS does not allow you to signal such properly. client will only see "unable to establish connection" without any clear reason for them. but you are right, it is completely up to you whether to choose compatibility and bigger client coverage or high SSL Labs rating. > > Thanks, > Shawn > >
Re: SSL Labs says my server isn't doing ssl session resumption
On 6/17/2021 1:01 AM, Willy Tarreau wrote: I don't know if the config is responsible for this but I've just tested on haproxy.org and it does work there: Session resumption (caching) Yes Session resumption (tickets) Yes Many thanks to everyone who replied, and countless people who published comments and articles on the Internet. You're awesome. I've managed to get my SSL Labs grade to A+. I really like testssl.sh. I've only got one remaining yellow item on the testssl report: BREACH (CVE-2013-3587)potentially NOT ok, "gzip" HTTP compression detected. - only supplied "/" tested This is what SSL Labs now says for the thing that started this thread: Session resumption (caching)No (IDs assigned but not accepted) Session resumption (tickets)Yes I'd like to get the caching item fixed, but I haven't figured that out yet. Hoping that getting the tickets working is enough for most clients. Not that I feel TLS is slow at all, seems zippy enough. Any chance that the problem is my openssl library rather than haproxy? It's stock Ubuntu 18. Here's the openssl info from haproxy -vv: Built with OpenSSL version : OpenSSL 1.1.1 11 Sep 2018 Running on OpenSSL version : OpenSSL 1.1.1 11 Sep 2018 As for the list of functional clients that SSL Labs generates, people using IE on anything older than Windows 10 are out of luck with my web pages, as are those using Safari 8 and below. Java 6 and 7 are also unsupported. I really do not care about people using those clients. Upgrade your Java version or get a better browser. Thanks, Shawn
Re: SSL Labs says my server isn't doing ssl session resumption
On 6/16/2021 9:26 AM, Lukas Tribus wrote: That is not true, you can disable TLS tickets and still get resumption on TLSv1.2. Disabling TLSv1.0 does not mean disabling Session ID caching. What do you see with testssl.sh ? That was an interesting rabbit hole. Finally got it downloaded properly and ran it. testssl.sh says: SSL Session ID support yes Session Resumption Tickets no, ID: yes I think that means I'm probably OK on this. What would you say? Thanks, Shawn
Re: SSL Labs says my server isn't doing ssl session resumption
On Fri, Jun 11, 2021 at 06:48:09PM -0600, Shawn Heisey wrote: > I'm fiddling with ssl labs to see how I can improve my TLS setup. > > Here's what they say about a site I have behind haproxy with TLS: > > https://www.elyograg.org/foo/haproxy-ssllabs-session-resumption-not-working.png > > They claim that session resumption isn't working. I'm hoping that I've just > done something wrong... which will be bad for my ego but great for getting > problems fixed. I did have the option to disable tls tickets, but when I > took it out, my ssl labs grade didn't go down, so it's still not there. > > This is what I have in the global section: > > global > log 127.0.0.1 len 65535 format rfc5424 local0 > log 127.0.0.1 len 65535 format rfc5424 local1 notice > maxconn 4096 > daemon > spread-checks 2 > tune.bufsize65536 > tune.http.logurilen 49152 > tune.ssl.cachesize 10 > tune.ssl.lifetime 900 > ssl-server-verify none > tune.ssl.default-dh-param 2048 > ssl-default-bind-ciphers EECDH+AESGCM:EDH+AESGCM > ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 > ssl-default-server-ciphers > RC4-MD5:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-SHA:AES256-SHA:AES256-SHA256 > stats socket /etc/haproxy/stats.socket > > I don't think there's anything else in the config that could affect this, > but if there is something that would help diagnose, let me know. I don't know if the config is responsible for this but I've just tested on haproxy.org and it does work there: Session resumption (caching) Yes Session resumption (tickets) Yes Our bind line looks like this: bind:443 ssl alpn h2,http/1.1 npn h2,http/1.1 no-sslv3 crt ... ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:!DSS:!EDH ecdhe prime256v1 and we don't have any ssl-default-* nor tune.ssl.* setting. Maybe you could start bisecting among these parameters. Willy
Re: SSL Labs says my server isn't doing ssl session resumption
ср, 16 июн. 2021 г. в 20:27, Lukas Tribus : > On Wed, 16 Jun 2021 at 17:03, Илья Шипицин wrote: > > > > ssl sessions are for tls1.0 (disabled in your config) > > tls1.2 uses tls tickets for resumption > > That is not true, you can disable TLS tickets and still get resumption > on TLSv1.2. Disabling TLSv1.0 does not mean disabling Session ID > caching. > > ok, I need to refresh that in memory > > What do you see with testssl.sh ? > > > Lukas >
Re: SSL Labs says my server isn't doing ssl session resumption
On Wed, 16 Jun 2021 at 17:03, Илья Шипицин wrote: > > ssl sessions are for tls1.0 (disabled in your config) > tls1.2 uses tls tickets for resumption That is not true, you can disable TLS tickets and still get resumption on TLSv1.2. Disabling TLSv1.0 does not mean disabling Session ID caching. What do you see with testssl.sh ? Lukas
Re: SSL Labs says my server isn't doing ssl session resumption
ssl sessions are for tls1.0 (disabled in your config) tls1.2 uses tls tickets for resumption what does ssl labs say on tls tickets ? сб, 12 июн. 2021 г. в 05:51, Shawn Heisey : > I'm fiddling with ssl labs to see how I can improve my TLS setup. > > Here's what they say about a site I have behind haproxy with TLS: > > > https://www.elyograg.org/foo/haproxy-ssllabs-session-resumption-not-working.png > > They claim that session resumption isn't working. I'm hoping that I've > just done something wrong... which will be bad for my ego but great for > getting problems fixed. I did have the option to disable tls tickets, > but when I took it out, my ssl labs grade didn't go down, so it's still > not there. > > This is what I have in the global section: > > global > log 127.0.0.1 len 65535 format rfc5424 local0 > log 127.0.0.1 len 65535 format rfc5424 local1 notice > maxconn 4096 > daemon > spread-checks 2 > tune.bufsize65536 > tune.http.logurilen 49152 > tune.ssl.cachesize 10 > tune.ssl.lifetime 900 > ssl-server-verify none > tune.ssl.default-dh-param 2048 > ssl-default-bind-ciphers EECDH+AESGCM:EDH+AESGCM > ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 > ssl-default-server-ciphers > RC4-MD5:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-SHA:AES256-SHA:AES256-SHA256 > stats socket /etc/haproxy/stats.socket > > I don't think there's anything else in the config that could affect > this, but if there is something that would help diagnose, let me know. > > Here's info about haproxy, which I compiled from source: > > root@smeagol:~# haproxy -vv > HAProxy version 2.4.0-6cbbecf 2021/05/14 - https://haproxy.org/ > Status: long-term supported branch - will stop receiving fixes around Q2 > 2026. > Known bugs: http://www.haproxy.org/bugs/bugs-2.4.0.html > Running on: Linux 5.8.0-55-generic #62~20.04.1-Ubuntu SMP Wed Jun 2 > 08:55:04 UTC 2021 x86_64 > Build options : >TARGET = linux-glibc >CPU = native >CC = cc >CFLAGS = -O2 -march=native -g -Wall -Wextra > -Wdeclaration-after-statement -fwrapv -Wno-address-of-packed-member > -Wno-unused-label -Wno-sign-compare -Wno-unused-parameter -Wno-clobbered > -Wno-missing-field-initializers -Wno-cast-function-type -Wtype-limits > -Wshift-negative-value -Wshift-overflow=2 -Wduplicated-cond > -Wnull-dereference >OPTIONS = USE_PCRE_JIT=1 USE_OPENSSL=1 USE_ZLIB=1 USE_SYSTEMD=1 >DEBUG = > > Feature list : +EPOLL -KQUEUE +NETFILTER -PCRE +PCRE_JIT -PCRE2 > -PCRE2_JIT +POLL -PRIVATE_CACHE +THREAD -PTHREAD_PSHARED +BACKTRACE > -STATIC_PCRE -STATIC_PCRE2 +TPROXY +LINUX_TPROXY +LINUX_SPLICE +LIBCRYPT > +CRYPT_H +GETADDRINFO +OPENSSL -LUA +FUTEX +ACCEPT4 -CLOSEFROM +ZLIB > -SLZ +CPU_AFFINITY +TFO +NS +DL +RT -DEVICEATLAS -51DEGREES -WURFL > +SYSTEMD -OBSOLETE_LINKER +PRCTL +THREAD_DUMP -EVPORTS -OT -QUIC -PROMEX > -MEMORY_PROFILING > > Default settings : >bufsize = 16384, maxrewrite = 1024, maxpollevents = 200 > > Built with multi-threading support (MAX_THREADS=64, default=4). > Built with OpenSSL version : OpenSSL 1.1.1f 31 Mar 2020 > Running on OpenSSL version : OpenSSL 1.1.1f 31 Mar 2020 > OpenSSL library supports TLS extensions : yes > OpenSSL library supports SNI : yes > OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3 > Built with network namespace support. > Built with zlib version : 1.2.11 > Running on zlib version : 1.2.11 > Compression algorithms supported : identity("identity"), > deflate("deflate"), raw-deflate("deflate"), gzip("gzip") > Built with transparent proxy support using: IP_TRANSPARENT > IPV6_TRANSPARENT IP_FREEBIND > Built with PCRE version : 8.39 2016-06-14 > Running on PCRE version : 8.39 2016-06-14 > PCRE library supports JIT : yes > Encrypted password support via crypt(3): yes > Built with gcc compiler version 9.3.0 > > Available polling systems : >epoll : pref=300, test result OK > poll : pref=200, test result OK > select : pref=150, test result OK > Total: 3 (3 usable), will use epoll. > > Available multiplexer protocols : > (protocols marked as cannot be specified using 'proto' > keyword) >h2 : mode=HTTP side=FE|BE mux=H2 > flags=HTX|CLEAN_ABRT|HOL_RISK|NO_UPG > fcgi : mode=HTTP side=BEmux=FCGI > flags=HTX|HOL_RISK|NO_UPG > : mode=HTTP side=FE|BE mux=H1 flags=HTX >h1 : mode=HTTP side=FE|BE mux=H1 > flags=HTX|NO_UPG > : mode=TCPside=FE|BE mux=PASS flags= > none : mode=TCPside=FE|BE mux=PASS > flags=NO_UPG > > Available services : none > > Available filters : > [SPOE] spoe > [CACHE] cache > [FCGI] fcgi-app > [COMP] compression > [TRACE] trace > >
SSL Labs says my server isn't doing ssl session resumption
I'm fiddling with ssl labs to see how I can improve my TLS setup. Here's what they say about a site I have behind haproxy with TLS: https://www.elyograg.org/foo/haproxy-ssllabs-session-resumption-not-working.png They claim that session resumption isn't working. I'm hoping that I've just done something wrong... which will be bad for my ego but great for getting problems fixed. I did have the option to disable tls tickets, but when I took it out, my ssl labs grade didn't go down, so it's still not there. This is what I have in the global section: global log 127.0.0.1 len 65535 format rfc5424 local0 log 127.0.0.1 len 65535 format rfc5424 local1 notice maxconn 4096 daemon spread-checks 2 tune.bufsize65536 tune.http.logurilen 49152 tune.ssl.cachesize 10 tune.ssl.lifetime 900 ssl-server-verify none tune.ssl.default-dh-param 2048 ssl-default-bind-ciphers EECDH+AESGCM:EDH+AESGCM ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 ssl-default-server-ciphers RC4-MD5:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-SHA:AES256-SHA:AES256-SHA256 stats socket /etc/haproxy/stats.socket I don't think there's anything else in the config that could affect this, but if there is something that would help diagnose, let me know. Here's info about haproxy, which I compiled from source: root@smeagol:~# haproxy -vv HAProxy version 2.4.0-6cbbecf 2021/05/14 - https://haproxy.org/ Status: long-term supported branch - will stop receiving fixes around Q2 2026. Known bugs: http://www.haproxy.org/bugs/bugs-2.4.0.html Running on: Linux 5.8.0-55-generic #62~20.04.1-Ubuntu SMP Wed Jun 2 08:55:04 UTC 2021 x86_64 Build options : TARGET = linux-glibc CPU = native CC = cc CFLAGS = -O2 -march=native -g -Wall -Wextra -Wdeclaration-after-statement -fwrapv -Wno-address-of-packed-member -Wno-unused-label -Wno-sign-compare -Wno-unused-parameter -Wno-clobbered -Wno-missing-field-initializers -Wno-cast-function-type -Wtype-limits -Wshift-negative-value -Wshift-overflow=2 -Wduplicated-cond -Wnull-dereference OPTIONS = USE_PCRE_JIT=1 USE_OPENSSL=1 USE_ZLIB=1 USE_SYSTEMD=1 DEBUG = Feature list : +EPOLL -KQUEUE +NETFILTER -PCRE +PCRE_JIT -PCRE2 -PCRE2_JIT +POLL -PRIVATE_CACHE +THREAD -PTHREAD_PSHARED +BACKTRACE -STATIC_PCRE -STATIC_PCRE2 +TPROXY +LINUX_TPROXY +LINUX_SPLICE +LIBCRYPT +CRYPT_H +GETADDRINFO +OPENSSL -LUA +FUTEX +ACCEPT4 -CLOSEFROM +ZLIB -SLZ +CPU_AFFINITY +TFO +NS +DL +RT -DEVICEATLAS -51DEGREES -WURFL +SYSTEMD -OBSOLETE_LINKER +PRCTL +THREAD_DUMP -EVPORTS -OT -QUIC -PROMEX -MEMORY_PROFILING Default settings : bufsize = 16384, maxrewrite = 1024, maxpollevents = 200 Built with multi-threading support (MAX_THREADS=64, default=4). Built with OpenSSL version : OpenSSL 1.1.1f 31 Mar 2020 Running on OpenSSL version : OpenSSL 1.1.1f 31 Mar 2020 OpenSSL library supports TLS extensions : yes OpenSSL library supports SNI : yes OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3 Built with network namespace support. Built with zlib version : 1.2.11 Running on zlib version : 1.2.11 Compression algorithms supported : identity("identity"), deflate("deflate"), raw-deflate("deflate"), gzip("gzip") Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT IP_FREEBIND Built with PCRE version : 8.39 2016-06-14 Running on PCRE version : 8.39 2016-06-14 PCRE library supports JIT : yes Encrypted password support via crypt(3): yes Built with gcc compiler version 9.3.0 Available polling systems : epoll : pref=300, test result OK poll : pref=200, test result OK select : pref=150, test result OK Total: 3 (3 usable), will use epoll. Available multiplexer protocols : (protocols marked as cannot be specified using 'proto' keyword) h2 : mode=HTTP side=FE|BE mux=H2 flags=HTX|CLEAN_ABRT|HOL_RISK|NO_UPG fcgi : mode=HTTP side=BEmux=FCGI flags=HTX|HOL_RISK|NO_UPG : mode=HTTP side=FE|BE mux=H1 flags=HTX h1 : mode=HTTP side=FE|BE mux=H1 flags=HTX|NO_UPG : mode=TCPside=FE|BE mux=PASS flags= none : mode=TCPside=FE|BE mux=PASS flags=NO_UPG Available services : none Available filters : [SPOE] spoe [CACHE] cache [FCGI] fcgi-app [COMP] compression [TRACE] trace