Dear Maintainer,
As of ~Oct. 29th, 2020 pidgin is no longer connection, I get
'xxxxx@gmail.com/Home disconnected SSL Handshake failed" I am using Debian
testing (buster) but I tried pidgin using X forwarding on my Debian stable
server and seemed to get the same result.
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
Pidgin just stopped connecting to the jabber client on my two desktop machines.
* What exactly did you do (or not do) that was effective (or
ineffective)?
I tried purging and reinstalling, messing with the Account settings and
removing the "Home" Resource, enabling "Allow paintext auth over unencrypted
streams", changing the proxy settings (I don't use a proxy), removing my
.purple directory and setting up fresh, & looking at the pidgin documentation
for jabber set up. I also verified that "Less Secure Apps" was enabled in my
gmail account.
* What was the outcome of this action?
Nothing worked. Changing a setting removed the 'Handshake failed' message, but
did not connect. When I disabled and re-enabled the account again I get the
'disconnected' message back.
* What outcome did you expect instead?
*** End of the template - remove these template lines ***
New info, pidgin IS working on Debian stable. But I downloaded and set up Empathy and it isn't working in Debian testing. This seems to be a Buster issue, not specifically a pidgin problem.
Hi, I have experienced a similar issue when testing Psi/Psi-plus : There was an error communicating with the server. Details: Authentication error: No appropriate mechanism available for given security settings (e.g. SASL library too weak, or plaintext authentication not enabled) Offered mechanisms: PLAIN Offered mechanisms: PLAIN
I meant bullseye at #10, never try to post a bug without coffee. Anyway, the issue seems to have resolved itself on Debian testing for me, this morning I was greeted by a request for an updated gmail certificate (I have pidgin set to auto-start), and everything looks ducky after several weeks. I guess that is why they call it testing... BTW, is there any way to automatically accept the certificates? I never double check them and really don't use pidgin to do anything but chat with the spouse and a couple of cronies and sometimes get several new gmail certificates requests a day (and sometimes seem to go a long time between new ones). I know I shouldn't add anything to a bug report, but I guess I'm just an evil git that way.
For me, the same error "SSL Handshake Failed" started happening with pidgin 2.13.0-2+b1 on Debian Buster about a week ago. Interestingly, one TLS XMPP account work just fine, but other TLS XMPP account (on jabber.fsfe.org) started failing. So it is not that whole of XMPP if broken in Pidgin. Interestingly enough, I can still use other TLS XMPP Clients (like Android client "Conversations v2.9.6+FCR" from f-droid.org) to connect to that jabber.fsfe.org server just fine, so it is not and issue that FSFE XMPP server is broken for all clients, either. "pidgin -d" when pressing reconnect it fails and prints: (17:16:46) jabber: Sending (redacted@jabber.fsfe.org/redacted): <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> (17:16:46) jabber: Recv (50): <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> (17:16:46) nss: Handshake failed (-12286) (17:16:46) connection: Connection error on 0x557f6ad65f00 (reason: 5 description: SSL Handshake Failed) Seraching the web for "nss: Handshake failed (-12286)" finds https://github.com/fchat-pidgin/fchat-pidgin/issues/156#issuecomment-305260240 whish says it means "SSL_ERROR_NO_CYPHER_OVERLAP" which is somewhat more informative. I've also managed to use "wireshark" to see Pidgin tries to use TLS 1.2 (why not 1.3? It seems supported in Buster otherwise?), and that seems to fail when trying to connect to jabber.fsfe.org XMPP server (I've contacted FSFE). Manually verifying in shell seems to confirm this case to be combination of jabber.fsfe.org configuration issue of only supporting TLS 1.3, and Buster Pidgin issue of not supporting TLS 1.3: % openssl s_client -connect jabber.fsfe.org:5222 -starttls xmpp -servername jabber.fsfe.org -tls1_3 works, but % openssl s_client -connect jabber.fsfe.org:5222 -starttls xmpp -servername jabber.fsfe.org -tls1_2 fails with: CONNECTED(00000003) 140641803256960:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:../ssl/record/rec_layer_s3.c:1544:SSL alert number 40 So, probably not a bug in Pidgin (although I do hope Pidgin will support TLS1.3 in Bullseye? right?) I'm writing this anyway so other poor soul that gets such error can try to narrow down what is the problem.
There is also an workaround on Debian Buster: in Pidgin, one can select "Tools" / "Plugins" and install "NSS Preferences 2.13.0" plugin, and then click "Configure": here one can select what TLS versions and ciphers will be used, *including* TLS1.3 So I've installed it, enabled "min TLS1.2" and "max TLS1.3" and now it connects to TLS1.3-only server jabber.fsfe.org just fine. Why using best supported TLS protocol isn't default behaviour in Pidgin is something that should probably be addressed.