Hi again Sorry for the late answer, I have had covid so I’ve been out of commission for a while. Attaching the pcap files, this is taken from the client side. From what I can tell, it uses TLS1.2 in both versions. The client uses TLS sessions, not tickets, since tickets use an extension which is not present in the ClientHello message.
Best regards Johan Andersson From: Johan Andersson Sent: den 3 februari 2021 14:43 To: Илья Шипицин <chipits...@gmail.com> Cc: HAProxy <haproxy@formilux.org> Subject: RE: SSL session resumption Hi I have some wireshark logs, but I’ll have to go through them to make sure it doesn’t contain any sensitive information. Best regards Johan From: Илья Шипицин <chipits...@gmail.com<mailto:chipits...@gmail.com>> Sent: den 3 februari 2021 14:10 To: Johan Andersson <j...@hms.se<mailto:j...@hms.se>> Cc: HAProxy <haproxy@formilux.org<mailto:haproxy@formilux.org>> Subject: Re: SSL session resumption Can you provide wireshark capture? It is very useful On Wed, Feb 3, 2021, 5:39 PM Johan Andersson <j...@hms.se<mailto:j...@hms.se>> wrote: To whom it may concern We have recently upgraded out HAProxy version from 2.1.3 to 2.2.4. After the upgrade we got customer complaints that the data usage of their devices had gone up. Our company sells proprietary hardware that logs data and sends that to a web service which we host. These devices are often deployed remotely and connected via shaky 3G connections with data-capped SIM cards, so low data usage is very important. After some digging with Wireshark, we found that the SSL sessions are not resumed. Instead a new handshake is initiated every time the device sends data. Which is typically once an hour. We have set the global tune.ssl.lifetime parameter to 24h and the tune.ssl.cachesize to 100000 and this has worked since HAProxy version 1.6.9 when we first introduced it. We have also tested with the latest 2.1.11 release of HAProxy and it behaves the same way as the 2.1.3 version. We have also tested with 2.2.0 and 2.2.8 and they behave the same as 2.2.4. We have tried reproducing this with openssl s_client, saving the session id between requests but can’t reproduce it that way. We have also pored over the change logs between versions to see if there is some change that could make HAProxy behave this way. We’re at a loss here, what could cause this behavior, and how can we fix it? Best regards Johan Andersson Development Engineer Global Platforms Cloud Team HMS Industrial Networks AB Stationsgatan 37, Box 4126 300 04 Halmstad, Sweden Email: j...@hms-networks.com<mailto:j...@hms-networks.com> [cid:image001.png@01D6FA2D.98D58250] HALMSTAD | BARCELONA | BEIJING | BOSTON | BUCHEN | CHICAGO | COVENTRY | DEN BOSCH | DUBAI | IGUALADA | KARLSRUHE | MILAN | MULHOUSE | NIVELLES | PUNE | RAVENSBURG | SEOUL | SINGAPORE | TOKYO | WETZLAR
Haproxy 2.2.4.pcapng
Description: Haproxy 2.2.4.pcapng
Haproxy 2.1.3.pcapng
Description: Haproxy 2.1.3.pcapng
