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
