diff options
author | Dr. Stephen Henson <steve@openssl.org> | 2010-02-12 21:59:31 +0000 |
---|---|---|
committer | Dr. Stephen Henson <steve@openssl.org> | 2010-02-12 21:59:31 +0000 |
commit | f9595988665e86018cdbd76d8f0edb2d9a44bcb1 (patch) | |
tree | f2674bbb4e3981f66cbce6fe72801b1fab4401ba | |
parent | 5a9e3f05ff287a76fa6cd344fb42fc69be5f0cd8 (diff) |
update references to new RI RFC
-rw-r--r-- | CHANGES | 23 | ||||
-rw-r--r-- | NEWS | 2 | ||||
-rw-r--r-- | doc/ssl/SSL_CTX_set_options.pod | 4 |
3 files changed, 14 insertions, 15 deletions
@@ -929,14 +929,14 @@ [Steve Henson] *) If client attempts to renegotiate and doesn't support RI respond with - a no_renegotiation alert as required by draft-ietf-tls-renegotiation. - Some renegotiating TLS clients will continue a connection gracefully - when they receive the alert. Unfortunately OpenSSL mishandled - this alert and would hang waiting for a server hello which it will never - receive. Now we treat a received no_renegotiation alert as a fatal - error. This is because applications requesting a renegotiation might well - expect it to succeed and would have no code in place to handle the server - denying it so the only safe thing to do is to terminate the connection. + a no_renegotiation alert as required by RFC5746. Some renegotiating + TLS clients will continue a connection gracefully when they receive + the alert. Unfortunately OpenSSL mishandled this alert and would hang + waiting for a server hello which it will never receive. Now we treat a + received no_renegotiation alert as a fatal error. This is because + applications requesting a renegotiation might well expect it to succeed + and would have no code in place to handle the server denying it so the + only safe thing to do is to terminate the connection. [Steve Henson] *) Add ctrl macro SSL_get_secure_renegotiation_support() which returns 1 if @@ -948,10 +948,9 @@ the updated NID creation version. This should correctly handle UTF8. [Steve Henson] - *) Implement draft-ietf-tls-renegotiation-03. Re-enable - renegotiation but require the extension as needed. Unfortunately, - SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION turns out to be a - bad idea. It has been replaced by + *) Implement RFC5746. Re-enable renegotiation but require the extension + as needed. Unfortunately, SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION + turns out to be a bad idea. It has been replaced by SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION which can be set with SSL_CTX_set_options(). This is really not recommended unless you know what you are doing. @@ -7,7 +7,7 @@ Major changes between OpenSSL 0.9.8l and OpenSSL 1.0: - o Support for draft-ietf-tls-renegotiation-03.txt + o Support for RFC5746 TLS renegotiation extension. o RFC3280 path validation: sufficient to process PKITS tests. o Integrated support for PVK files and keyblobs. o Change default private key format to PKCS#8. diff --git a/doc/ssl/SSL_CTX_set_options.pod b/doc/ssl/SSL_CTX_set_options.pod index a878a6af6d..3e61a36e17 100644 --- a/doc/ssl/SSL_CTX_set_options.pod +++ b/doc/ssl/SSL_CTX_set_options.pod @@ -234,8 +234,8 @@ these options. =head1 SECURE RENEGOTIATION OpenSSL 0.9.8m and later always attempts to use secure renegotiation as -described in draft-ietf-tls-renegotiation (FIXME: replace by RFC). This -counters the prefix attack described in CVE-2009-3555 and elsewhere. +described in RFC5746. This counters the prefix attack described in +CVE-2009-3555 and elsewhere. The deprecated and highly broken SSLv2 protocol does not support secure renegotiation at all: its use is B<strongly> discouraged. |