diff options
author | Dr. Stephen Henson <steve@openssl.org> | 2009-12-09 18:17:21 +0000 |
---|---|---|
committer | Dr. Stephen Henson <steve@openssl.org> | 2009-12-09 18:17:21 +0000 |
commit | 7a8a3ef4f699d1857f0896f0a6b69cc4626f43cb (patch) | |
tree | 504ad365a4f39aecc3214dbf4890d68dbf338678 /doc | |
parent | 98c7b0367d94f7c18f6cc77c4ce9453f2675b842 (diff) |
clarify docs
Diffstat (limited to 'doc')
-rw-r--r-- | doc/ssl/SSL_CTX_set_options.pod | 19 |
1 files 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<SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION> 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. |