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.
