diff options
author | beck <> | 2023-05-29 11:14:19 +0000 |
---|---|---|
committer | beck <> | 2023-05-29 11:14:19 +0000 |
commit | 26e7d501966e054b9e377033e8b93db0c4e42412 (patch) | |
tree | d2d5bcf70733359711fde87d19feb33c49da197f | |
parent | e074f5c2c19e5324112455428b2f4b66b012e9a6 (diff) | |
download | openbsd-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.3 | 80 |
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 |
99 | overwriting any existing callback. | 99 | overwriting any existing callback. |
100 | .Pp | 100 | .Pp |
101 | The verification callback can be used to customise the operation of | 101 | The verification callback can be used to modify the operation of |
102 | certificate verification, either by overriding error conditions or | 102 | certificate verification, either by overriding error conditions or |
103 | logging errors for debugging purposes. | 103 | logging errors for debugging purposes. |
104 | The use of a verification callback is not essential, and should not | ||
105 | be used in security sensitive programs. | ||
104 | .Pp | 106 | .Pp |
105 | However, a verification callback is | 107 | Do not use this function. |
106 | .Em not | 108 | It is extremely fragile and unpredictable. |
107 | essential and the default operation is often sufficient. | 109 | This callback exposes implementation details of certificate verification, |
110 | which change as the library evolves. | ||
111 | Attempting to use it for security checks can introduce vulnerabilities if | ||
112 | making incorrect assumptions about when the callback is called. | ||
113 | Additionally, overriding | ||
114 | .Fa ok | ||
115 | may leave | ||
116 | Fa ctx | ||
117 | in an inconsistent state and break invariants. | ||
118 | .Pp | ||
119 | Instead, customize certificate verification by configuring options on the | ||
120 | .Vt X509_STORE_CTX | ||
121 | before verification, or applying additional checks after | ||
122 | .Xr X509_verify_cert 3 | ||
123 | completes successfully. | ||
108 | .Pp | 124 | .Pp |
109 | The | 125 | The |
110 | .Fa ok | 126 | .Fa ok |
@@ -112,6 +128,10 @@ parameter to the callback indicates the value the callback should return | |||
112 | to retain the default behaviour. | 128 | to retain the default behaviour. |
113 | If it is zero then an error condition is indicated. | 129 | If it is zero then an error condition is indicated. |
114 | If it is 1 then no error occurred. | 130 | If it is 1 then no error occurred. |
131 | As the default behaviour is internal to the verifier, and possibly unknown | ||
132 | to the caller, changing this parameter is inherently dangerous and should not | ||
133 | normally be done except for debugging purposes, and should not be expected to | ||
134 | be consistent if the verifier changes. | ||
115 | If the flag | 135 | If the flag |
116 | .Dv X509_V_FLAG_NOTIFY_POLICY | 136 | .Dv X509_V_FLAG_NOTIFY_POLICY |
117 | is set, then | 137 | is set, then |
@@ -156,9 +176,11 @@ verify_callback(int ok, X509_STORE_CTX *ctx) | |||
156 | { | 176 | { |
157 | return ok; | 177 | return ok; |
158 | } | 178 | } |
179 | This is likely the only safe callback to use. | ||
159 | .Ed | 180 | .Ed |
160 | .Pp | 181 | .Pp |
161 | Simple example, suppose a certificate in the chain is expired and we | 182 | Simple and terrible example that you should not use: |
183 | Suppose a certificate in the chain is expired and we | ||
162 | wish to continue after this error: | 184 | wish to continue after this error: |
163 | .Bd -literal | 185 | .Bd -literal |
164 | int | 186 | int |
@@ -171,26 +193,17 @@ verify_callback(int ok, X509_STORE_CTX *ctx) | |||
171 | return ok; | 193 | return ok; |
172 | } | 194 | } |
173 | .Ed | 195 | .Ed |
196 | While this example is presented for historical purposes, | ||
197 | this is not the correct way to accomplish this. | ||
198 | You should set verification options on the STORE_CTX to use | ||
199 | .Vt X509_V_FLAG_NO_CHECK_TIME | ||
200 | using | ||
201 | .Xr X509_VERIFY_PARAM_set_flags 3 | ||
202 | instead. | ||
174 | .Pp | 203 | .Pp |
175 | More complex example, we don't wish to continue after | 204 | Full featured debugging logging callback - note that the output and |
176 | .Sy any | 205 | order that things happen from this can change over time and should not |
177 | certificate has expired just one specific case: | 206 | be parsed or expected to be consistent. |
178 | .Bd -literal | ||
179 | int | ||
180 | verify_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 | ||
193 | Full featured logging callback. | ||
194 | In this case the | 207 | In this case the |
195 | .Fa bio_err | 208 | .Fa bio_err |
196 | is assumed to be a global logging | 209 | is 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 |
281 | In general a verification callback should | 294 | In general a verification callback should |
282 | .Sy NOT | 295 | .Sy NOT |
283 | unconditionally return 1 in all circumstances because this will allow | 296 | return a changed value of |
284 | verification to succeed no matter what the error. | 297 | .Fa ok |
285 | This effectively removes all security from the application because | 298 | because this can allow the verification to appear to succeed |
286 | .Sy any | 299 | in an unpredictable way. |
287 | certificate (including untrusted generated ones) will be accepted. | 300 | This can effectively remove all security from the application because |
301 | untrusted or invalid certificates may be accepted. | ||
302 | Doing this can possibly make | ||
303 | .Xr X509_verify_cert 3 | ||
304 | return what appears to be a validated chain of certificates that has not | ||
305 | been validated or even had the signatures checked. | ||