diff options
| author | Dr. Stephen Henson <steve@openssl.org> | 2009-12-09 18:16:50 +0000 |
|---|---|---|
| committer | Dr. Stephen Henson <steve@openssl.org> | 2009-12-09 18:16:50 +0000 |
| commit | b5c002d5a81ed659ffab3d1ab40e38d863951681 (patch) | |
| tree | c43c5f10e4c9f2e0ae1a059bcad02b046ef85a62 | |
| parent | 4db82571ba7849b7865a237c85cb9107ef2d51a9 (diff) | |
clarify docs
| -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 e5837819dc..825a6ad9ae 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 @@ -233,7 +233,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). @@ -254,13 +254,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. |