However, ECDHE cipher suites are not vulnerable to this particular attack. I understand that secure renegotiation is not supportedĬurrently due to the 'triple handshake attack' which is a valid concern. Hidden problem that can surface much later.Īlternatively, the problem could be addressed by actually implementing secure Not providing theĮxtension runs the risk that some servers will reject the connection, but Iįeel it is better to hit the issue early and directly rather than having a That the client will not support secure renegotation. Providing a renegotiation_info extension) where it makes it clear to the server Instead, I propose that the golang client implement the second bullet (i.e. The session aborts at the time of renegotiation. Secure renegotiation is not actually supported in the client, the potential forĪ confusing situation exists: the handshake is initiated, but sometime later It appears this golang client is implementing the first bullet, but since

Instead of continuing see Section 4.3 for discussion.

In this case, some servers may want to terminate the handshake 'renegotiation_info' extension was included, set the secure_renegotiation flag * If neither the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV nor the 'renegotiated_connection' field is zero, and if it is not, MUST abort the The server MUST then verify that the length of the If the extension is present, set secure_renegotiation flag to There is a screenshot of the ClientHelloĪccording to RFC 5746 ( ): * The server MUST check if the 'renegotiation_info' extension is included in theĬlientHello.

The pcap file demonstrates that the Client provides the 'renegotiation_info'Įxtension in the ClientHello. The route requiring a client certificate. Globally and SSLVerif圜lient is only required for a particular route, golangĬrypto/tls Conn will trigger a no renegotiation alert when transitioning into This example illustrates that with a server configuration where SSL is enabled

Wireshark https crt