0.12.2-0ubuntu1.16.04.2 fails to connect to servers after upgrade

[Dave Jones]

I have quassel-core running in an old xenial container with postgres as a backend. Last night it upgraded from 0.12.2-0ubuntu1 to 0.12.2-0ubuntu1.16.04.2 and when the core restarted it seemed unable to connect to any IRC servers. There doesn't seem to be much of use in the core's log files, but I'll include the snippet before and after the upgrade in case there's anything useful:

2020-03-23 22:33:18 Info: Client 192.168.80.198 disconnected (UserId: 1).
2020-03-24 01:07:51 Warning: Caught signal 15 - exiting.
2020-03-24 01:07:57 Info: PostgreSQL Storage Backend is ready. Quassel Schema Version: 17
2020-03-24 01:07:57 Info: Listening for GUI clients on IPv6 :: port 4242 using protocol version 10
2020-03-24 01:07:57 Info: Listening for GUI clients on IPv4 0.0.0.0 port 4242 using protocol version 10
2020-03-24 01:07:57 Info: Restoring previous core state...
2020-03-24 01:07:59 Warning: Could not connect to Canonical (The remote host closed the connection)
2020-03-24 01:07:59 Warning: Could not connect to Freenode (The remote host closed the connection)
2020-03-24 01:08:00 Warning: Could not connect to OFTC (The remote host closed the connection)

(the last three messages then repeat until it gives up attempting to reconnect)

When I started a client in the morning it oddly warned that the core was "unable to support SSL" which leaves me wondering if the upgrade broke something in how the core uses SSL? I've tried setting the log level to Debug but there doesn't seem to be any additional info in the output.

For the avoidance of doubt, downgrading the core back to 0.12.2-0ubuntu1 restored all the connections successfully.

[Oliver Gerlich (ogerlich)]

I'm also having weird SSL problems with quassel 0.12.2-0ubuntu1.16.04.2, but in my case it's the connection between quasselclient and quasselcore that doesn't work. When starting quasselclient it now shows a warning dialog: "Your client does not support SSL encryption. Sensitive data, like passwords, will be transmitted unencrypted to your Quassel core." where I can select Cancel and Ignore. None of these options will actually lead to a connection to the core, though!

In my case quasselcore is version 1:0.13.1-1+deb10u2~bpo9+1 running under Debian 9.12.

With quasselclient 0.12.2-0ubuntu1 the problem does not occur. And that client does show the core connection as encrypted.

I've traced the TCP connection with Wireshark, and it looks like the broken client only ever sends a single packet with 12 payload bytes, but never receives a reply from server.

[Oliver Gerlich (ogerlich)]

So for the quasselclient issue I've now compared the wireshark traces of 0.12.2-0ubuntu1 and 0.12.2-0ubuntu1.16.04.2. At startup both send a payload of 12 bytes.

0.12.2-0ubuntu1:
    42 b3 3f 03 00 00 00 02 80 00 00 01
0.12.2-0ubuntu1.16.04.2
    42 b3 3f 02 00 00 00 02 80 00 00 01

They only differ in the 4th byte (working client sends 0x03, broken client sends 0x02).
According to https://quasseldroid.info/docs/protocol/layers/framing/ that byte contains the handshake feature flags. 0x02 means "Compression"; 0x03 means "TLS" and "Compression".

So it looks like quasselclient 0.12.2-0ubuntu1.16.04.2 does not use TLS for the core connection any more.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Guigui (guigui)]

I confirm here the exact same problem for both connecting client to quasselcore, and connecting quasselcore to IRC servers with SSL support.
Downgrade to 0.12.2-0ubuntu1 and works fine.