Re: SSL Labs says my server isn't doing ssl session resumption

2021-06-25 Thread Willy Tarreau
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)

2021-06-21 Thread Rainer Duffner



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

2021-06-21 Thread 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



Re: SSL Labs says my server isn't doing ssl session resumption

2021-06-20 Thread Shawn Heisey

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

2021-06-20 Thread Willy Tarreau
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

2021-06-20 Thread Willy Tarreau
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

2021-06-20 Thread Lukas Tribus
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

2021-06-20 Thread Shawn Heisey

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

2021-06-20 Thread Lukas Tribus
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

2021-06-20 Thread Илья Шипицин
вс, 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

2021-06-20 Thread 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. 
 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

2021-06-19 Thread Shawn Heisey

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

2021-06-17 Thread Willy Tarreau
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

2021-06-16 Thread Илья Шипицин
ср, 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

2021-06-16 Thread 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.


What do you see with testssl.sh ?


Lukas



Re: SSL Labs says my server isn't doing ssl session resumption

2021-06-16 Thread Илья Шипицин
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

2021-06-11 Thread 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