Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

SSL handshake fails with pidgin's ssl cache #182

Closed
alexbarton opened this issue Apr 7, 2015 · 10 comments
Closed

SSL handshake fails with pidgin's ssl cache #182

alexbarton opened this issue Apr 7, 2015 · 10 comments
Assignees
@alexbarton
Labels
bug Issue affects current expected functionality

Comments

@alexbarton
Copy link
Member

(Report imported from Bugzilla #182)

Status RESOLVED, severity normal, in component Daemon.
Reported in version unspecified on platform All.
Assigned to: Alexander Barton.

On 2015-02-12 05:42:45 +0100, aza wrote:

If you'd ever used Pidgin with IRC you must know this bug.

On ssl renegotiation pidgin reuses the keys from the previous session and this fails with ircd and aparently with ngircd too.

Here's the relevant comment from their issue:

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.

https://developer.pidgin.im/ticket/11568

On 2015-02-20 10:02:50 +0100, Alexander Barton wrote:

I'll try to look into this, thanks for reporting the problem!

On 2015-03-14 13:25:48 +0100, Alexander Barton wrote:

I can't reproduce this with Pidgin 2.10.11 (libpurple 2.10.11) and the steps mentioned to reproduce it in the Pidgin bug report (https://developer.pidgin.im/ticket/11568):

How to reproduce:

  1. Create a new account
  2. Once connected to the server, disable the account
  3. Enable the account again.

Pidgin just reconnects to the ngIRCd, regardless of ngIRCd being linked to GnuTLS or OpenSSL?
I'm testing this on OS X 10.10 which has OpenSSL 0.9.8zc.

Which versions of Pidgi and libpurple are you using?

Thanks!
Alex
@alexbarton alexbarton added the bug Issue affects current expected functionality label Apr 7, 2015
@alexbarton alexbarton added the invalid This issue seems to be „not valid“ … label Apr 7, 2015
@fauno
Copy link

fauno commented Apr 13, 2015

why was this marked as invalid?

@alexbarton
Copy link
Member Author

Because I can't reproduce it here, see above.

Which versions are you using? I tested it with Pidgin 2.10.11 (libpurple 2.10.11) on OS X 10.10 which uses OpenSSL 0.9.8zc.

@lobit0
Copy link

lobit0 commented Apr 13, 2015

I think I'm having this issue, too.

Pidgin 2.10.11 (libpurple 2.10.11)
OpenSSL 1.0.1f 6 Jan 2014
Edubuntu Trusty LTS

@fauno
Copy link

fauno commented Apr 13, 2015

@lobit0 is connecting to our 22.1 server and just got the handshake failure. maybe it's the cipherlist? we're using ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:HIGH:!aNULL:@STRENGTH:!SSLv3

@sudoaza
Copy link

sudoaza commented Apr 13, 2015

still happening on arch libpurple and pidgin both 2.10.11-1 openssl 1.0.2.a-1

  • Join an IRC server
  • Once you're connected disable the account.
  • re-enable it. In the spanish verion shows "Se produjo un fallo en la negociación SSL"

@alexbarton alexbarton removed the invalid This issue seems to be „not valid“ … label Apr 13, 2015
@alexbarton alexbarton reopened this Apr 13, 2015
@alexbarton
Copy link
Member Author

Ok, thanks a lot for the additional information. I'll try again to reproduce it here.

@alexbarton alexbarton self-assigned this Apr 13, 2015
@fauno
Copy link

fauno commented Apr 13, 2015

thanks! we just tested with the default ciphers, it's the same error. here's the server-side log

[30049:6   39] Accepted connection 8 from "10.4.23.225:44739" on socket 7.
[30049:6   39] Connection 8: initialized TLSv1.2 using cipher DHE-RSA-AES128-GCM-SHA256.
[30049:5   39] User "fauno!fauno@ponape.local" registered (connection 8).
[30049:6   52] Shutting down connection 8 (Got QUIT command) with "10.4.23.225:44739" ...
[30049:5   52] User "fauno!fauno@ponape.local" unregistered (connection 8): Got QUIT command.
[30049:6   52] Connection 8 with "10.4.23.225:44739" closed (in: 0.1k, out: 1.6k).
[30049:6   53] Accepted connection 8 from "10.4.23.225:44741" on socket 7.
[30049:3   53] SSL protocol error: SSL_accept (error:140D9115:SSL routines:ssl_get_prev_session:session id context uninitialized)
[30049:6   53] Shutting down connection 8 (SSL accept error, closing socket) with "10.4.23.225:44741" ...
[30049:5   53] Client unregistered (connection 8): SSL accept error, closing socket.
[30049:6   53] Connection 8 with "10.4.23.225:44741" closed (in: 0.0k, out: 0.0k).

@fauno
Copy link

fauno commented Apr 13, 2015

i just compiled ngircd with gnutls instead of openssl and the issue went away :)

openssl version on the server was 1.0.2

@ghost
Copy link

ghost commented Jun 26, 2015

Here is how I fixed the problem: https://github.com/tejr/ngircd/commit/b71a0ddbd570f5163ede198d635c3b03abd3e27e

I can make a pull request or however you prefer to work if that helps.

@alexbarton
Copy link
Member Author

@tejr a pull request would be best, I think. Thanks a lot!

@ghost ghost mentioned this issue Jun 26, 2015
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@alexbarton alexbarton

Labels
bug Issue affects current expected functionality
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@alexbarton @fauno @sudoaza @lobit0