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

[nbi]

Some progress. I found a reference to a MTU size issue possibly 
impacting this. I'm using channel bonding provided by the ifenslave 
package. It turns out ifenslave has a bug that causes it to not set the 
MTU size correctly on the active slave. I applied the workaround and 
verified the MTU is correct. I have not seen the handshake problem 
since, but it is much too early to tell. I'm perplexed as to how MTU 
fragmentation/reassembly could possibly impact this issue, but if that 
turns out to be the fix I'm more than happy to go with it.

If the problem resurfaces I will use the utility dumpssl to debug the 
handshakes.


On Mon, 19 Aug 2019 15:48:04 -0700 nbi <nbi.vegas at gmail.com> wrote:
 > 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.
 >