This is BoringSSL's interpretation as well. We don't support renegotiation on the server at all, but our server still implements the renegotiation_info extension in the degenerate case for the initial handshake. It is vacuously true that all renegotiations we'll perform on that connection are secure. :-)
I believe the Go TLS stack has the same behavior. On Wed, Jun 13, 2018 at 4:03 PM Martin Thomson <[email protected]> wrote: > Hi Rich, > > I think that the Qualys interpretation might be safer. That is, you > probably should send R-I always. See Karthik's response to my > suggestion that it might be OK to omit R-I in some cases: > > https://mailarchive.ietf.org/arch/msg/tls/TfiUa3M390augtvUoxH2D7L5LGM > On Wed, Jun 13, 2018 at 12:47 PM Salz, Rich > <[email protected]> wrote: > > > > It seems that the semantics of the "renegotiation_info" extension are > slightly muddy. Qualys understands it to mean that the server will not > perform insecure renegotiation, full stop. But OpenSSL further understands > it to mean that the server *will* perform secure negotiation. OpenSSL > therefore makes it difficult to simultaneously simultaneously satisfy both > of Qualys's expectations, since disabling all renegotiation will cause it > not to send the "renegotiation_info" extension. Popular open source web > servers implement a workaround which achieves Qualys's desired behavior. > Comments? > > > > _______________________________________________ > > TLS mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
