Re: [tlug] Good Overview Of What Is Still Secure?

["Nikolay Elenkov" <nick@example.com>]

Darren Cook writes:

>
> I spent some time yesterday working through these; also the slashdot
> thread [1].
> I got a good idea, but the dust on the conclusions hasn't settled yet
> (e.g. the imperialviolet page says how much better ECDHE is than DHE,
> but the "EC" is the elliptic curves that hackers might have a compromise
> for).

That one was published before the whole affair become public. ECDHE is
much faster, yes, but currently used curves might be problematic.
If the curves are changed it should still be OK to use. Most probably
you can't do this with a config switch right now, new versions of
OpenSSL, etc. will be needed.

>
> [1]:
> http://yro.slashdot.org/story/13/09/05/1951204/nsa-foils-much-internet-encryption
> (I found this useful for pointing out that the CAs don't get the private
> keys, it is all kept browser-side, and also that a man-in-the-middle
> attack would be too easily noticed.)
>

CA's might issue intermediate certificates (and some have) that would
allow anyone to decrypt traffic. Some commercial devices even offer this
as a selling point. It's not really all that easy to notice, and most
people never look past the padlock/green address bar. The certificate CN
is the same as the original, e.g., 'CN=google.com', that is why the
browser won't issue a warning. It is only the issuer that is different,
but how often have you checked who issued the site certificate when
connecting to Gmail? There are standards proposed to deal with this,
e.g. certificate transparency, but not widely adopted yet. Chrome pins
all Google properties, and some of the more popular sites (PayPal, etc.),
so if you use a recent version of Chrome, you should be relative safe
against MiTM. They probably don't pin Rakuten though....

If your server is hosted on any machine that you don't physically own,
and it uses SSL with RSA for key exchange, RSA keys can be leaked
or simply handed by your hosting provider. This allows whoever has
it to decrypt past sessions (you can try it yourself using Wireshark).
That is the problem that forward secrecy aims to solve. If you are
running a MiTM though, you can force most browsers to downgrade
as far back as SSL3, and if your server allows it, well...

See this for more practical advice about setting up Apache:

http://blog.ivanristic.com/2013/06/ssl-labs-deploying-forward-secrecy.html
http://blog.ivanristic.com/2013/08/configuring-apache-nginx-and-openssl-for-forward-secrecy.html
http://blog.ivanristic.com/2013/08/increasing-dhe-strength-on-apache.html

And, of course, there's  BREACH, so TLS doesn't look too good
nowadays, unless you are using TLS 1.2 with GCM (see above blog for
more details).