Re: [TLS] What does "renegotiation_info" mean?
Thanks for the replies; I put a summary in https://github.com/openssl/openssl/issues/6484 for OpenSSL (ooh, look, I got a DMARC work-around :) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] What does "renegotiation_info" mean?
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 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 > 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 > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] What does "renegotiation_info" mean?
On Wed, Jun 13, 2018 at 07:47:11PM +, Salz, Rich 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? Then there are the clients that justifiably immediately abort the handshake if TLS 1.2 server_hello lacks renegotiation_info. This is because unless client then tries to probe for renegoitiation, which it can not in practice do because all the servers that just fail to renegotiate correctly, it can not tell if it is under attack or not. Not responding to renegotiation_info in TLS 1.2 is a security issue, even if there is no renegotiation support. OpenSSL should be fixed to respond to it in TLS 1.0 to 1.2 _regardless_ of if renegotiation is enabled or not. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] What does "renegotiation_info" mean?
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 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
