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.<p>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]).<p>EDIT: Links<p>[1] - <a href="http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html" rel="nofollow">http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-se...</a><p>[2] - <a href="http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html" rel="nofollow">http://news.netcraft.com/archives/2013/06/25/ssl-intercepted...</a>
<i>> Note that ECDH and DH are different authentication mechanisms: these require special certificates and offer no forward-secrecy.</i><p>I contacted the author about this, but I don't think this is correct.<p>The OpenSSL ciphers documentation[1] says "DH" is simply all suites using Diffie–Hellman, not necessarily <i>authenticated</i> 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!<p>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.)<p>[1]: <a href="http://www.openssl.org/docs/apps/ciphers.html" rel="nofollow">http://www.openssl.org/docs/apps/ciphers.html</a><p>[2]: <a href="https://www.ssllabs.com/ssltest/index.html" rel="nofollow">https://www.ssllabs.com/ssltest/index.html</a>
Part 1 & 2 of the series:<p><a href="https://blog.thijsalkema.de/blog/2013/08/26/the-state-of-tls-on-xmpp-1/" rel="nofollow">https://blog.thijsalkema.de/blog/2013/08/26/the-state-of-tls...</a><p><a href="https://blog.thijsalkema.de/blog/2013/08/28/the-state-of-tls-on-xmpp-2/" rel="nofollow">https://blog.thijsalkema.de/blog/2013/08/28/the-state-of-tls...</a>
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:<p>iptables -t nat -I PREROUTING -s 173.203.79.216 -p tcp --dport 443 -j REDIRECT --to-port 5223<p>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.<p>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.
What's the author's concern about AES128?<p><pre><code> "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."
</code></pre>
Etc...<p>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.
If you're looking for encrypted OTR/decentralized/p2p messaging, also take a look at <a href="http://retroshare.sourceforge.net/" rel="nofollow">http://retroshare.sourceforge.net/</a>
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.