Secure Renegotiation will allow for a server to differentiate between an initial connection and a renegotiation, protecting against “man-in-the-middle” attacks during renegotiations. “Secure Socket Layer (SSL) and Transport Layer Security (TLS) renegotiation are vulnerable to an attack in which the attacker forms a TLS connection with the target server, injects content of his choice, and then splices in a new TLS connection from a client. The server treats the clients initial TLS handshake as a renegotiation and thus believes that the initial data transmitted by the attacker is from the same entity as the subsequent client data. This specification defines a TLS extension to cryptographically tie renegotiations to the TLS connections they are being performed over, thus preventing this attack.” -Abstract [RFC-5746](https://tools.ietf.org/html/rfc5746) - We will have an alpha release available for testing in November or December. Interested parties should contact us at [facts@wolfssl.com](mailto:facts@wolfssl.com)- Although were adding Secure Renegotiation to wolfSSL, we discourage its use when not a strict requirement.-Initially wolfSSL did not support Renegotiation as it was considered an insecure feature. As such there was no need to support Secure Renegotiation until there was a customer demand for it.-We make it a priority to ensure our clients have all the necessary tools at their disposal. Therefore we are adding support for Secure Renegotiation for those users and customers where it is a strict requirement.ReferencesInternet Engineering Task Force, RFC-5746