This article details deploying forward secrecy. https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy
On Thu, Jul 25, 2013 at 5:54 AM, Tom Ritter <[email protected]> wrote: > On 25 July 2013 06:41, Ben Laurie <[email protected]> wrote: > > What helps here is perfect forward secrecy. > > Only so long as the exact same web companies can _also_ justify not > giving up the secrets on the backend. IANAL obviously, but as we saw > in the compelled encryption keys for hard drives, the government chose > the very intelligent tact of not demanding the key, but rather access > to the decrypted content. If this was argued in court, and they made > the same argument, ant the government won... well, it might make PFS > useless too. (The company choosing to either not use PFS so they > don't have to modify their SSL terminators, or making the modification > and handing the premaster secret over). I, personally, would not > feel confident in PFS keeping the government out of the SSL stream if > I suspected the SSL keys were being handed over. > > > BTW, better alternative to Convergence: Certificate Transparency - > > http://tools.ietf.org/html/rfc6962. > > Only in an architectural sense - in a year we might have Chrome > enforcing CT for specific CAs, and in a couple of years to ten years, > we might have CT applying to all CAs in a trust store*. You can use > Convergence today. > > -tom > > * This is obviously wild speculation about plans from someone who has > no idea what Chrome is planning, talking to someone who does, but > probably can't talk about it publicly yet. > -- > Too many emails? Unsubscribe, change to digest, or change password by > emailing moderator at [email protected] or changing your settings at > https://mailman.stanford.edu/mailman/listinfo/liberationtech >
-- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at [email protected] or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
