From 7a8a3ef4f699d1857f0896f0a6b69cc4626f43cb Mon Sep 17 00:00:00 2001 From: "Dr. Stephen Henson" Date: Wed, 9 Dec 2009 18:17:21 +0000 Subject: [PATCH] clarify docs --- doc/ssl/SSL_CTX_set_options.pod | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/doc/ssl/SSL_CTX_set_options.pod b/doc/ssl/SSL_CTX_set_options.pod index 2a324da374..c1df5af413 100644 --- a/doc/ssl/SSL_CTX_set_options.pod +++ b/doc/ssl/SSL_CTX_set_options.pod @@ -2,7 +2,7 @@ =head1 NAME -SSL_CTX_set_options, SSL_set_options, SSL_CTX_get_options, SSL_get_options - manipulate SSL options +SSL_CTX_set_options, SSL_set_options, SSL_CTX_clear_options, SSL_clear_options, SSL_CTX_get_options, SSL_get_options, SSL_get_secure_renegotiation_support - manipulate SSL options =head1 SYNOPSIS @@ -234,7 +234,7 @@ this option =head1 SECURE RENEGOTIATION -OpenSSL by 0.9.8m and later always attempts to use secure renegotiation as +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 a prefix attack described in the draft and elsewhere (FIXME: need full reference). @@ -255,13 +255,14 @@ then the connection will fail because it is not possible to determine whether an attack is taking place. If the option B is set then the -renegotiation between unpatched clients and patched servers is permitted as -well as initial connections and renegotiation between patched clients and -unpatched servers. This option should be used with caution because it leaves -both clients and servers vulnerable. However unpatched servers and clients are -likely to be around for some time and simply refusing to connect to unpatched -servers may well be considered unacceptable. So applications may be forced to -use this option for the immediate future. +above restrictions are relaxed. Renegotiation is permissible and initial +initial connections to unpatched servers will succeed. + +This option should be used with caution because it leaves both clients and +servers vulnerable. However unpatched servers and clients are likely to be +around for some time and refusing to connect to unpatched servers or denying +renegotion altogether may be unacceptable. So applications may be forced to +tolerate unsafe renegotiation for the immediate future. The function SSL_get_secure_renegotiation_support() indicates whether the peer supports secure renegotiation. -- 2.25.1