Opened 13 years ago

Closed 13 years ago

Last modified 11 years ago

#9553 closed enhancement (fixed)

AIM+ICQ feature request (support port 5190, using SSL)

Reported by: akin Owned by: nobody
Milestone: Adium 1.4 Component: Service/AIM
Version: Severity: normal
Keywords: AIM, ICQ, dot mac, .Mac, SSL, Cc: anthony.kinyon+adiumfeaturerequest@…
Patch Status:


The latest iChat from Apple supports SSL over AIM/ICQ/.Mac using port 5190 and server . It seems that Adium presently disallows user specification to use SSL (does not offer the option) nor does it offer using a custom port. Tested with a .Mac account using 1.2.4 on Leopard/Intel. This would be more secure so can the appropriate option(s) please be made available? Thank you.

Change History (21)

comment:1 Changed 13 years ago by Anthony Kinyon

This is related to #9474 (closed).

This should not depend on libpurple. It is very easy to add support to use an optional custom server address and enable SSL over the connection. In fact I don't think that really has much of anything to do with libpurple? (Meant with respect). Please reconsider adding this feature, I think it would be nice and would not take much effort or time to implement.

comment:2 Changed 13 years ago by Anthony Kinyon

I believe port 443 can also be used, but port 5190 is the default.

comment:3 Changed 13 years ago by Anthony Kinyon

I still feel that libpurple doesn't necessarily own responsibility for this functionality, although it would be nice to see it supported in both Adium and Pidgin.

I did open a ticket with Pidgin just incase they think it's "their responsibility" to handle this.

Again, I still feel that Adium could do this on their own with minimal effort, and should.

comment:4 Changed 13 years ago by Thomas Gibson-Robinson

This, unfortunately, cannot be done with minimal effort (and it could never be done the way you are suggesting, at least while libpurple is being used). Sean Egan (the lead developer of Pidgin and thus libpurple) said this in August last year:


PS You can get SSL'ed OSCAR by connecting to and then everything else is normal. I had one of my summer of code students try it last year, but he apparently hit a wall because the SSL state is shared amongst each OSCAR connection or something.



Also, you shouldn't create duplicate tickets - that's only going to frustrate the nice people who triage all these tickets!

comment:5 Changed 13 years ago by Anthony Kinyon

Hi tomgr,

Sorry, did not see a way to re-open the existing ticket. I may have missed the option to do so. I didn't set out with the mindset "Gosh, I think I'll go screw with the Adium team this morning by opening a duplicate ticket." I mean, let's use common sense and not waste time insinuating that it was my goal. The typical person wouldn't do that intentionally. In any case, I don't wish this to degenerate.

My thought on this is that SSL is an industry standard, I don't know why it would be implemented so differently over OSCAR but maybe AOL has done something to modify how it is used that I'm not aware of. I wasn't aware of Sean's comments last year, but I thank you for sharing, as it is good information. Just because problems were encountered doesn't mean they should just give up, though. :) I know things are easier said than done, of course, as is always the way. But I hope we can get this support. What if someone runs a packet sniffer on iChat (Leopard), would that provide better data to analyze? I assume that doing so is perfectly legal since it is technically your own IP traffic.

comment:6 Changed 13 years ago by Thomas Gibson-Robinson

Indeed, there is no way to reopen a ticket unless you are one of the few that have the appropriate permissions. I think what the Adium team like people to do is for them to comment in the original ticket, and they will then re-open it if necessary, but I'm not in anyway a member of the team so this is just based off past experience!

You are quite right it is perfectly legal (well from what I've heard it is, but I have zero legal knowledge) but I'm not sure it would be particularly useful, the problem is a bit of a tricky one as (you guessed correctly) AOL appears to be using SSL in a non-standard fashion. From what I understand each connection to the AOL servers has to use the same SSL state, which is not the way it works in standard SSL; each connection will have its own state. This would be tricky to overcome as it would probably require reworking of the SSL libraries! To be honest you're probably best off directing any technical bits to the pidgin ticket you opened - the guys there will be the ones who will fix it and will know far more than I do!

I wouldn't be overly worried about it not being encrypted, your password is not transmitted in plaintext (see for what is sent) so no-one can login to your account (and its also not vulnerable to replay attacks).

comment:7 Changed 13 years ago by Robert

Resolution: invalid
Status: newclosed

Thanks for your comments, tomgr, they were appropriate! :)

comment:8 Changed 12 years ago by m1b

tomgr -- your final comment about not being worried that traffic isn't being encrypted doesn't take logins via public net access into account.

While I certainly care about my account's auth info not being exposed, I also absolutely care about keeping the contents of my chats private while it's in transit to the AIM host. OTR is great if I know I have someone at the other end who can do OTR, but I don't always have that luxury. In some cases, I'll accept the risk that all I can secure is the connection between myself and AOL, but that's my decision.

That said, clearly this is a pidgin issue rather than a Adium issue.

comment:9 in reply to:  6 Changed 12 years ago by Peter Hosey

Replying to tomgr:

… I think what the Adium team like people to do is for them to comment in the original ticket, and they will then re-open it if necessary …

That's correct.

comment:10 Changed 12 years ago by lid

A patch was submitted to the libpurple/pidgin ticket a couple weeks ago that adds SSL capability, so hopefully this will become possible soon...

comment:11 Changed 12 years ago by Robert

Thanks for the update, lid! :)

comment:12 Changed 12 years ago by Paul Aurich

The aforementioned libpurple code has been merged into im.pidgin.pidgin and will be in the next release of Pidgin and, as of [25947] and [25949], is in Adium's libpurple framework. I believe the only remaining step is to add the GUI account option for toggling SSL.

comment:13 Changed 12 years ago by Robert

Thanks, Paul! I'll copy your comment to #9474. :)

comment:14 Changed 12 years ago by Zachary West

Resolution: invalidfixed

(In [26198]) Adds two Oscar UI options:

  • Always use proxy server for FT/DIM (Fixes #11413)
  • Use SSL for connections (Fixes #9553) - This appears to be a little bit buggy - once you set "use_ssl", the account has a really hard top stopping using it. I'm confident "use_ssl" is 0, but it's still negotiating an SSL connection. This is classified as "experimental" in libpurple, last I saw.

I intend to go back and make the Oscar account view > an AIM and ICQ account view, since this is duplicating code between the Oscar and ICQ account views. The Oscar view expects a profile (should go in AIM), with the SSL/proxy stuff in the general Oscar view.

comment:15 Changed 12 years ago by Zachary West

Milestone: Adium 1.4

comment:16 Changed 12 years ago by Zachary West

(In [26199]) Fixes [26197] with some help from darkrain42: instead of accessing random locations in memory to determine if we're connected via SSL, return the correct location. Corrects the problem I noted in [26197], refs #9553.

comment:17 Changed 12 years ago by Zachary West

(In [26200]) Last try on [26197] - we need to iterate over all of the oscar_connections to find any SSL connections. Certain Oscar connections (buddy icons, etc) are required to use non-SSL connections, and may be the head of the GSList. Refs #9553.

comment:18 Changed 12 years ago by Zachary West

(In [26201]) Generalize the "show server certificate" logic from Purple Jabber accounts to all Purple accounts. Can now view the AIM certificate when connected. Refs #9553.

comment:19 Changed 11 years ago by Paul

How does one enable this for .Mac? Changing the login server to slogin doesn't seem to do the trick.

In addition, I'm seeing something odd – when editing an AIM account, the only way to trigger SSL seems to be to change the server to slogin. on ICQ, you can do that too, but there's also a "Encrypt connection using SSL" checkbox. however, checking this box with the default login server (login.icq) results in a failed SSL handshake error. .Mac accounts don't have any SSL checkboxes either.

what's up with these inconsistencies? thanks!

comment:20 Changed 11 years ago by Zachary West

You do not need to change the login server for SSL. Set up your account as a MobileMe, I don't know what .Mac is doing these days.

comment:21 Changed 11 years ago by Paul

but this was an old account, are you suggesting users recreate accounts for this? seems like a kludgey workaround and it's not clear why .Mac should be behaving any differently. (i.e. if it is behaving differently, that's a bug).

re: not needing to change the server, like I said, in 1.4b12, checking SSL in ICQ prefs and leaving the server as is results in a SSL handshake error.

Note: See TracTickets for help on using tickets.