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

[Kurt Roeckx]

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
really know what to look for.


Kurt