How to botch TLS forward secrecy

So posts about what you can screw up are nice, but what would be nicer is posts about how to set up an ideal SSL configuration for various web servers. (Perhaps there&#x27;s no &quot;perfect&quot; configuration possible, but &quot;strongest given known limitations&quot; would be fine too.)<p>With all the talk of PFS lately I&#x27;ve been trying to configure Apache to do it, but either I&#x27;m dumber than I thought or there&#x27;s no straightforward how-to online at the moment.<p>Instead of telling us the various crazy pitfalls and edge cases, just give dummies like me the best possible formula so we can configure things securely and then get on with our lives. The first step towards defeating eavesdropping is making the best possible SSL configuration a copy and paste affair instead of an acronym guessing game.<p>Edit: If total security isn&#x27;t really possible right now as this post suggests, maybe a &quot;best&quot; configuration plus mailing list for when it&#x27;s updated for varios major platforms (ie LTS) would be a good stopgap.

The only purpose of session resumption is performance, right? I thought someone published a report recently that real-world servers don&#x27;t get enough successfully resumed sessions for it to even be worthwhile, particularly in a world with crypto hardware, SPDY and HTTP keepalive.<p>Wouldn&#x27;t it be easier to just disable TLS resume than to figure out how to do it right?<p>edit: It was another agl article, <a href="https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html" rel="nofollow">https:&#x2F;&#x2F;www.imperialviolet.org&#x2F;2010&#x2F;06&#x2F;25&#x2F;overclocking-ssl.h...</a>:<p><pre><code> Since the session information contains key material, it&#x27;s never cached on disk so the attempted client resume rate, seen by Google, is only 50%.</code></pre>

&gt; Ideally the DH group would match or exceed the RSA key size but 1024-bit DHE is arguably better than straight 2048-bit RSA<p>So let&#x27;s argue!<p>It depends on how you presume the attacker is gonna get you. Suppose the attacker is well-funded enough to go after one RSA-1024 or DH-1024 instance. Unlike RSA, however, DHE tends to work modulo the same prime over and over. This has consequences for cryptanalysis: once the attacker has solved a single DH instance, they can solve the next one much faster [2]. In the case of 1024-bit DH, the subsequent instances can be solved in about 2^55 time (versus about 2^80 for the first log); this is not instant, but it&#x27;s pretty quick for a well-funded and skilled attacker.<p>Where 1024-bit DHE does shine versus 2048-bit static RSA is against other, less Hollywood, types of key retrieval such as outright hacking.<p>[1] <a href="https://tools.ietf.org/html/rfc2409#page-22" rel="nofollow">https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;rfc2409#page-22</a><p>[2] <a href="http://www.iacr.org/archive/pkc2006/39580175/39580175.pdf" rel="nofollow">http:&#x2F;&#x2F;www.iacr.org&#x2F;archive&#x2F;pkc2006&#x2F;39580175&#x2F;39580175.pdf</a>

The recent discussions of SSL&#x2F;TLS on the server made me wonder about client configuration. I looked around for a SSL Labs like tool for browser and asked on security.SX[1] but I was unable to find anything comparable which was troubling.<p>Am I missing something to think that an SSL Labs like tool for the client is also important? Does anyone have any recommendations?<p>[1] <a href="http://security.stackexchange.com/q/38084/4564" rel="nofollow">http:&#x2F;&#x2F;security.stackexchange.com&#x2F;q&#x2F;38084&#x2F;4564</a>

Perhaps someone ought to add session ticket support to OpenSSL for using some of the latest fast in memory-only databases.<p>If I were a company which made such a database, I&#x27;d think that kind of project would give me very good exposure.

How to configure Apache to use stronger than 1024 bit DHE? Like group 14.

So if Google enables forward secrecy for Google searches, would that mean every single Google search would be encrypted with a new key, or only the &quot;open session&quot;? Would encrypting every search be possible with <i>perfect</i> forward secrecy [1]? And if so, can&#x27;t we get that for TLS 1.3, too?<p>[1] <a href="http://en.wikipedia.org/wiki/Perfect_forward_secrecy" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Perfect_forward_secrecy</a>