I wrote a long blog post covering everything you ever wanted to know about Keyless SSLhttps://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/ …
-
-
Replying to @grittygrease
@grittygrease Good work. I am curious as to why the keyserver doesn't get to choose Serverhello.server_random.1 reply 0 retweets 0 likes -
Replying to @BRIAN_____
@BRIAN_____ This would require another roundtrip in the RSA case. It could be feasible in the DH case, though.3 replies 0 retweets 0 likes -
Replying to @grittygrease
@grittygrease In the RSA case, keyserver can batch send acceptable server_randoms to you, async. Guards against some interesting replays.2 replies 0 retweets 0 likes -
Replying to @BRIAN_____
@BRIAN_____ What's the threat model for these replay attacks?3 replies 0 retweets 0 likes -
Replying to @grittygrease
@grittygrease 2. Compromised PoP decrypting traffic from other PoPs' conns by replaying client_random and server_random from those conns.1 reply 0 retweets 0 likes -
Replying to @BRIAN_____
@BRIAN_____ Interesting, I see where you're going with this. More reasons to use forward-secret ciphersuites.1 reply 0 retweets 0 likes -
Replying to @grittygrease
@grittygrease Even in the (EC)DHE case, it would be best if the keyserver could send the (EC)DHE keypairs that each PoP uses, batch/async.1 reply 0 retweets 0 likes
@grittygrease To be clear, I mean "best" in the eyes of somebody that wants to trust the PoPs as little as possible; may be unrealistic.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.