8 ms·
There’s no way to guarantee forward secrecy to a client. If regular TLS promises that, the committee is lying and they know it.
by kabwj 8y ago
There’s no way to guarantee forward secrecy to a client. If regular TLS promises that, the committee is lying and they know it.
- zrm 8y agoThere are constructions that provide forward secrecy when both the client and server follow them. This is what TLS aims to provide. If the server doesn't faithfully implement the protocol, of course it will not provide the expected security guarantees. But then it isn't the committee who is lying, it's the server by claiming to implement TLS and then not.
- zaroth 8y agoForward secrecy is mostly a myth anyway when the “ephemeral” keys used to generate the session are kept in memory for weeks, months, or years already (e.g. HAProxy)
- Dylan16807 8y agoSure, if you want to pretend that an easily-fixed bug makes security a myth.
- zaroth 8y agoIt doesn't matter how easy the bug is to fix, if 90 out of 100 sites don't fix it. In this case it's less of a bug than it is a thorn, because rotating the keys requires knowing when they can actually expire, which requires state that the process holding the keys usually doesn't carry. But my point was more along the lines that PFS was never a guaranteed contract with the client, only a possibility offered by certain key exchange protocols, and even then, easy enough to get wrong that most people did.