summaryrefslogtreecommitdiffstats
path: root/doc
diff options
context:
space:
mode:
authorMatt Caswell <matt@openssl.org>2016-10-27 10:46:25 +0100
committerMatt Caswell <matt@openssl.org>2016-11-07 16:05:11 +0000
commit929cc3fa6bceba1c6d9c362c56b89cbf2acf40bc (patch)
tree9b76d44e6a61be0361aabd91bc7ab2f9bc127eea /doc
parent992b3740a1f7b24771ccf29a52b0141c51b95933 (diff)
Partial revert of "Fix client verify mode to check SSL_VERIFY_PEER"
This partially reverts commit c636c1c47. It also tweaks the documentation and comments in this area. On the client side the documented interface for SSL_CTX_set_verify()/SSL_set_verify() is that setting the flag SSL_VERIFY_PEER causes verfication of the server certificate to take place. Previously what was implemented was that if *any* flag was set then verification would take place. The above commit improved the semantics to be as per the documented interface. However, we have had a report of at least one application where an application was incorrectly using the interface and used *only* SSL_VERIFY_FAIL_IF_NO_PEER_CERT on the client side. In OpenSSL prior to the above commit this still caused verification of the server certificate to take place. After this commit the application silently failed to verify the server certificate. Ideally SSL_CTX_set_verify()/SSL_set_verify() could be modified to indicate if invalid flags were being used. However these are void functions! The simplest short term solution is to revert to the previous behaviour which at least means we "fail closed" rather than "fail open". Thanks to Cory Benfield for reporting this issue. Reviewed-by: Richard Levitte <levitte@openssl.org> (cherry picked from commit c8e2f98c97ff3327784843946c2d62761572e5d5)
Diffstat (limited to 'doc')
-rw-r--r--doc/ssl/SSL_CTX_set_verify.pod7
1 files changed, 7 insertions, 0 deletions
diff --git a/doc/ssl/SSL_CTX_set_verify.pod b/doc/ssl/SSL_CTX_set_verify.pod
index 96a98acaac..d2d3d03a89 100644
--- a/doc/ssl/SSL_CTX_set_verify.pod
+++ b/doc/ssl/SSL_CTX_set_verify.pod
@@ -145,6 +145,13 @@ Its return value is identical to B<preverify_ok>, so that any verification
failure will lead to a termination of the TLS/SSL handshake with an
alert message, if SSL_VERIFY_PEER is set.
+=head1 BUGS
+
+In client mode, it is not checked whether the SSL_VERIFY_PEER flag
+is set, but whether any flags are set. This can lead to
+unexpected behaviour if SSL_VERIFY_PEER and other flags are not used as
+required.
+
=head1 RETURN VALUES
The SSL*_set_verify*() functions do not provide diagnostic information.