summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorbeck <>2023-05-29 11:14:19 +0000
committerbeck <>2023-05-29 11:14:19 +0000
commit26e7d501966e054b9e377033e8b93db0c4e42412 (patch)
treed2d5bcf70733359711fde87d19feb33c49da197f
parente074f5c2c19e5324112455428b2f4b66b012e9a6 (diff)
downloadopenbsd-26e7d501966e054b9e377033e8b93db0c4e42412.tar.gz
openbsd-26e7d501966e054b9e377033e8b93db0c4e42412.tar.bz2
openbsd-26e7d501966e054b9e377033e8b93db0c4e42412.zip
Stop suggesting that children play with loaded revolvers.
This takes much of the language that boring uses to document the verify callback, and corrects the historical horror that OpenSSL introduced years ago by suggesting people ignore expiry dates using the callback instead of the verify flags. nits by jsg@ and tb@ ok tb@
-rw-r--r--src/lib/libcrypto/man/X509_STORE_CTX_set_verify_cb.380
1 files changed, 49 insertions, 31 deletions
diff --git a/src/lib/libcrypto/man/X509_STORE_CTX_set_verify_cb.3 b/src/lib/libcrypto/man/X509_STORE_CTX_set_verify_cb.3
index 9ae3d0294a..0e026a7b29 100644
--- a/src/lib/libcrypto/man/X509_STORE_CTX_set_verify_cb.3
+++ b/src/lib/libcrypto/man/X509_STORE_CTX_set_verify_cb.3
@@ -1,4 +1,4 @@
1.\" $OpenBSD: X509_STORE_CTX_set_verify_cb.3,v 1.9 2022/11/16 14:51:08 schwarze Exp $ 1.\" $OpenBSD: X509_STORE_CTX_set_verify_cb.3,v 1.10 2023/05/29 11:14:19 beck Exp $
2.\" full merge up to: OpenSSL aebb9aac Jul 19 09:27:53 2016 -0400 2.\" full merge up to: OpenSSL aebb9aac Jul 19 09:27:53 2016 -0400
3.\" selective merge up to: OpenSSL 24a535ea Sep 22 13:14:20 2020 +0100 3.\" selective merge up to: OpenSSL 24a535ea Sep 22 13:14:20 2020 +0100
4.\" 4.\"
@@ -66,7 +66,7 @@
66.\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED 66.\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
67.\" OF THE POSSIBILITY OF SUCH DAMAGE. 67.\" OF THE POSSIBILITY OF SUCH DAMAGE.
68.\" 68.\"
69.Dd $Mdocdate: November 16 2022 $ 69.Dd $Mdocdate: May 29 2023 $
70.Dt X509_STORE_CTX_SET_VERIFY_CB 3 70.Dt X509_STORE_CTX_SET_VERIFY_CB 3
71.Os 71.Os
72.Sh NAME 72.Sh NAME
@@ -98,13 +98,29 @@ to
98.Fa verify_cb 98.Fa verify_cb
99overwriting any existing callback. 99overwriting any existing callback.
100.Pp 100.Pp
101The verification callback can be used to customise the operation of 101The verification callback can be used to modify the operation of
102certificate verification, either by overriding error conditions or 102certificate verification, either by overriding error conditions or
103logging errors for debugging purposes. 103logging errors for debugging purposes.
104The use of a verification callback is not essential, and should not
105be used in security sensitive programs.
104.Pp 106.Pp
105However, a verification callback is 107Do not use this function.
106.Em not 108It is extremely fragile and unpredictable.
107essential and the default operation is often sufficient. 109This callback exposes implementation details of certificate verification,
110which change as the library evolves.
111Attempting to use it for security checks can introduce vulnerabilities if
112making incorrect assumptions about when the callback is called.
113Additionally, overriding
114.Fa ok
115may leave
116Fa ctx
117in an inconsistent state and break invariants.
118.Pp
119Instead, customize certificate verification by configuring options on the
120.Vt X509_STORE_CTX
121before verification, or applying additional checks after
122.Xr X509_verify_cert 3
123completes successfully.
108.Pp 124.Pp
109The 125The
110.Fa ok 126.Fa ok
@@ -112,6 +128,10 @@ parameter to the callback indicates the value the callback should return
112to retain the default behaviour. 128to retain the default behaviour.
113If it is zero then an error condition is indicated. 129If it is zero then an error condition is indicated.
114If it is 1 then no error occurred. 130If it is 1 then no error occurred.
131As the default behaviour is internal to the verifier, and possibly unknown
132to the caller, changing this parameter is inherently dangerous and should not
133normally be done except for debugging purposes, and should not be expected to
134be consistent if the verifier changes.
115If the flag 135If the flag
116.Dv X509_V_FLAG_NOTIFY_POLICY 136.Dv X509_V_FLAG_NOTIFY_POLICY
117is set, then 137is set, then
@@ -156,9 +176,11 @@ verify_callback(int ok, X509_STORE_CTX *ctx)
156{ 176{
157 return ok; 177 return ok;
158} 178}
179This is likely the only safe callback to use.
159.Ed 180.Ed
160.Pp 181.Pp
161Simple example, suppose a certificate in the chain is expired and we 182Simple and terrible example that you should not use:
183Suppose a certificate in the chain is expired and we
162wish to continue after this error: 184wish to continue after this error:
163.Bd -literal 185.Bd -literal
164int 186int
@@ -171,26 +193,17 @@ verify_callback(int ok, X509_STORE_CTX *ctx)
171 return ok; 193 return ok;
172} 194}
173.Ed 195.Ed
196While this example is presented for historical purposes,
197this is not the correct way to accomplish this.
198You should set verification options on the STORE_CTX to use
199.Vt X509_V_FLAG_NO_CHECK_TIME
200using
201.Xr X509_VERIFY_PARAM_set_flags 3
202instead.
174.Pp 203.Pp
175More complex example, we don't wish to continue after 204Full featured debugging logging callback - note that the output and
176.Sy any 205order that things happen from this can change over time and should not
177certificate has expired just one specific case: 206be parsed or expected to be consistent.
178.Bd -literal
179int
180verify_callback(int ok, X509_STORE_CTX *ctx)
181{
182 int err = X509_STORE_CTX_get_error(ctx);
183 X509 *err_cert = X509_STORE_CTX_get_current_cert(ctx);
184
185 if (err == X509_V_ERR_CERT_HAS_EXPIRED) {
186 if (check_is_acceptable_expired_cert(err_cert)
187 return 1;
188 }
189 return ok;
190}
191.Ed
192.Pp
193Full featured logging callback.
194In this case the 207In this case the
195.Fa bio_err 208.Fa bio_err
196is assumed to be a global logging 209is assumed to be a global logging
@@ -280,8 +293,13 @@ first appeared in OpenSSL 1.1.0 and has been available since
280.Sh CAVEATS 293.Sh CAVEATS
281In general a verification callback should 294In general a verification callback should
282.Sy NOT 295.Sy NOT
283unconditionally return 1 in all circumstances because this will allow 296return a changed value of
284verification to succeed no matter what the error. 297.Fa ok
285This effectively removes all security from the application because 298because this can allow the verification to appear to succeed
286.Sy any 299in an unpredictable way.
287certificate (including untrusted generated ones) will be accepted. 300This can effectively remove all security from the application because
301untrusted or invalid certificates may be accepted.
302Doing this can possibly make
303.Xr X509_verify_cert 3
304return what appears to be a validated chain of certificates that has not
305been validated or even had the signatures checked.