Tighten SSL_OP_LEGACY_SERVER_CONNECT to align with RFC 5746.
RFC 5746 forbids a server from downgrading or upgrading
renegotiation_info support. Even with SSL_OP_LEGACY_SERVER_CONNECT set
(the default), we can still enforce a few things.
I do not believe this has practical consequences. The attack variant
where the server half is prefixed does not involve a renegotiation on
the client. The converse where the client sees the renegotiation and
prefix does, but we only support renego for the mid-stream HTTP/1.1
client auth hack, which doesn't do this. (And with triple-handshake,
HTTPS clients should be requiring the certificate be unchanged across
renego which makes this moot.)
Ultimately, an application which makes the mistake of using
renegotiation needs to be aware of what exactly that means and how to
handle connection state changing mid-stream. We make renego opt-in now,
so this is a tenable requirement.
(Also the legacy -> secure direction would have been caught by the
server anyway since we send a non-empty RI extension.)
Reviewed-by: Adam Langley <email@example.com>
diff --git a/ssl/test/runner/common.go b/ssl/test/runner/common.go
index 4ac2341..143b0e0 100644
@@ -579,10 +579,18 @@
// renegotiation handshake to be incorrect.
- // NoRenegotiationInfo causes the client to behave as if it
- // didn't support the renegotiation info extension.
+ // NoRenegotiationInfo disables renegotiation info support in all
+ // handshakes.
+ // NoRenegotiationInfoInInitial disables renegotiation info support in
+ // the initial handshake.
+ NoRenegotiationInfoInInitial bool
+ // NoRenegotiationInfoAfterInitial disables renegotiation info support
+ // in renegotiation handshakes.
+ NoRenegotiationInfoAfterInitial bool
// RequireRenegotiationInfo, if true, causes the client to return an
// error if the server doesn't reply with the renegotiation extension.