[Bug 60182] SSLStaplingFakeTryLater Deviates From Documented Behavior of Only Being Effective When SSLStaplingReturnResponderErrors is On

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60182

--- Comment #1 from gmoniker@gmail.com ---
This behaviour in Apache 2.4 is still ongoing in trunk and it is making it very
difficult for server operators. 

On the one hand authorities like the Dutch NCSC and privacy focused customers
are demanding that OCSP stapling should be enabled, and at the other hand you
have a bug in the Apache code that makes it nearly impossible to have stapling
enabled while an OCSP responder is unreachable with no immediate connection
refusal. The OCSP responders and the browser clients are completely outside the
operators control.

Setting FakeTryLater or leaving it on default would really help in this case,
because the ResponderTimeOut is only experienced on one TLS connection setup by
a client and then the TryLater is cached.

However this is not possible for two reasons:

1. The TryLater if it is made by Apache 2.4 is not marked as an unsuccesful
response, so it is cached for the duration of the succesful OCSP response
caching time out, which you would want to be long. So, this will mean that even
a short unreachability of the OCSP responder, causes a long unavailability of
the OCSP staple. Setting FakeTryLater to off, is not a real option either
because then each new TLS connection from a browser will again have to suffer
the ResponderTimeOut until the server can finally reach the OCSP responder,
leading to a potentially huge increase in memory usage and slow website
loading.

2. The faked TryLater because it is not marked as an unsuccesful response is
served to the clients, even if ReturnResponderErrors is off. In itself this
does not violate any RFC and the RFC meaning of TryLater would seem to support
this usage. But it is contrary to the expectation from the documentation, and
the natural language interpretation of ReturnReponderErrors. Also it
specifically causes trouble for FireFox users. If the Firefox browser in
default settings (for the past four year anyway) doesn't have a cached OCSP
response itself and receives a TryLater, then it will refuse to load the site
and give its users an incomprehensible message. This is not Apache's fault, but
it is kind of difficult for the server operator to explain to customers.

So, for the server operator at the moment, it is kind of repulsive to activate
OCSP stapling in Apache. Apache turns a DOS of the OCSP responder into a DOS of
the website it serves. And the fix would really be very simple. It is even
already made in the 2.5 branch. Just mark the faked up TryLater as an
unsuccesful response. Include *pok = false after the create of the TryLater,
just as in
https://github.com/apache/httpd/commit/3bd26f8c6b3ed892e0e27747bb5fce1db360ffc1#diff-f4dcc9abff3ef58debc5e15da139ce3d

Then setting ReturnResponderErrors to off works also for the faked TryLater and
just gives no staple response then, which is just fine for all the major
browsers, as long as they are not set to require a mandatory OCSP response,
which is not their default setting. Furthermore the faked TryLater is only
stored for SSLStaplingErrorCacheTimeout, which increases the time a valid OCSP
response staple can be available. And no TLS connections have to wait for
SSLStaplingResponderTimeout seconds, but one in each error cache timeout.

With that fix, I believe setting ReturnResponderErrors to on is still a bit
impossible, because it turns an OCSP responder DOS unnecesarily into a website
DOS. But thats a different issue, and at least as operator you have one
workable configuration, even if it is not the default one.

1. Online Certificate Status Protocol - OCSP
https://tools.ietf.org/html/rfc6960
2. Dutch governmental TLS guidelines, saying you have to activate OCSP stapling
on the server or give a very good reason why not:
https://www.ncsc.nl/binaries/ncsc/documenten/publicaties/2019/mei/01/ict-beveiligingsrichtlijnen-voor-transport-layer-security-tls/ICT-beveiligingsrichtlijnen-voor-Transport-Layer-Security-v2.pdf

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org