On Wed, Jun 13, 2018 at 07:47:11PM +0000, 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
