My favorites | Sign in
Project Home Downloads Issues Source
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 152: unencrypted connection to Jabber server although TLS is set
5 people starred this issue and may be notified of changes. Back to list
Status:  Fixed
Owner:  george.hazan
Closed:  Mar 2010
Cc:, maxim.mluhov

Sign in to add a comment
Reported by, Aug 18, 2009
Miranda Version                  : 0.9.0
Unicode Build                    : Yes
Test Build # (if applicable)     : alpha build #1
Plugin Version # (if applicable) :

What steps will reproduce the problem?
I'm using GMX ( as provider for my Jabber service.

I'm quoting myself (from the forum, see and etc. for
the context)
About the password thing. In the account manager I had selected "Secure
XMPP Network". When I now turn to the network preferences (which I hadn't
done earlier) than I see that TLS is enabled, but SSL is not. The outcome
is that the connection is not encrypted.

When I select "Secure XMPP Network (old style)" the alternate port 5223
instead of 5222 is set and SSL is activated. The TLS checkbox is disabled
at that point. And indeed, the connection is encrypted. In Wireshark I can
see how the server sends a certificate. An later on I couldn't see any
plaintext passwords.

The third thing I tried was set "Secure XMPP Network" but manually select
SSL instead of TLS to see what happens. The config dialogue automatically
picks port 5223 if I check the SSL box. Upon login I see again how the
server sends a certificate to Miranda. After that I cannot see any
plaintext so I suppose it's all secure cypher text. But I can't tell the
algorithm right away. But that shouldn't matter anyway.

What is the expected result?
Miranda should warn the user that the connection is not encrypted although
it is expected to be. A promp asking whether Miranda should proceed would
be great. Similar to browsers or maybe PuTTY.

What happens instead?
Miranda connects through an insecure connection, sending login credentials
as plaintext.

The network log that I attached shows the login procedure to the GMX server
using the "Secure XMPP Network" w/ TLS.
2.0 KB   View   Download
2.4 KB   View   Download
Aug 19, 2009
Project Member #1
(No comment was entered for this change.)
Status: Assigned
Labels: Component-Protocol-Jabber
Aug 20, 2009
I have not tested… but are you sure you know how ‘TLS’ and ‘SSL’ options work?

First of all, the first method should be called STARTTLS and it is the standard hop 
to hop encryption method used (and specified) in XMPP Core RFC. The second 
method should be called ‘Legacy SSL on separate port method’ or something like 
that. After all, TLS 1.0 and SSLv3 are more or less the same thing.

So: ‘than I see that TLS is enabled, but SSL is not. The outcome
is that the connection is not encrypted.‘

Well, these options are mutually exclusive. You cannot do both methods. No 
wonder ‘SSL’ is disabled when ‘TLS’ is enabled.

What's different is how client and server negotiate the encryption. With old-
style/legacy encryption, the client opens secure socket on port 5223 and the 
communication is encrypted from that point. This is NOT standard XMPP.

On the other hand, with STARTTLS, client always uses the standard port (usually 
5222, but really as discovered via DNS SRV record lookup) and at first connects via 
plain-text. Then some connection features can be negotiated after client checks if 
they are supported by the server. If STARTTLS is among the supported features, the 
stream is restarted and the connection is encrypted from that point onwards.

So… My question is – have you actually got past the point where STARTTLS is 

Well… looking through your jabbeauth.txt, it seems kinda strange. Maybe their 
server is actually broken or does not support STARTTLS? See how opening stream 
with Google Talk server looks and notice the starttls feature:

<?xml version="1.0"?>

<stream:stream xmlns:stream="" version="1.0" 
xmlns="jabber:client" to="" xml:lang="en" 
xmlns:xml="" >

<stream:stream from="" id="24315FA8D6545A6F" version="1.0" 
xmlns:stream="" xmlns="jabber:client">

<starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls">
<mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl">

They also seem to use old-style username/password authentication on GMX instead 
of SASL… It really seems like server issue. Maybe they are running some ancient 
software which actually does not support XMPP?

In case it's server issue – I can only see one problem in Miranda: It does not tell the 
user that connection is not encrypted. E.g. Pidgin or Psi have options to require 
encryption and if that fails, they warn users and don't allow connecting.
Aug 22, 2009
I'm aware that TLS and SSL are mutually exclusive. I only described what happened in
my Miranda setup. After all, it could have been that my Miranda was acting strange
right from the start.

I read your note carefully. What made me wonder was the part about SASL. I have no
idea about its internals. And I probably won't be reading RFC4422 anytime soon. ;)
However, by chance I ran accross the "advanced options" tab in the jabber
configuration dialog. I noticed that SASL was disabled. I cannot remember that I've
ever changed this setting. So I'm guessing it must have been (an old?) default
setting. I can't tell. So I went on and enabled SASL. I did a few tests with
Wireshark running in the background. Here's what I found.

1) SSL (port 5223) and SASL worked. The connection was encrypted - as expected.
2) TLS and SASL also worked. And this time I also saw the starttls command. After
that a certificate was transfered and from then on the connection was encrypted. I
just don't know which mechanism was used to authenticate with the server. The text
node of the <mechanism> element said "PLAIN". I didn't take a network log but I can
create one any time if necessary.
3) I wanted to double-check so I kept TLS on and deactived SASL. Again I got the same
result that I had initially reported. The connection was unencrypted and the password
was sent in plain text. After all, there was not starttls whatsoever.

So from my black box perspective, i.e. without looking at the code, I assume that
Miranda doesn't even attempt to send the STARTTLS command if SASL is deactivated. Now
I don't know if you need SASL in order to use TLS. I suppose not. At least from a
user's perspective it wouldn't make much sense to have a TLS checkbox and yet another
one that has a meaning like "TLS - this time for real".

The bottom line is this. First, I don't think that the server is at fault. With the
new findings I'm smelling some quirk in the jabber plugin. 2nd I strongly argue for a
warning to be displayed and an option to interupt if a password is about to get sent
through an insecure channel.
Aug 29, 2009
#4 waqas20
I can confirm this. With SASL disabled, Miranda performs legacy auth (jabber:iq:auth) 
right after it receives <stream:stream> from the server. No STARTTLS.

I should note here that SASL and STARTTLS support is required by the XMPP RFC, for both 
clients and servers.
Dec 13, 2009
The RFC 3920 defines the standard behaviour of entities, and it was published a way 
after the xmpp technology began to develop. So it defines some old behavior as non-
standard, and in order for an entity to distinguish if its counterpart uses standard 
or non-standard mode, the "version" attribute of the <stream:stream/> element set 
to "1.0" is used.
The <starttls/> element is defined in the 'urn:ietf:params:xml:ns:xmpp-tls' 
namespace that is defined by this RFC. The server must advertize it to a client only 
if the client told it that the version of the protocol is (at least) 1.0, otherwise 
it isn't applicable. In this case, only legacy SSL method makes sense.
The "Disable SASL authentication (for old servers)" option effectively makes 
Miranda's jabber plugin use pre-standard protocol (note that there's 
no 'version="1.0"' in the <stream:stream/> element in this case). So the server 
doesn't advertise, and the client doesn't use, tls.
This option should be renamed to something more descriptive (it disables not only 
SASL, so maybe something like "Use pre-RFC3920 protocol (for old servers; no TLS and 
SASL)" would be better?). And it would be fine if it disable the TLS checkbox (and 
the tooltip of the disabled TLS checkbox would state that it's disabled because of 
enabled "old protocol" option). This would make the Miranda's appearance consistent.
Another issue that may be related to this topic is that if using standard protocol, 
and disable both SSL and TLS in Miranda, and the server requires starttls, then 
Miranda still tries SASL authentication without starttls sending user credentials 
unprotected, and the server, of course, closes the connection. Miranda never warns 
user of the error, just silently cannot login. The communications log:

[18:51:57 JABBER_1] PS_SETSTATUS( 40072 )
[18:51:57 JABBER_1] SetAwayMsg called, wParam=40072 lParam=
[18:51:57 JABBER_1] Thread started: type=0
[18:51:57 JABBER_1] Thread type=0 server='pi.local' port='5222'
[18:51:57 JABBER_1] Connecting to pi.local:5222 (Flags 0)....
[18:52:00 JABBER_1] (1480) Connected to pi.local:5222
[18:52:00 JABBER_1] Local IP =
[18:52:00 JABBER_1] Stream is initializing after connect
[18:52:00 JABBER_1] (02609048:1480) Data sent
<?xml version="1.0" encoding="UTF-8"?><stream:stream xmlns="jabber:client" 
to="pi.local" xmlns:stream="" xml:lang="en" 
[18:52:00 JABBER_1] Entering main recv loop
[18:52:00 JABBER_1] (02609048:1480) Data received
<?xml version='1.0'?><stream:stream xmlns='jabber:client' 
xmlns:stream='' id='1221354266' from='pi.local' 
version='1.0' xml:lang='en'>
[18:52:00 JABBER_1] recvResult = 166
[18:52:00 JABBER_1] bytesParsed = 166
[18:52:00 JABBER_1] (02609048:1480) Data received
<stream:features><starttls xmlns='urn:ietf:params:xml:ns:xmpp-
tls'><required/></starttls><mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-
[18:52:00 JABBER_1] recvResult = 201
[18:52:00 JABBER_1] bytesParsed = 201
[18:52:00 JABBER_1] (02609048:1480) Data sent
<auth xmlns="urn:ietf:params:xml:ns:xmpp-sasl" mechanism="PLAIN">[my base64-encoded 
[18:52:00 JABBER_1] (02609048:1480) Data received
<stream:error><policy-violation xmlns='urn:ietf:params:xml:ns:xmpp-streams'/><text 
xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-streams'>Use of STARTTLS 
[18:52:00 JABBER_1] recvResult = 203
[18:52:00 JABBER_1] bytesParsed = 0
[18:52:00 JABBER_1] Unknown state: bytesParsed=0, datalen=203, 
[18:52:00 JABBER_1] Connection closed gracefully
[18:52:00 JABBER_1] recvResult = 0
[18:52:00 JABBER_1] Thread ended: type=0 server='pi.local'
[18:52:00 JABBER_1] (02609048:4294967295) Connection closed
[18:52:00 JABBER_1] Exiting ServerThread

My concerns are:
1. Miranda should analyze the <required/> element of <starttls/>. It isn't necessary 
to try the unencripted authentication if it's known beforehand that it will be 
rejected. It's just an extra exposure of a sensitive information to the wire.
2. Miranda should notify user of such an event. It's rather difficult for an 
unexperienced user to guess the true cause of him be unable to login. The simple 
messagebox "The server requires encryption; make sure the TLS option is enabled" 
would help greatly.
Mar 17, 2010
Project Member #6 borkra
Issue 622 has been merged into this issue.
Mar 17, 2010
I think this might have shown something deeper - even with "Use TLS" checked,
connections without TLS can occur. IMHO, there should be a check in the code (before
sending the login) of the kind "if use TLS is checked and the connection is not
TLS-secured for whatever reason, abort and warn". IMHO thats what users expect. If I
check "use TLS", I assume I can connect safely even if I am in an insecure network.

What happens if the server says it supports no TLS and "Use TLS" is on? In case an
unencrypted connection is made, the whole TLS stuff is useless against active
attackers: An attacker performing an MitM attack will just spoof a server that does
not have TLS. For this reason, it is crucial not to fall back to unencrypted
connections if the server does not support TLS.

BTW, I do not agree that its "a setting nobody uses" so it is not an issue. I noticed
it by accident and another user had this setting on too. I probably enabled it when I
had some connection problems and had hoped to fix them this way. I am using the
server "", which I would consider "one of the larger ones", and it does
allow this setting. And sending data in clear that is assumed to be encrypted because
of a seemingly (at least for regular users) unrelated setting seems to be more than
just a nuisance to me.
Mar 20, 2010
Project Member #8 borkra
This issue was closed by revision r11424.
Status: Fixed
Sign in to add a comment

Powered by Google Project Hosting