"Failed to read fixed header" due to TLS 1.3 (march 2018 + january 2019)

[dequis]

This was brought up by @rosshadden / @jaymzh / @ipantovic in #361 (comment) and @mandree in #403 (comment) - I'm opening a new ticket for visibility/clarity.

tl;dr

Update to libpurple 2.13.0, or, if that's not possible, use the NSS preferences plugin (tools menu -> plugins) to set the max version to TLS 1.2.

Do not play with the other checkboxes in the NSS preferences plugin.

Causes

The above is my current recommendation - play it safe and avoid this bug, TLS 1.3 is too young for now - but this bug is about the case where TLS 1.3 itself is enabled, it works, but you get disconnected with "Failed to read fixed header" after sending MQTT CONNECT (the first hexdump in the debug logs, which says MQTToT).

I imagine three possible causes for this:

• Using libpurple 2.12.0 or older and using NSS preferences to tick all the checkboxes of ciphers required for TLS 1.3 instead of just disabling it
• Using libpurple 2.13.0 or newer and using NSS preferences to enable TLS 1.3
• Future versions of NSS may change the defaults to enable TLS 1.3. That's why this bug is worth fixing.

If anyone with had this error and doesn't fit in these please leave a comment here.

Also, all of these cases require linux, because the version of NSS shipped with pidgin doesn't have TLS 1.3 support.

Previous issues

Pidgin/libpurple 2.12.0 and earlier had a bug in which (for historical reasons) they force-enable the latest TLS version and disable ciphers they don't know about, making it impossible to connect to servers that enable TLS 1.3. That issue fixed in libpurple 2.13.0. The result of that:

• Stickers and images are not received any more #404 (2018-01-30) is the facebook CDN deploying TLS 1.3 - results in images not being visible
• Facebook again with the SSL Handshake Failed #408 (2018-03-16) is deploying TLS 1.3 in the mqtt server - results in SSL handshake error

This issue was initially reported arond the same date.

The actual bug

This is when you avoid the SSL Handshake Error and trip right after. As @mandree points out in #403 (comment) it's just an EAGAIN.

The old code made the assumption that the first call to the read callback would also include at least two bytes to read, and this seems to be true with TLS 1.2. I guess something changed about TLS 1.3 that gets you calls with nothing to read.

ef6ae47 fixes that

So, if you really want, you can enable TLS 1.3 if you use libpurple 2.13.0 and upgrade to this commit. At least until we find the next issue.

[jaymzh]

You are my hero.

[dequis]

Credit to @mandree really, I didn't even think this code could be failing to handle EAGAIN

[EionRobb]

I wonder if that EAGAIN thing is why I could get the FB plugin to work with the win32-ssl plugin. I might try that again too.

[rosshadden]

@dequis Setting max TLS to 1.2 did bypass the issue for me, however it's worth noting I actually have libpurple 2.13.0-1 installed, which is the latest. Oh well.

[jaymzh]

I can confirm that with this patch and libpurple 2.13, the problem is fixed.

I can also confirm that setting max to TLS 1.2 works around it.

Thanks so much @mandree and @dequis !

[rosshadden]

Oh my bad, I didn't update this plugin. I'll try it tomorrow.

[mandree]

@dequis - Fedora 27 Workstation (amd64), ef6ae47 and NSS limited to TLS 1.2 (without I get sporadic errors and need to reconnect), fixes things for me (with libpurple 2.12.0/pidgin 2.12.0-3.fc27). Thank you!

[rosshadden]

After updating the plugin, it works with TLS 1.3, and as I had already confirmed the workaround of using TLS 1.2 had worked before doing so. Thanks!

[Zombie-Ryushu]

I still get this error even after updating the plugin with Spectrum2.

[shlomif]

@Zombie-Ryushu : everyone: note that I got this bug again and was able to fix it by deleting ssl-gnutls.so.

[GreatEmerald]

I'm getting this bug now as well. I'm on 2.13.0, and disabling TLS 1.3 doesn't help. And I don't think that deleting a system library is a good idea.

[Agalin]

For me downgrade to GnuTLS 3.5.x fixes the issue.

[petermolnar]

For me downgrade to GnuTLS 3.5.x fixes the issue.

May I ask how did you manage that? If I try to downgrade libgnutls30 on debian (unstable) it wants to wreak havoc and remove nearly all packages on my system.

[dequis]

Yeah so now gnutls enabled TLS 1.3 but the issue is essentially the same. I applied the same fix over at bitlbee-facebook, which primarily uses gnutls, so if you just build the master branch it should work for you.

[petermolnar]

OK, got it working: I recompilied pidgin without gnutls, used the wip-workplace-chat branch.
If anyone needs it:

apt-get build-dep pidgin
git clone https://github.com/CkNoSFeRaTU/pidgin
cd pidgin
./configure --prefix=/usr --disable-nm --enable-gnutls=no
make
sudo make install
# just in case
sudo rm /usr/lib/purple-2/ssl-gnutls.*

[GreatEmerald]

The weird thing is, I have one openSUSE Tumbleweed system where this works just fine, using GnuTLS 3.6.3; and then I have another Tumbleweed system where I get this error. I don't really get how that is even possible...

[dequis]

It's not particularly consistent, it's a bit of a race condition, depends on network latency and all. To reproduce it with gnutls I had to reconnect several times, got it approximately 2 times out of 10 tries.

Again, building the master branch is the most certain way to fix it.

[dequis]

0.9.6 is out with the patch that fixes our side of issues, mostly relevant again for gnutls people, but for nss people libpurple 2.13.0 or tinkering with nss preferences is still required. I wrote a bit more here https://github.com/dequis/purple-facebook/releases/tag/v0.9.6

[josx]

A few days ago my pidgin started to give this error (on faceboook). I have latest purple-facebook source code compiled and libpurple 2.13.x
Any clue to solve it?

[dequis]

Then it's something else. Please open another issue.

Note that the error is roughly equivalent to "connection reset by peer", and anything can cause the connection to be abruptly closed, TLS is just one of many possible reasons for it.