maemo.org Bugzilla – Full Text Bug Listing
|Summary:||XMPP lacks option to require TLS (vulnerable to MITM attacks)|
|Product:||[Maemo Official Applications] Chat & Call & SMS||Reporter:||Olle Segerdahl <olle>|
|Status:||RESOLVED FIXED||QA Contact:||communication-bugs|
|Priority:||Unspecified||CC:||andre_klapper, corsac, maemo|
SOFTWARE VERSION: 2.2009.51-1 (affects all version of Maemo with Telepathy/Gabble) The OVI by Nokia IM profile does not support SSL/TLS operation. Though the jabber client has SSL support, there is no way to enable it for Ovi Chat. This means that your OVI password is sent in clear text each time you connect to OVI Chat (such as when you change Internet connection profile or presence). The expected behaviour is to use SSL/TLS since the server supports it. I'm guessing the reason why it has been left out is because the XMPP client doesn't support the DNS service records that the OVI Jabber server (chat.ovi.com) requires you to use for correct TLS operation. (see RFC3920 paragraphs 5.1 and 14.3) Ideally this report would be treated as a security bug and not a feature request.
Thanks for the report. I'm afraid I can't reproduce this - a packet capture shows starttls negotiation taking place before authentication and everything is encrypted after that point. Clear steps to reproduce would be very welcome.
Sorry, I didn't check the details properly. Steps to reproduce: 1. Add a "192.168.1.1 chat.ovi.com" line to the /etc/hosts file 2. On 192.168.1.1 run "nc -vvnl 5222" 3. Connect to OVI Chat 4. When the nc receives the session paste a jabber server response with no starttls and only PLAIN sasl mechanism. 5. Client sends credentials in cleartext (base64 encoded) To make this more clear: In 2.2009.51-1 (and probably older releases) there is a man-in-the-middle issue due to not requiring TLS before authenticating that exposes credentials in clear text over the network. This has nothing to do with not supporting SRV records (that was old bug on Maemo4).
Thanks! Confirming, for *all* XMPP accounts. There are probably some misguided souls out there who run XMPP servers without TLS so requiring it may have to be optional, but the option should be there and it should default to ON. At least for "normal" XMPP accounts one can force use of SSL on port 5223 but this is not available on ovi chat accounts. Adding Default-port = 5223 Default-old-ssl = 1 in /usr/share/osso-rtcom/nokiachat.profile (google talk for example already does this) and param-old-ssl=true param-port=5223 in the ovi stanza in /home/user/.rtcom-accounts/accounts.cfg does not work (the config gets reset as soon as the account is re-enabled).
"Gabble supports it. rtcom-accounts-ui does not before PR1.2." This has been fixed in package rtcom-accounts-ui 4.116-2+0m5 which is part of the internal build version 10.2009.52-5 (Note: 2009/2010 is the year, and the number after is the week.) A future public update released with the year/week later than this internal build version will include the fix. (This is not always already the next public update.) Please verify that this new version fixes the bug by marking this bug report as VERIFIED after the public update has been released and if you have some time. To answer popular followup questions: * Nokia does not announce release dates of public updates in advance. * There is currently no access to these internal, non-public build versions. A Brainstorm proposal to change this exists at http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/
(In reply to comment #4) > "Gabble supports it. rtcom-accounts-ui does not before PR1.2." True, empathy has had it for ages. When this fix is released, Ovi accounts (rtcom-accounts-plugin-nokiachat) should default to require TLS, otherwise they will still be vulnerable. Should a separate bug be filed for the Ovi case or is that already taken care of?
(In reply to comment #4) > To answer popular followup questions: > * Nokia does not announce release dates of public updates in advance. > * There is currently no access to these internal, non-public build versions. > A Brainstorm proposal to change this exists at > http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/ In case of security issues, shouldn't out of band (or scheduled batches) security updates be considered. I'm a bit concerned about security (for professional reasons) of the Maemo platform, and I'm not aware of a security response team handling this. It's more generic than just this so I might open a brainstorm or something (just not sure “brainstorm” doesn't mean “/dev/null” yet). What do you think (and sorry for off topic).
Setting explicit PR1.2 milestone (so it's clearer in which public release the fix will be available to users). Sorry for the bugmail noise (you can filter on this message).