|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|
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 (gmx.net) as provider for my Jabber service. I'm quoting myself (from the forum, see http://forums.miranda-im.org/showpost.php?p=188797&postcount=103 and http://forums.miranda-im.org/showpost.php?p=188799&postcount=105 etc. for the context) <quote> 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. </quote> 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.
Aug 19, 2009
(No comment was entered for this change.)
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 negotiated? 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="http://etherx.jabber.org/streams" version="1.0" xmlns="jabber:client" to="gmail.com" xml:lang="en" xmlns:xml="http://www.w3.org/XML/1998/namespace" > <stream:stream from="gmail.com" id="24315FA8D6545A6F" version="1.0" xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client"> <stream:features> <starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"> <required/> </starttls> <mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"> <mechanism>X-GOOGLE-TOKEN</mechanism> </mechanisms> </stream:features> 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
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 = 192.168.1.2 [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="http://etherx.jabber.org/streams" xml:lang="en" version="1.0"> [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='http://etherx.jabber.org/streams' 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- sasl'><mechanism>PLAIN</mechanism></mechanisms></stream:features> [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 credentials]</auth> [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 required</text></stream:error></stream:stream> [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, jabberNetworkBufferSize=2048 [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
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 "jabber.ccc.de", 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
This issue was closed by revision r11424.
|► Sign in to add a comment|