Adium

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#12913 closed defect (fixed)

Adium 1.4b9 SSL Handshake fails for Jabber under OS X 10.6

Reported by: jystickman Owned by:
Milestone: Adium 1.4 Component: Adium Core
Version: 1.4b9 Severity: regression
Keywords: SSL Jabber 10.6 Snow Leopard Cc: darkrain42
Patch Status:

Description

After upgrading to OS X 10.6, AdiumX can no longer log in to a Jabber server using SSL. Repeated failures with message "Error: SSL Handshake Failed". Exact same setup works fine under 10.5.8. This is confirmed by 3 people.

Account setup options set Port 5222, Require SSL/TLS, and Do Strict Certificate Checks.

Attachments (3)

foo.txt (4.4 KB) - added by jystickman 5 years ago.
Debug log of failed SSL connection
serverlog.txt (3.0 KB) - added by jystickman 5 years ago.
Server Error Logs
xmpp-ssl-cipher.diff (2.4 KB) - added by proton 5 years ago.
Patch to fix issue

Download all attachments as: .zip

Change History (44)

Changed 5 years ago by jystickman

Debug log of failed SSL connection

comment:1 Changed 5 years ago by zacw

The relevant error is:

errSSLPeerInternalError		= -9838,	/* internal error */

comment:2 Changed 5 years ago by jystickman

Thanks. I did guess that, but included the entire section of the log for completeness. :-) BTW, in case it wasn't obvious, I edited my login in the log to be foobar - it doesn't really make a difference what the login is because the session never gets to the point where it prompts you for a password. You should be able to test against the server without having a login. If it gets to a password, the error should be resolved.

comment:3 Changed 5 years ago by iggy

I confirm this problem. Any workarounds?

comment:4 Changed 5 years ago by jystickman

None that I have been able to determine save for going back to using iChat.

comment:5 Changed 5 years ago by Robby

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

comment:6 Changed 5 years ago by Robby

  • Keywords Snow Leopard added

comment:7 Changed 5 years ago by sharakan

I can also confirm this problem. And like jystickman, iChat is my only recourse.

comment:8 follow-up: Changed 5 years ago by xre

Same boat - same symptoms, same recourse.

comment:9 Changed 5 years ago by RandallS

appears as though SSL is an issue in 12945 and 12955; hate iChat.

comment:10 in reply to: ↑ 8 Changed 5 years ago by mulsoft

Same for me, just switched to iChat temporarely ...

comment:11 Changed 5 years ago by jwhyne

Same for me as well.

comment:12 Changed 5 years ago by Robby

Everyone,

as stated in ReportingBugs we don't this mass of "me, too" comments. Just vote the ticket up: see the arrows at the top.

comment:13 Changed 5 years ago by Robby

  • Severity changed from normal to regression

comment:14 Changed 5 years ago by Robby

  • Milestone set to Adium 1.4

comment:15 Changed 5 years ago by ryderllama

Not sure if anyone has indicated the Jabber server this has been reported against. Seems pertinent as I log into a different jabber server (Openfire v3.6.4) just fine in SSL mode. I'm seeing failures to connect to Sun Java System Instant Messaging version 7.3 after upgrading to Snow Leopard. It worked fine on OS X 10.5.8. This appears to be a widespread issue for my company that uses this IM server

comment:16 follow-up: Changed 5 years ago by throughnothing

I notice that Google talk works for me using SSL in 10.6, but my own jabber server (running ejabberd 2.0.3) does not work. My jabber server *does* work with the same version of adium (1.4b9) in leopard (10.5.8 and earlier). My ejabber server only allows ssl, so I cannot try connecting without SSL, however it seems my error may be slightly different. Here is a log snippet from my error:

20:35:36: Connecting: gc=0x1a1f3d40 (Initializing Stream) 2 / 5
20:35:36: (Libpurple: jabber) Sending: <stream:stream to='domain.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>
20:35:36: ************ domain@domain.com --step-- 2
20:35:36: (Libpurple: jabber) Recv (93): <stream:error><invalid-namespace xmlns='urn:ietf:params:xml:ns:xmpp-streams'/></stream:error>
20:35:36: (Libpurple: jabber) XML parser error for JabberStream 0x0: Domain 3, code 201, level 2: Namespace prefix stream on error is not defined
20:35:36: (Libpurple: jabber) Unknown packet: error
20:35:36: (Libpurple: connection) Connection error on 0x1a1f3d40 (reason: 0 description: Server closed the connection)
20:35:36: Connection Disconnected: gc=1a1f3d40 (Server closed the connection)
20:35:36: <ESPurpleJabberAccount:2584e90 25>:domain@domain.com accountConnectionReportDisconnect: Server closed the connection

Should this be filed as a different bug?

comment:17 Changed 5 years ago by madbrit

This breaks my service (at work) I see this issue. :-(

comment:18 Changed 5 years ago by madbrit

I had to stop using Adium and move back to iChat...

comment:19 Changed 5 years ago by b8drf

I noticed the Milestone has been changed to 1.4 - can someone give me an idea when 1.4 is slated for release (roughly) - since this Jabber issue is affecting 1000's of users at our company we need to determine if we simply wait or migrate folks to iChat - Thanks!

comment:20 Changed 5 years ago by darkrain42

  • Cc darkrain42 added

comment:21 in reply to: ↑ 16 Changed 5 years ago by darkrain42

Replying to throughnothing:

I notice that Google talk works for me using SSL in 10.6, but my own jabber server (running ejabberd 2.0.3) does not work. My jabber server *does* work with the same version of adium (1.4b9) in leopard (10.5.8 and earlier). My ejabber server only allows ssl, so I cannot try connecting without SSL, however it seems my error may be slightly different. Here is a log snippet from my error:

Should this be filed as a different bug?

I think that's a different bug.

comment:22 Changed 5 years ago by threar

As I haven't seen movement on this ticket for 3 weeks, I was wondering if there's a status update. Last mention was that the fix is expected for Adium 1.4, but no timeframes have been given for that. Are there any updates?

comment:23 follow-up: Changed 5 years ago by Robby

There has been little progress towards the 1.4 release or even a newer beta in recent weeks.

comment:24 in reply to: ↑ 23 ; follow-up: Changed 5 years ago by sharakan

Replying to Robby:

There has been little progress towards the 1.4 release or even a newer beta in recent weeks.

This is a pretty serious regression. Have any resources at least been put into triaging the problem? Can we please have something sooner than 1.4 if that release isn't moving at speed.

comment:25 Changed 5 years ago by Robby

I'm no developer myself but I'm sure patches are welcome.

comment:26 in reply to: ↑ 24 Changed 5 years ago by b8drf

Replying to sharakan:

Replying to Robby:

There has been little progress towards the 1.4 release or even a newer beta in recent weeks.

This is a pretty serious regression. Have any resources at least been put into triaging the problem? Can we please have something sooner than 1.4 if that release isn't moving at speed.

I agree - this Jabber SSL failure under Snow Leopard is affecting 1000's of user in our organization - we have therefore switched them over to iChat and I suspect we will not be switching them back to Adium which is a shame.

comment:27 Changed 5 years ago by calum

If your organization has 1000's of users, surely it was a bit foolhardy to upgrade them all to Snow Leopard a) so soon after release, and b) without first testing everything they're likely to be using...?

comment:28 Changed 5 years ago by b8drf

Not foolhardy at all - you are assuming we did't know about the Adium limitation before we swithced the users - wrong assumption. The benefits of Snow Leopard far outweighed the downside of loosing Adium so it was an informed choice. My comment was a request for some timeline on the Adium fix - to be honest I am surprised about the lack of pace in fixing what would seem to be a pretty significant regression - I guess this is the price you pay for relying on Opensource solutions. On the upside our users are now able to use video capabilities within iChat which they couldn't before in Adium.

comment:29 Changed 5 years ago by darkrain42

The logs from a server that produces this problem would be incredibly useful.

22:48:26 < proton> so it's actually the server returning an Internal Error 
                   response
22:49:18 < darkrain> ugh, that makes it much harder to diagnose.
22:49:52 < proton> yeah, need to get our hands on a server that fails
22:50:08 < proton> it fails after the client sends the Client Key Exchange 
                   message

Changed 5 years ago by jystickman

Server Error Logs

comment:30 Changed 5 years ago by jystickman

darkrain and proton - added a server log per your request. Also, the IM server uses TLS and not straight SSL.

Let me know if this helps.

comment:31 Changed 5 years ago by darkrain42

Could someone get a packet capture of this not occurring when using Adium 1.4b9 on 10.5, please? (That server log turns out to be not very useful and fairly opaque, at least to me)

Something like sudo tcpdump -s0 -n -w adium-1.4b9-OSX-10.5.pcap port 5222 should produce the file. My email address is <my nick> -at- pidgin.im (or I think the Adium developers have a private feedback address).

comment:32 follow-up: Changed 5 years ago by jystickman

darkrain - I can try this tomorrow, but is there a reason that tcpdump isn't working for you? The failure happens before a login is needed - I provided the target server and config info in the first attachment and bug description. Is there something special you're looking for that can't be replicated so far by the developers?

Unfortunately, the system I'm on at the moment is SL...

Changed 5 years ago by proton

Patch to fix issue

comment:33 in reply to: ↑ 32 ; follow-up: Changed 5 years ago by darkrain42

Replying to jystickman:

darkrain - I can try this tomorrow, but is there a reason that tcpdump isn't working for you? The failure happens before a login is needed - I provided the target server and config info in the first attachment and bug description. Is there something special you're looking for that can't be replicated so far by the developers?

Unfortunately, the system I'm on at the moment is SL...

Sure, I can do tcpdump (and I had). I wanted to compare the two (I only have a SL computer), in particular the negotiated ciphers (and whether or not 10.5 offered the elliptic_curve options on the client hello).

It's a moot point, though, because Proton correctly noticed the issue was the server being unable to properly handle an elliptic curve mechanism (and attached a patch).

comment:34 in reply to: ↑ 33 Changed 5 years ago by jystickman

Replying to darkrain42:

Sure, I can do tcpdump (and I had). I wanted to compare the two (I only have a SL computer), in particular the negotiated ciphers (and whether or not 10.5 offered the elliptic_curve options on the client hello).

Oh. Oops. Hadn't thought that was the issue. I was looking for something deeper. My bad and my apologies.

It's a moot point, though, because Proton correctly noticed the issue was the server being unable to properly handle an elliptic curve mechanism (and attached a patch).

Thanks very much darkrain (and proton too). When a build is available with the change, I'll be happy to test. Thanks again for your efforts.

comment:35 follow-up: Changed 5 years ago by Andrew Wellington <proton@…>

  • Resolution set to fixed
  • Status changed from new to closed

(In 63a2af2e3e41) Remove elliptic curve ciphers from the cipher list as it causes a number of XMPP servers to break. This is the same cipher set that Mac OS X 10.5 used, and the same as 10.6 without the EC ciphers.

Reviewed by sholt. Fixes #12913

comment:36 in reply to: ↑ 35 Changed 5 years ago by sharakan

Replying to Andrew Wellington <proton@…>:

(In 63a2af2e3e41) Remove elliptic curve ciphers from the cipher list as it causes a number of XMPP servers to break. This is the same cipher set that Mac OS X 10.5 used, and the same as 10.6 without the EC ciphers.

Reviewed by sholt. Fixes #12913

I pulled over & built the latest changeset and can confirm it solves the problem for our corporate XMPP server. Thanks!

comment:37 Changed 5 years ago by Andrew Wellington <proton@…>

(In a84d7da4ebde) Remove elliptic curve ciphers from the cipher list as it causes a number of XMPP servers to break. This is the same cipher set that Mac OS X 10.5 used, and the same as 10.6 without the EC ciphers.

Reviewed by sholt. Fixes #12913

comment:38 follow-up: Changed 5 years ago by ryderllama

Is there any chance we can get this fix added to the 1.3.X branch?

I was all excited when I saw 1.3.7 come out, but then didn't see this fix incorporated into it :(

comment:39 in reply to: ↑ 38 Changed 5 years ago by b8drf

Replying to ryderllama:

Is there any chance we can get this fix added to the 1.3.X branch?

I was all excited when I saw 1.3.7 come out, but then didn't see this fix incorporated into it :(

Yes, I would really like to see this included in the 1.3.x branch - I had to take a stable version of the 1.4 source and compile to get this working on 64bit SL but would much prefer to be using a released version ... Cheers!

comment:40 Changed 5 years ago by cnewman

Andrew Wellington, could you please explain the elliptic curve problem in more detail? If it's actually a server problem (server fails to parse a valid TLS request or selects an unusable cipher suite) I will lobby to get Sun's jabber server fixed (the one that's been problematic for me). If it's a MacOS problem (Apple's TLS library advertising a TLS cipher suite that doesn't work), I can open a bug in Apple's database to vote to get that fixed. To do either of those, I need sufficient information to open a coherent bug report showing who is at fault in terms of protocol compliance. Mozilla's ssltap tool may be helpful:

http://www.mozilla.org/projects/security/pki/nss/tools/ssltap.html

If it's actually an Adium client problem, then please treat this with a high priority and get it into 1.3.x branch as I can not use Adium until it is fixed.

Thank you.

comment:41 Changed 5 years ago by zacw

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

Note: See TracTickets for help on using tickets.