[Pkg-openssl-devel] Bug#935133: Bug#935133: Bug#935133: slow TLS handshake renders browsers and email client unusable
nbi
nbi.vegas at gmail.com
Thu Aug 29 20:28:16 BST 2019
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
More information about the Pkg-openssl-devel
mailing list