Opened 9 years ago

Last modified 4 years ago

#11568 new defect

SSL handshake failure on reconnect of IRC over SSL

Reported by: Neo@… Owned by: elb
Milestone: Component: IRC
Version: 2.6.6 Keywords:
Cc: MattTheRat, NEOatNHNG, ciupicri, oitofelix, nh2

Description

I use the IRC server of CAcert a lot (ircs://irc.cacert.org:7000), which has SSL encryption enabled.

There are no problems on the initial connect, but when the connection is interrupted (e.g. lost wifi) and pidgin reconnects it always throws an "SSL Handshake Failed" and subsequent clicks on "Reconnect" will just throw the same error.

How to reproduce:

  1. Create a new account (protocol=IRC, username=TEST, server=irc.cacert.org, port=7000, Use_SSL=True)
  1. Once connected to the server, disable the account
  1. Enable the account again.

To recover from this problem one can just restart pidgin but that's very annoying especially if working over a weak wifi connection.

Tried this on Ubuntu Linux 9.10 with pidgin 2.6.6 and libpurple 2.6.6 with a clean user and all plugins disabled.

This issue might be related to #8828

Attachments (6)

pidgin.log (19.8 KB) - added by Neo@… 9 years ago.
Debug output
purple-debug.log (5.3 KB) - added by dwlocks 9 years ago.
obufuscated servernames, usernames and ips.
irc_cap.pcap (13.7 KB) - added by MattTheRat 9 years ago.
wireshark capture of IRC traffic
debug.log (24.9 KB) - added by NEOatNHNG 8 years ago.
debug log from corresponding pcap (interesting part starts at line 249 (02:33:16))
debug.pcap (11.1 KB) - added by NEOatNHNG 8 years ago.
ssl_cache.patch (766 bytes) - added by NEOatNHNG 8 years ago.
Patch to disable SSL cache

Download all attachments as: .zip

Change History (41)

Changed 9 years ago by Neo@…

Debug output

Changed 9 years ago by dwlocks

obufuscated servernames, usernames and ips.

comment:1 Changed 9 years ago by dwlocks

I can confirm this issue with Pidgin 2.6.6-2.fc12 (libpurple 2.6.6), as well as with Pidgin 2.5.X on my previous Fedora 10 system.

A colleague uses Pidgin 2.6.6 on Ubuntu and 2.7 on Windows Vista, and also has the issue.

One more thing: our IRC server uses our LDAP tree for authentication. IT tried shortening the LDAP reauth timeout to no avail.

comment:2 Changed 9 years ago by darkrain42

  • Status changed from new to pending

The error NSS is returning is PR_END_OF_FILE_ERROR.

Could one of you get a pcap (tcpdump) capture of this? I'm looking to confirm that the server is, indeed, closing the connection (and how far through the SSL negotiation it gets)

comment:3 Changed 9 years ago by trac-robot

  • Status changed from pending to closed

This ticket was closed automatically by the system. It was previously set to a Pending status and hasn't been updated within 14 days.

comment:4 Changed 9 years ago by MattTheRat

I have attached a wireshark capture of IRC traffic to our internal IRC server (10.33.1.235)

This issue is starting to affect most of our users as they all use Pidgin and the wireless network is being used more often for connections.

Changed 9 years ago by MattTheRat

wireshark capture of IRC traffic

comment:5 Changed 9 years ago by darkrain42

  • Status changed from closed to new

comment:6 Changed 9 years ago by MattTheRat

If it helps, there appears to be a time factor here. I put my laptop to sleep last night at 1830 and brought it back this morning at 915 with no wakeups in between. I reconnected to the IRC server without having to close Pidgin.

Is it possible there is a cache that is only cleared after a number of hours?

comment:7 Changed 9 years ago by fuddl

I'm using Pidgin as packaged in Debian "sid"/unstable and reported the very same bug and a workaround to the Debian bug tracking system.

You'll find the workaround here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590883#12

I had a look at the code around (NSS) SSL-thingies for IRC and noticed that there are some "FIXME" comments and a few lines contain "tls-cached". So things look like it could really be a caching problem.

comment:8 follow-up: Changed 8 years ago by dandv

I get "SSL Handshake Failed" when trying to connect to freenode with "Use SSL" checked. (freenode doesn't allow my IP to connect without SSL).

Pidgin 2.7.4. The log doesn't say much.

(22:52:26) prefs: /purple/savedstatus/default changed, scheduling save.
(22:52:26) account: Connecting to account xxx@irc.freenode.net.
(22:52:26) connection: Connecting. gc = 0328BC28
(22:52:26) dnsquery: Performing DNS lookup for irc.freenode.net
(22:52:26) dnsquery: IP resolved for irc.freenode.net
(22:52:26) proxy: Attempting connection to 213.161.196.11
(22:52:26) proxy: Connecting to irc.freenode.net:6667 with no proxy
(22:52:26) proxy: Connection in progress
(22:52:26) proxy: Connecting to irc.freenode.net:6667.
(22:52:26) proxy: Connected to irc.freenode.net:6667.
(22:52:32) util: Writing file prefs.xml to directory Z:\Programs\Net\Pidgin-portable\.purple
(22:52:32) util: Writing file Z:\Programs\Net\Pidgin-portable\.purple\prefs.xml
(22:52:32) util: Writing file accounts.xml to directory Z:\Programs\Net\Pidgin-portable\.purple
(22:52:32) util: Writing file Z:\Programs\Net\Pidgin-portable\.purple\accounts.xml
(22:53:09) nss: Handshake failed  (-5938)
(22:53:09) connection: Connection error on 0328BC28 (reason: 5 description: SSL Handshake Failed)
(22:53:09) account: Disconnecting account usepidgin@irc.freenode.net (01D95C80)
(22:53:09) connection: Disconnecting connection 0328BC28
(22:53:09) connection: Destroying connection 0328BC28
(22:53:15) util: Writing file accounts.xml to directory Z:\Programs\Net\Pidgin-portable\.purple
(22:53:15) util: Writing file Z:\Programs\Net\Pidgin-portable\.purple\accounts.xml

comment:9 in reply to: ↑ 8 Changed 8 years ago by rekkanoryo

Replying to dandv:

I get "SSL Handshake Failed" when trying to connect to freenode with "Use SSL" checked. (freenode doesn't allow my IP to connect without SSL).

Pidgin 2.7.4. The log doesn't say much.

Freenode does not do IRC over SSL on port 6667. Try port 7000 (or look at their documentation).

comment:10 Changed 8 years ago by dandv

Setting the port to 7000 worked.

comment:11 Changed 8 years ago by elb

  • Cc NEOatNHNG added

comment:12 Changed 8 years ago by NEOatNHNG

It seems that the problem is hit when using the SSL/TLS session ID mechanism to do an abbreviated handshake and reuse the keys from the last session.

I have attached a pcap and a matching debug log. I think the server is the one acting strange here. I have contacted the admins of the server to get this sorted out. The problem might be that this is not the only server behaving that way. So it might be actually desirable to not reuse the keys from last session and always use new sessions for compatibility. If so I have also attached a patch to disable the SSL cache.

On the other hand the other pcap from MattTheRat? doesn't seem to use an SSL handshake at all and therefore can't be related so maybe it's only this server after all.

Changed 8 years ago by NEOatNHNG

debug log from corresponding pcap (interesting part starts at line 249 (02:33:16))

Changed 8 years ago by NEOatNHNG

Changed 8 years ago by NEOatNHNG

Patch to disable SSL cache

comment:13 Changed 8 years ago by NEOatNHNG

I have verified that this behaviour is indeed due to a bug in the server software called ircd-hybrid (and also its fork oftc-hybrid) which didn't call SSL_CTX_set_session_id_context() which in order made the handshake fail.

I have submitted a patch in their bug tracker but I guess it needs some time to get fixed everywhere.

comment:14 Changed 8 years ago by deryni

So this ticket can be closed as there isn't a libpurple bug here?

comment:15 Changed 8 years ago by darkrain42

We might want to consider disabling the session cache, as NEOatNHNG suggested. I'm personally neutral on this (an IM client doesn't gain much use from it, in my opinion, when compared to an HTTPs client, but it's still nice (in theory)).

comment:16 Changed 8 years ago by deryni

I'd be ok with having a way to do that but I wouldn't bother doing it by default. It is nice when it works and shouldn't generally hurt anything (except when servers are broken which I'm always a fan of identifying and reporting).

comment:17 Changed 8 years ago by johket

So could an option be added for this?

I'm having this problem as well and it's really annoying, would be helpful to have an option to disable the cache.

comment:18 Changed 8 years ago by BW~Merlin

Just ran into this problem today, can no longer connect to freenode via SSL (tried all the different SSL ports and different freenode servers as well).

comment:19 Changed 7 years ago by TheBayer

Still present on V2.10, still quite annoying.

comment:20 Changed 7 years ago by kip

I'm having the same issue. Using Pidgin 2.10.6 (libpurple 2.10.6) under Ubuntu Precise (amd64).

comment:21 Changed 6 years ago by ciupicri

I'm having the same issue under Fedora 19 x86_64 with libpurple-2.10.7-3, pidgin-2.10.7-3, nss-3.15.1-2:

(15:10:01) proxy: Connected to adams.freenode.net:6697.
(15:10:01) nss: Handshake failed  (-5938)
(15:10:01) connection: Connection error on 0x4cc6880 (reason: 5 description: SSL Handshake Failed)

comment:22 Changed 6 years ago by lloydsmart


Hash: SHA256

Can confirm - having same issue on Trisquel 6.0 (binary equivalent to Ubuntu 12.04) using Pidgin 2.10.7 from the PPA.


Version: GnuPG v1.4.11 (GNU/Linux)

iF4EAREIAAYFAlIUx8oACgkQgijxUCZnvluetwD8CuRrnpy8AzyGGc1oBzfP7keh WIT8Ub8pS9eP87XPYWEBAKadNh2hYohdbXkmOev8d5wviat51hxFp5/0J3mnnxc6 =ARFh


comment:23 Changed 5 years ago by oitofelix

As of 2013-12-06 the same issue is occurring in Parabola GNU+Linux-Libre, so probably it is so in Arch GNU+Linux. The relevant packages are: pidgin (2.10.7-4), libpurple (2.10.7-4) and nss (3.15.3-1).

Isn't it possible to provide an option to disable the SSL cache?

comment:24 Changed 5 years ago by nh2

This is really annoying.

Apart from applying this 3 years old patch, can I delete a certain file to wipe the cache?

comment:25 Changed 5 years ago by nh2

Any update on this?

It makes pidgin unusable: After resuming from suspend, I simply can't use it for IRC any more.

Please tell me where this cache is stored.

comment:26 Changed 5 years ago by datallah

It'd not stored anywhere apart from in memory.

comment:27 follow-up: Changed 5 years ago by nh2

@datallah: How does it manage to persist through a pidgin restart then?

comment:28 in reply to: ↑ 27 Changed 5 years ago by datallah

Replying to nh2:

@datallah: How does it manage to persist through a pidgin restart then?

Perhaps this isn't the issue that is causing whatever symptom you're running into. Did you confirm that the patch prevents the issue from happening?

comment:29 in reply to: ↑ description ; follow-up: Changed 5 years ago by fermuch

Any update? This bug is 4 years old, and still, it's being ignored. Is there anything I can do to help help solve this bug?

I can reproduce the bug with 2.10.9-r1.

comment:30 Changed 5 years ago by kip

*sigh* If it's an consolation fermuch, I run into this issue pretty much every day still =(

comment:31 in reply to: ↑ 29 Changed 5 years ago by elb

Replying to fermuch:

Any update? This bug is 4 years old, and still, it's being ignored. Is there anything I can do to help help solve this bug?

I can reproduce the bug with 2.10.9-r1.

Have you contacted the server admins in the past four years? This is a bug in the server software, Pidgin is behaving correctly. If what you mean is, the IRCd has had a bug for four years and we haven't worked around it yet, then yes, unfortunately that is true.

If you are currently using NSS, you might try GnuTLS. I am not sure if it has the same problem or not.

comment:32 Changed 4 years ago by elb

Ticket #16560 has been marked as a duplicate of this ticket.

comment:33 Changed 4 years ago by rata0071

This happens with ngircd servers too. Still anoying :( I've reported the issue there and point them here, but it may help pidgin fame(?) to disable ssl cache for the time being...

(01:19:06) account: Connecting to account xxxxxx.
(01:19:06) connection: Connecting. gc = 0x1862980
(01:19:06) dnsquery: Performing DNS lookup for xxxxxx
(01:19:06) dns: Wait for DNS child 13267 failed: No hay ningún proceso hijo
(01:19:06) dns: Created new DNS child 13315, there are now 1 children.
(01:19:06) dns: Successfully sent DNS request to child 13315
(01:19:06) dns: Got response for 'xxxxxx'
(01:19:06) dnsquery: IP resolved for xxxxxxx
(01:19:06) proxy: Attempting connection to xxxxxxx
(01:19:06) proxy: Connecting to xxxxxxx:6697 with no proxy
(01:19:06) proxy: Connection in progress
(01:19:06) proxy: Connecting to xxxxxxx:6697.
(01:19:06) proxy: Connected to xxxxxx:6697.
(01:19:06) nss: Handshake failed  (-5938)
(01:19:06) connection: Connection error on 0x1862980 (reason: 5 description: Se produjo un fallo en la negociación SSL)
(01:19:06) account: Disconnecting account xxxxxxxx (0xf48100)
(01:19:06) connection: Disconnecting connection 0x1862980
(01:19:06) connection: Destroying connection 0x1862980
Last edited 4 years ago by rata0071 (previous) (diff)

comment:34 Changed 4 years ago by rata0071

Not to be bossy about it, but shouldn't it at least request a new key if the old one failed?

comment:35 Changed 4 years ago by tyrmored

For those who are in a position to patch or upgrade their IRCS daemons to make this work, I figured out a patch that fixes things for Pidgin (and stunnel) to ngircd-openssl here if that helps anybody: https://github.com/ngircd/ngircd/pull/215

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!