<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jan 13, 2015 at 3:30 PM, Andreas Junius <span dir="ltr"><<a href="mailto:andreas.junius@gmail.com" target="_blank">andreas.junius@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">So what I did was adding an additional level for encryption underneath SSL (all at application level for a start). My server has two certificates now; the SSL certificate for authentication and another one that serves as the servers own CA. The server uses this CA certificate to sign what I call an “encryption certificate”, that it delivers to the client. This “encryption certificate” gets generated by the application server on a regular basis. The interval can be set via parameter, depending on the security needs of the application, e.g. re-generate after 4 weeks or 2 weeks or even on every request/session.</blockquote><div><br></div><div>It sounds like you are homebrewing your own version of this:</div><div><br></div><div><a href="https://en.wikipedia.org/wiki/Forward_secrecy">https://en.wikipedia.org/wiki/Forward_secrecy</a></div><div><br></div><div>TLS can automatically generate ephemeral keys for encryption, while only using the long-lived key for signing the ephemeral keys. This decouples authentication from encryption, and ensures that every session is protected by a brand new set of public/private keys. </div></div><div><br></div><div>You will need to use e.g. an ECDHE ciphersuite for this to happen, however it's been built into TLS for awhile now...</div><div><br></div>-- <br><div class="gmail_signature">Tony Arcieri<br></div>
</div></div>