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 client`s 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
– We will have an alpha release available for testing in November or December. Interested parties should contact us at firstname.lastname@example.org
– Although we`re 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.