Hacker News new | ask | show | jobs
by tptacek 3184 days ago
The 'P' in 'PFS' has always stretched the truth, which is why a lot of practitioners elide it.

Even if you never rotate STEKs and never reset systems to get a new STEK accidentally, the DH handshake is still providing forward secrecy value for clients who don't do session tickets.

1 comments

Do such clients actually exist in mainstream usage? The one crypto bug which you are actually protected from by using IE on Win7!
I don't know, but the cost that session tickets are saving are almost entirely an externality to clients, and the privacy benefit of not honoring tickets isn't, so there would seem to be some value to a Chrome extension that busted that cache.
Yeah but it's not the client sending the resumption ticket but sending the capability in the ClientHello which exposes the session key under a possibly fixed key. So you can't fix this by busting the client cache I think. You need the capability flag off.

Even so could an active adversary turn on the capability in the ClientHello and still get a chance to see the STEK encrypted session key even against legacy (or intentionally ticket-disabled) clients? This I don't know - would a client just drop the ticket message and proceed or would it abort? But at least it would have to be an active attacker.

Yep, this got pointed out to me several times on Slack. Session tickets suck.