[Pkg-openssl-devel] Bug#935133: Bug#935133: slow TLS handshake renders browsers and email client unusable

[nbi]

On 8/19/19 3:19 PM, Kurt Roeckx wrote:
> On Mon, Aug 19, 2019 at 02:57:14PM -0700, nbi wrote:
>> Package: libssl1.0.0,libssl1.0.2,libssl1.1,openssl
>> Version:
>> libssl1.0.0 1.0.2l-1~bpo8+1
>> libssl1.0.2 1.0.2q-2
>> libssl1.1 1.1.1c-1
>> openssl 1.1.1c-1
>>
>> After booting a distribution (sparkylinux.org) based on "testing" everything appears to be working correctly. Browsers and email clients access their destinations without
>> perceptible delay regardless of whether the connection is secure or not. However after some extended web usage (I often see this problem after about an hour of web surfing)
>> browsers get stuck on TLS connections. This problem has existed since the beginning of June, i.e. Buster and testing since Buster. It does not happen with Debian Stretch.
>>
>> I first saw this with Firefox Quantum and assumed it was a Firefox specific problem however none of the purported solutions solved this problem. I then realized that it
>> also happens with Chrome. Worse yet, even the Thunderbird email client is affected. The messages for each:
>>
>> Firefox: performing TLS handshake
>> Chrome: establishing secure connection
>> Thunderbird: cannot establish secure connection
>>
>> Basically the browsers get stuck on the TLS handshake. This seemingly gets worse as time goes on. After boot up these messages fly by so quickly they're barely perceptible.
>> Eventually the handshakes take seconds. At some point the bowsers become unusable as the handshake seems to time out.
>>
>> I repeated the testing with the very latest versions of both Firefox and Chrome on both sparkylinux ("testing") and Debian Stretch. This problem does not happen on Stretch.
>> The evidence suggests it's distribution version specific. The above ssl library components changed from Stretch to Buster. Since the browsers utilize these components for
>> TLS handshakes it stands to reason this is either a regression or new bug in these ssl components.
> Neither Firefox nor Chrome makes use of openssl. Firefox makes use
> of NSS (libnss3). Chrome makes use of boringssl, but neither
> Chrome nor boringssl is part of Debian. Chromium has an embeded
> copy of boringssl.

I don't understand how all these apps can experience the same problem 
without using a shared component for the TLS handshakes. That would just 
be too coincidental, no?
boringssl is a fork of Openssl. So is it possible that some of the 
problems that existed in Openssl were carried forward to boringssl 
without correction?

>
> What they all do have in common is that they now support TLS 1.3,
> but I currently don't see how that should have any effect. Is the
> whole PC slower, or the browsers, or just the connection? And a
> reboot solves the problem?

As I reported just the TLS handshake. Other parts of the connection 
sequence take on the order of milliseconds as usual. PC and other apps 
are fine. Yes, reboot solves the problem although only temporarily. Also 
as mentioned this doesn't happen with Stretch. Maybe the regression or 
new bug were introduced with newer versions of libboringssl and libnss3 ?

>
> Did you try to look at network traffic with something like
> wireshark?

And what am I looking for? You're suggesting that I'm the first person 
to report this problem? I've already spent far too much time on this 
issue and now you're asking me an end user to spend even more time on 
this issue? I don't mind helping, but it needs to be within reason. In 
this case having specific things to look for would be most helpful.

>
>
> Kurt
>