Mailing List Archive
tlug.jp Mailing List tlug archive tlug Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [tlug] Good Overview Of What Is Still Secure?
- Date: Thu, 12 Sep 2013 10:56:10 +0900 (JST)
- From: "Nikolay Elenkov" <firstname.lastname@example.org>
- Subject: Re: [tlug] Good Overview Of What Is Still Secure?
- References: <522D26F5.email@example.com> <firstname.lastname@example.org> <email@example.com> <52310E3F.firstname.lastname@example.org>
- User-agent: SquirrelMail/1.4.8-2.el4.centos4
Darren Cook writes: > > I spent some time yesterday working through these; also the slashdot > thread . > 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. > > : > 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).
Home | Main Index | Thread Index
- Prev by Date: Re: [tlug] Good Overview Of What Is Still Secure?
- Next by Date: [tlug] linux mint KDE distribution
- Previous by thread: Re: [tlug] Good Overview Of What Is Still Secure?
- Next by thread: Re: [tlug] Good Overview Of What Is Still Secure?
Home Page Mailing List Linux and Japan TLUG Members Links