The State of TLS on XMPP

https://blog.thijsalkema.de/blog/2013/09/02/the-state-of-tls-on-xmpp-3/

by xnyhps • 13 years ago

73 32 13 years ago

blog.thijsalkema.de

spurgu• 13 years ago

Part 1 & 2 of the series:

https://blog.thijsalkema.de/blog/2013/08/26/the-state-of-tls...

https://blog.thijsalkema.de/blog/2013/08/28/the-state-of-tls...

nsmartt• 13 years ago

Somewhat off-topic: What are some alternatives to XMPP? I haven't found much about messaging protocols.

lobster_johnson• 13 years ago

SIMPLE [1], mostly. There is also IMPP [2], an XMPP competitor which has a bunch of RFCs behind it, but never gained any implementations, as far as I know.

Alternatives such as the MSN, AOL and Skype's IM protocols are shoddily defined, cruft-ridden ad-hoc protocols that people have been mostly able to reverse engineer, but they are not useful except for interoperability with existing networks.

SIMPLE has not been deployed to any great extant, that I know. The benefit to XMPP is that it's not just well defined (a bunch of RFCs with a working group behind them), but also a proven protocol that has years of production use under its belt. The problem with the IM protocol landscape is entirely political. Everyone wants to own the network, nobody wants to be compatible.

[1] https://en.wikipedia.org/wiki/SIMPLE

[2] https://en.wikipedia.org/wiki/Instant_Messaging_and_Presence...

unknownian• 13 years ago

Very active development, already multiple clients, encrypted and P2P only: http://tox.im/

devx3• 13 years ago

What about Moxie's TextSecure? I think it's going to be integrated into CyanogenMod ROM's soon, so I'd like to see an evaluation of that, too. An evaluation of Surespot would be nice, too, even though it's not using PFS.

aw3c2• 13 years ago

It's SMS, not XMPP.

frank_boyd2• 13 years ago

If you're looking for encrypted OTR/decentralized/p2p messaging, also take a look at http://retroshare.sourceforge.net/

JulianMorrison• 13 years ago

Has anyone done a cryptographic audit of this?

frank_boyd2• 13 years ago

As for me, no. Mail the devs for any questions, they're very available.

The application itself is open-source.

devx3• 13 years ago

Is HTTP 2.0 finalized and approved? If not could we push for it to support PFS by default with ECDHE, which seems to add only 15 percent overhead [1]? That seems like a small price to pay if the security of every session grows exponentially, with each one being encrypted with a new key.

HTTP 2.0/SPDY already makes TLS mandatory, no? So why not make PFS mandatory, too? I'd rather we do it now than wait for HTTP 3.0, and it might force a lot more companies to adopt it by default as they move to HTTP 2.0 (companies such as Microsoft [2]).

EDIT: Links

[1] http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-se...

[2] http://news.netcraft.com/archives/2013/06/25/ssl-intercepted...

xnyhps3• 13 years ago

I wrote this post before the latest of Snowden's revelations and Bruce Schneier's comments on them[1].

"Prefer conventional discrete-log-based systems over elliptic-curve systems; the latter have constants that the NSA influences when they can."

I'd rather have some smart people take a thorough look at the curves we use before we make ECDHE mandatory. If we need to choose between computationally heavy DHE or possibly backdoored ECDHE, I'm afraid many companies will still pick ECHDE.

[1] http://www.theguardian.com/world/2013/sep/05/nsa-how-to-rema...

agwa• 13 years ago

Be careful with traditional Diffie-Hellman, which in practice also has problems: if your server software doesn't let you specify your own parameters, it's probably using 1024 bit parameters. All versions of Apache are guilty of this[1], as are (at least the versions I checked) Dovecot and Postfix. I would not trust 1024 bit DH in the face of an adversary like the NSA. It would be interesting to check how XMPP server software handles DH parameters.

[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=49559

Edit to add: Prosody allows you to specify dhparams, though the documentation is vague[2]. Don't see anything in the ejabberd docs for this[3].

[2] http://prosody.im/doc/advanced_ssl_config

[3] http://www.process-one.net/docs/ejabberd/guide_en.html

devx3• 13 years ago

I think DJB is saying that the "default" ones recommended by NIST like P-224 are weak, but if you use something like Curve25519, then you're fine.

Full paper:

http://cr.yp.to/talks/2013.05.31/slides-dan+tanja-20130531-4...

JshWright5• 13 years ago

Anecdotally, we see > 98% of browser clients using PFS cipher suites.

Sure it would be nice if it was mandatory, but 98% is _very_ good.

mike-cardwell• 13 years ago

Handy tip: If you want to use ssllabs.com server test against a non-HTTP based SSL service on your host which runs on a different port, you can temporarily add this rule to iptables so that any connetions from SSL labs on port 443 get redirected to it:

iptables -t nat -I PREROUTING -s 173.203.79.216 -p tcp --dport 443 -j REDIRECT --to-port 5223

In this particular case, I turned on legacy SSL in my XMPP servers (Prosody) configuration so that an SSL on connect service existed on port 5223.

Of course, in the results that SSLlabs displays, you'll get some strange information as it's expecting HTTP, but the majority of the information is useful.

aprescott3• 13 years ago

Note that ECDH and DH are different authentication mechanisms: these require special certificates and offer no forward-secrecy.

I contacted the author about this, but I don't think this is correct.

The OpenSSL ciphers documentation[1] says "DH" is simply all suites using Diffie–Hellman, not necessarily authenticated DH, which is "aDH". I actually couldn't check if it does include aDH since `openssl ciphers -v 'aDH'` tells me I don't have any aDH ciphers!

Unfortunately there's no documentation to explain the difference between EDH (ephemeral DH?) and DHE. Are they synonyms? I'm assuming DHE is ephemeral since using a string with DHE Will get you Perfect Forward Secrecy "points" on an SSL Labs test[2]. (Run the test! Secure your web servers! You can get at least a B rating easily enough.)

[1] http://www.openssl.org/docs/apps/ciphers.html

[2] https://www.ssllabs.com/ssltest/index.html

xnyhps3• 13 years ago

I clarified that I mean to refer to those with OpenSSL names that start with "ECDH-" and "DH-", which is not the same as what the shorthand "DH" gives you. As far as I can tell, EDH is an older synonym for DHE.

I like the ssllabs test and I hope this sort of testing gets more common for TLS usage that isn't HTTPS. However, I think a B is still cause for concern. You can only obtain a B if you have a) SSLv2 enabled (which is broken), b) cipher suites enabled with <128 bit symmetric keys, c) a RSA private key with less than 1024 bits or d) if you don't mitigate BEAST. I think only d) is a valid excuse under some circumstances.

On the other hand, a 1024 bit RSA key with SSLv3 and only RC4 will give you an A, but I would not call this very secure anymore.

aprescott3• 13 years ago

I indeed managed to get a B without trying to mitigate against BEAST (d). The trouble does seem to be that RC4 isn't vulnerable to BEAST, but it's not desirable because of its other vulnerabilities.

Since BEAST was fixed in TLS 1.1, I think you can require 1.1+ and get an A, but the test suggests you might break things for a significant chunk of users.

Even if you get a B because you're vulnerable to BEAST, if you prioritise 1.1+ ciphers, you'll still fail to get an A but you'll mitigate against it. It looks like Qualys themselves have a post on this, actually: https://community.qualys.com/blogs/securitylabs/2011/10/17/m...

ivanr3• 13 years ago

Yes, I agree. To get an A these days, a site should at the very least support TLS 1.2, and use a key stronger than 1024 bits. That's where we're heading.

P.S. If you have SSL 2 enabled, you'll get an F.

e12e3• 13 years ago

I think that's "ADH", not "aDH":

    $ openssl ciphers -v aDH
    Error in cipher list
    140473872484008:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:ssl_lib.c:1314:

    $ openssl ciphers -v ADH
    ADH-AES256-GCM-SHA384   TLSv1.2 Kx=DH       Au=None Enc=AESGCM(256) Mac=AEAD
    ADH-AES256-SHA256       TLSv1.2 Kx=DH       Au=None Enc=AES(256)  Mac=SHA256
    ADH-AES256-SHA          SSLv3 Kx=DH       Au=None Enc=AES(256)  Mac=SHA1
    ADH-CAMELLIA256-SHA     SSLv3 Kx=DH       Au=None Enc=Camellia(256) Mac=SHA1
    ADH-DES-CBC3-SHA        SSLv3 Kx=DH       Au=None Enc=3DES(168) Mac=SHA1
    ADH-AES128-GCM-SHA256   TLSv1.2 Kx=DH       Au=None Enc=AESGCM(128) Mac=AEAD
    ADH-AES128-SHA256       TLSv1.2 Kx=DH       Au=None Enc=AES(128)  Mac=SHA256
    ADH-AES128-SHA          SSLv3 Kx=DH       Au=None Enc=AES(128)  Mac=SHA1
    ADH-SEED-SHA            SSLv3 Kx=DH       Au=None Enc=SEED(128) Mac=SHA1
    ADH-CAMELLIA128-SHA     SSLv3 Kx=DH       Au=None Enc=Camellia(128) Mac=SHA1
    ADH-RC4-MD5             SSLv3 Kx=DH       Au=None Enc=RC4(128)  Mac=MD5 
    ADH-DES-CBC-SHA         SSLv3 Kx=DH       Au=None Enc=DES(56)   Mac=SHA1
    EXP-ADH-DES-CBC-SHA     SSLv3 Kx=DH(512)  Au=None Enc=DES(40)   Mac=SHA1 export
    EXP-ADH-RC4-MD5         SSLv3 Kx=DH(512)  Au=None Enc=RC4(40)   Mac=MD5  export

Also note:

    $ openssl ciphers -v ADH|wc -l
    14
    $ openssl ciphers -v DH|wc -l
    38

aprescott3• 13 years ago

The strings and documentation don't make it too easy to distinguish, but the docs do explicitly distinguish between aDH and ADH. I think "DH" includes any and every cipher that might use DH, but there's a good chance that for a cipher string like TLS_DH_DSS_WITH_AES_256_GCM_SHA384, which uses "DH", it's actually part of the "aDH" umbrella (certificate carries DH keys). (Credit to the original author of the article for spotting that one via RFC5246.)

JshWright5• 13 years ago

What's the author's concern about AES128?

  "The best cipher offered is 128-bit AES. So far, this has been the only client that doesn’t support 256-bit encryption that I’ve seen."

  "Surprisingly AES128 takes priority over AES256 here."

  "Surprisingly AES128 is first, followed by 3DES and only then AES256."

  "128 bit AES/Camellia is preferred over those with 256 bit, but at least RC4 is at the very bottom here."

Etc...

In my opinion, preferring AES128 over AES256 is a feature. AES128 is more than sufficient in terms of cryptopgraphic strength, it's faster, and it isn't susceptible to the key schedule weakness that the higher key sizes have.

xnyhps3• 13 years ago

The key schedule weakness in AES256 that I know of only applies to related-keys, which don't affect TLS as far as I know. If there's anything else I'm missing, I would like to know.

I don't have a specific concern with AES128 (compared to the concern I have about the usage of (EXP-)DES and RC4). It merely surprised me that some clients prefer AES128 over AES256 and I think it's important for server operators to know that there are clients that will stop working when disabling all <256 bit ciphers.

Personally I don't find speed a concern when using IM, it's not full-disk encryption or a large download where speed is noticable.

JshWright5• 13 years ago

I'll admit that my concerns are mostly theoretical (and you're absolutely right that _only_ offering AES-128 is a bad idea).

The related key attacks don't apply in TLS (but still if the majority of the known attacks only apply to the higher key sizes, that sets my tin-foil a'tingling), and as far as speed goes, the bulk encryption cipher is never going to be the bottleneck, no matter the key size.

It's also a matter of the right tool for the job. Why get out the 2# sledge hammer when the claw hammer will pound that nail in just fine? They'll both get the job done, and to a lay person, they might both look like the 'right' tool. The claw hammer is obviously the more 'elegant' tool though.

ivanr3• 13 years ago

All Java installations support only up to 128-bit AES by default. Oracle calls that "strong encryption". You can upgrade to "unlimited strength" by changing some policy files, after which 256-bit AES will be possible.

I don't know if that's what you're seeing, but there's definitely a class of clients that do not support 256-bit AES.

The State of TLS on XMPP

Related Stories