

A roster of TLS cipher suites weaknesses - gits1225
http://googleonlinesecurity.blogspot.com/2013/11/a-roster-of-tls-cipher-suites-weaknesses.html

======
isomorphic
The elephant in the room for me is the legion of paying customers running old
Microsoft browsers.

Microsoft's regrettable browser-tying/integration strategy has exacerbated web
crypto problems. And it doesn't look like Microsoft is going to stop doing it,
either--ten years from now we'll be dealing with whatever crypto suites the
maximum IE version supports on Windows 7.

I'm picking on Microsoft here, but the same is true for any platform browser.
Crypto suites need to be completely modular, enabling backporting to old
environments.

------
lstamour
A fantastic overview of the past few years of exploits against SSL. All I can
add is a companion resource you probably already know about:
[https://www.ssllabs.com/projects/index.html](https://www.ssllabs.com/projects/index.html)

But even that doesn't give enough practical advice as to which ciphers to
pick. This blog post helps, but basically points out that there's no "perfect
replacement" for what SSL ciphers people tend to be using today. That said,
any attempt to avoid bad ciphers -- usually defaults -- is better than
nothing. Be careful: there are even valid SSL choices that don't encrypt your
data at all. Do your research when planning SSL and verify your SSL
configuration once you've selected server-side preferred options. It really
does matter.

[http://security.stackexchange.com/](http://security.stackexchange.com/) is
useful too, though not as fresh as many security blogs might be.

~~~
ivanr
For specific advice, here's my blog post with a proposed configuration that
will work with any program that relies on OpenSSL:

    
    
        http://blog.ivanristic.com/2013/08/configuring-apache-nginx-and-openssl-for-forward-secrecy.html
    

But I've found in practice that many operate under different circumstances.
For example, many hardware devices offer only a limited set of cipher suites.
To know how to configure them, you have to understand the advantages and
limitations of each.

That's why I keep the SSL/TLS Deployment Best Practices higher level, without
specific cipher suite configuration examples:

    
    
        https://www.ssllabs.com/projects/best-practices/

~~~
bradleyjg
In the blog post above you say that IE 8 on XP doesn't support PFS, but this
technet document seems to indicate that a few cipher suites with DHE are
available on XP: [http://msdn.microsoft.com/en-
us/library/windows/desktop/aa38...](http://msdn.microsoft.com/en-
us/library/windows/desktop/aa380512\(v=vs.85\).aspx)

Are all of them problematic for other reasons?

Thanks for all your work in this area!

~~~
ivanr
Yes, they are problematic. Cipher suites are typically tied to a particular
key algorithm. Microsoft does support the DHE key exchange, but only in
combination with DSA keys (DSS in the cipher suite string). There are a couple
of problems with that. First, if you do use DSA keys, you don't get to use any
RSA suites[1], which are much better supported. Just as an illustration Chrome
supports only one DSA suite. Second, virtually no one uses DSA keys today for
SSL. So, all the advice you will find is about RSA keys. Third, and worst,
Microsoft does not actually support DSA keys stronger than 1024 bits, and you
can't use 1024-bit keys because they're considered too weak.

I am sure there is a reason, but Microsoft never supported the DHE and RSA
combination, which was the only way to achieve Forward Secrecy before ECDHE
became widely supported.

[1] Actually, some web servers support multiple keys/certificates. With
Apache, for example, you could have an SSL site with RSA, DSA, and ECDSA keys
if you wanted. I think nginx is adding this capability too. But IIS does not
support it.

------
ck2
It's probably not complete fantasy to believe somewhere in the billion dollar
funded NSA machine, they have cracked RC4

Despite beast, I've disabled it completely and gone to AES with EC ciphers.

