maemo.org Bugzilla – Bug 9005
XMPP lacks option to require TLS (vulnerable to MITM attacks)
Last modified: 2010-03-15 20:52:35 UTC
You need to
before you can comment on or make changes to this bug.
SOFTWARE VERSION: 2.2009.51-1 (affects all version of Maemo with
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
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
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
which is part of the internal build version
(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
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
(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
(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
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).