Issue metadata
Sign in to add a comment
|
Forbid renegotiations without the renegotiation_info extension |
||||||||||||||||||
Issue descriptionIt's been 8 years. Surely that's long enough... I think there are enough stacks that don't bother implemention either renego or renegotiation_info that we probably can't straight-up mandate it, but blocking renegos if you don't have the extension seems plausible. I'm going to get some metrics. (Since renego is largely an enterprise thing, it's possible this will come up inconclusive, but we can see.)
,
Jun 13 2018
,
Aug 20
AGL points out that I'm misunderstanding the renegotiation attack. The more interesting attack is: Attacker -> Server: handshake Attacker -> Server: app data Client -> Server: handshake, but attacker intercepts Attacker -> Server: proxy the above handshake Client thinks it's doing an initial handshake. Server thinks it's a renegotiation and that, in particular, the attacker-supplied prefix is part of the stream. To avoid this you either need the server to reject RI-less renegotiations or for the client to reject *all* RI-less connections. Thus there's not much the client can do short of full enforcement. If full enforcement is impractical, having the client reject RI-less renegotiations doesn't actually stop the attack. It merely nudges RI-less renegotiating servers to implement RI, which is valuable, but opportunistic RI is insufficient. The server must reject RI-less renegotiation altogether, and that one we can't as easily induce on the client. It may be worth getting some data again on whether full enforcement is plausible. I recall it wasn't a while ago.
,
Oct 1
The NextAction date has arrived: 2018-10-01 |
|||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||
Comment 1 by bugdroid1@chromium.org
, Jun 12 2018