Bug 63679 - Usage of wrong mctx in ssl_callback_SSLVerify function
Summary: Usage of wrong mctx in ssl_callback_SSLVerify function
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_ssl (show other bugs)
Version: 2.5-HEAD
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Keywords: FixedInTrunk
Depends on:
Reported: 2019-08-21 12:01 UTC by Lubos Uhliarik
Modified: 2020-06-20 12:21 UTC (History)
0 users

Patch fixing the bug (802 bytes, patch)
2019-08-21 12:01 UTC, Lubos Uhliarik
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Lubos Uhliarik 2019-08-21 12:01:44 UTC
Created attachment 36728 [details]
Patch fixing the bug

Hi all,

in the commit r1826995 a following change has been made to ssl_callback_SSLVerify function in ssl_engine_kernel.c:

-    if (ok && sc->server->ocsp_enabled == TRUE) {
+    if (ok && ((sc->server->ocsp_mask & SSL_OCSPCHECK_CHAIN) ||
+         (errdepth == 0 && (sc->server->ocsp_mask & SSL_OCSPCHECK_LEAF)))) {     

Instead of using sc->server, mctx should be used. It causes now weird behavior, since ocsp_mask is by default set to UNSET (which is -1, translated to signed int...). When proxy is set set on the same server, if-condition above will be true.

I'm proposing this change:

-    if (ok && sc->server->ocsp_enabled) {
+    if (ok && ((mctx->ocsp_mask & SSL_OCSPCHECK_CHAIN) ||
+         (errdepth == 0 && (mctx->ocsp_mask & SSL_OCSPCHECK_LEAF)))) {

It was working before, because ocsp_enabled was by default set to FALSE. ocsp_mask is UNSET by default now and is set either to proxy or server structure in sc. If sc with is_proxy is passed here, it will result in bug.

Attaching patch. Please merge it to 2.4.x if possible.
Comment 1 Yann Ylavic 2019-08-23 10:46:13 UTC
Thanks for spotting and the patch, applied in r1865740.
I will propose it for backport soon, waiting a bit for others' review.
Comment 2 Yann Ylavic 2020-01-02 13:32:00 UTC
Backported to 2.4.x (r1872226), will be in the next release.
Comment 3 Christophe JAILLET 2020-06-20 12:21:16 UTC
This is part of 2.4.42