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

[nbi]

While I may be the first to report this to Debian bugs casual googling 
turns up other reports of this to the Internet at large.

The good news is that the MTU workaround seems to be working as there 
has not been any TLS handshake issues since the workaround was applied. 
While I'm completely baffled as to why this should be the case (MTU size 
should be totally transparent at the TLS level) I'll take the victory. I 
guess this ticket can be closed and revisited if need be.

On Wed, 21 Aug 2019 19:08:12 +0200 Kurt Roeckx <kurt at roeckx.be> wrote:
 > On Wed, Aug 21, 2019 at 09:47:09AM -0700, nbi wrote:
 > > 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.
 >
 > I did suspect something between your PC and the internet, but a
 > reboot fixing it didn't then make sense. I guess it's on the PC
 > itself, and something specific to your setup.
 >
 > That it slows down does not make sense to me, so I suspect there
 > is an other bug than the MTU problem. My expierence with MTU
 > problems is that some sites don't work at all, or only sometimes,
 > rather than slow down.
 >
 > > > > 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?
 >
 > The TLS implementations have very little in common. boringssl
 > isn't really a fork of OpenSSL, it just picked random parts of the
 > OpenSSL code, and has rewritten other parts. Even if the TLS
 > implementations was very simular, both boringssl and openssl
 > have rewritten it since the "fork". As far as I know, NSS doesn't
 > share any code with the others.
 >
 > > > > 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.
 >
 > So yes, you're the first person to report anything like that.
 >
 > With the switch to buster, lots of things changed including the
 > kernel. I guess most of your traffic is TLS based, so I'm not even
 > sure it's only TLS connections that are affected. The problem can
 > be in any of the components.
 >
 > If you have the problem again, I suggest to use a tool like
 > wireshark or tcpdump to monitor the network traffic. You can at
 > least look at which side seems to be slow to respond. I don't