2 ms·

It's fantastic that Let's Encrypt made short(er)-lived certificates possible. With automation in place it doesn't matter if the cert lives a year or a week. Eve

by pornel 7y ago

It's fantastic that Let's Encrypt made short(er)-lived certificates possible. With automation in place it doesn't matter if the cert lives a year or a week. Eventually it will get short enough that we won't have to bother with revocation lists, OCSP, etc.

tialaramex 7y ago
In the medium term the intent here is Delegated Credentials. The TLS working group is putting the finishing touches on a mechanism which goes like this: You still have TLS certificates like today, but the private key corresponding to the public key in that certificate lives on a dedicated machine that's not accessible to the outside world, rather than your web server. This dedicated machine uses the private key to sign tiny messages which basically say "I, the owner of this TLS certificate you've seen, authorise this web server for a short period (say 24 hours) to prove its identity using a short-lived key which you can verify using public key P". Then your web servers serve up the TLS cert (for which they don't know the private key) this short message with P in it, and proof they do know their short-lived private key which can be verified using P. Browsers check the certificate, the delegated credential message and so on and you've got all the same security but with much shorter lived credentials. This way, when somebody finds a zero day in your tremendously complicated web site and uses it to steal the private key, that key is only valid for maximum 24 hours and so you can close their window of opportunity relatively swiftly if you're on top of it. Meanwhile the dedicated server for making the signed messages is not publicly accessible and can be simpler and thus more secure. This isn't really a way forward for making toy web sites with 1000 visitors per day, but if you're building anything where you already have multiple servers possibly in different locations then it's more interesting.

by pornel 7y ago

tialaramex 7y ago

In the medium term the intent here is Delegated Credentials. The TLS working group is putting the finishing touches on a mechanism which goes like this: You still have TLS certificates like today, but the private key corresponding to the public key in that certificate lives on a dedicated machine that's not accessible to the outside world, rather than your web server. This dedicated machine uses the private key to sign tiny messages which basically say "I, the owner of this TLS certificate you've seen, authorise this web server for a short period (say 24 hours) to prove its identity using a short-lived key which you can verify using public key P". Then your web servers serve up the TLS cert (for which they don't know the private key) this short message with P in it, and proof they do know their short-lived private key which can be verified using P. Browsers check the certificate, the delegated credential message and so on and you've got all the same security but with much shorter lived credentials. This way, when somebody finds a zero day in your tremendously complicated web site and uses it to steal the private key, that key is only valid for maximum 24 hours and so you can close their window of opportunity relatively swiftly if you're on top of it. Meanwhile the dedicated server for making the signed messages is not publicly accessible and can be simpler and thus more secure. This isn't really a way forward for making toy web sites with 1000 visitors per day, but if you're building anything where you already have multiple servers possibly in different locations then it's more interesting.