You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Stefan Eissing <st...@greenbytes.de> on 2017/06/12 15:25:39 UTC
ocsp stapling improvements
I talked to the people orignally writing our ssl OCSP code regarding
feedback we got from the Let's Encrypt server outage [1]. We agreed
that some valid points for improvement were raised and we need a
discussion about what should be done about it, here.
I identified the following points so far:
1. Hand out existing responses until expired
2. Persist responses (is this just a config/default issue?)
3. Start update responses at server start/regular intervals
4. Use something better than HTTP/1.0 requests
I think 1) should be not too complicated code changes without
any big restructuring. I saw Ruediger already doing some changes.
The reason for 2) is not clear to me. Is this just a configuration
issue to have a persistent cache or is our giving up privileges
limiting here?
As to 3, starting a task at server start or after a certain interval,
do we have some infrastructure for this? Do we need something new?
On 4, it seems, we lack a good http(s) client. The code we use
for proxying is not easily reused for new connections, or? I see
more need for such a thing in the near future.
Feedback appreciated.
Cheers,
-Stefan
[1] https://blog.hboeck.de/archives/886-The-Problem-with-OCSP-Stapling-and-Must-Staple-and-why-Certificate-Revocation-is-still-broken.html
Re: ocsp stapling improvements
Posted by Ruediger Pluem <rp...@apache.org>.
On 06/12/2017 08:56 PM, Eric Covener wrote:
> On Mon, Jun 12, 2017 at 11:25 AM, Stefan Eissing
> <st...@greenbytes.de> wrote:
>> As to 3, starting a task at server start or after a certain interval,
>> do we have some infrastructure for this? Do we need something new?
>
> I don't really understand the context, but some potential examples
> would be the daemon launched by mod_cgid or rewritemap programs
> started by mod_rewrite.
That sounds old school :-).
I had mod_watchdog in mind when thinking of updating the OCSP responses
on a regular basis in the background.
Regards
Rüdiger
Re: ocsp stapling improvements
Posted by Eric Covener <co...@gmail.com>.
On Mon, Jun 12, 2017 at 11:25 AM, Stefan Eissing
<st...@greenbytes.de> wrote:
> As to 3, starting a task at server start or after a certain interval,
> do we have some infrastructure for this? Do we need something new?
I don't really understand the context, but some potential examples
would be the daemon launched by mod_cgid or rewritemap programs
started by mod_rewrite.
Re: ocsp stapling improvements
Posted by Ruediger Pluem <rp...@apache.org>.
On 06/12/2017 08:50 PM, Jacob Champion wrote:
> On 06/12/2017 08:25 AM, Stefan Eissing wrote:
>> On 4, it seems, we lack a good http(s) client. The code we use
>> for proxying is not easily reused for new connections, or? I see
>> more need for such a thing in the near future.
>
> Did the Apache-Serf-for-proxying effort end up going anywhere? I seem to remember Jim working on something related to
> this point.
IMHO a very old and reoccurring discussion that got always stuck for various reasons :-).
I agree that a better HTTP(s) client would be helpful, but I think it is not that desperately needed for the case
of our OCSP issues.
Regards
Rüdiger
Re: ocsp stapling improvements
Posted by Jacob Champion <ch...@gmail.com>.
On 06/12/2017 08:25 AM, Stefan Eissing wrote:
> On 4, it seems, we lack a good http(s) client. The code we use
> for proxying is not easily reused for new connections, or? I see
> more need for such a thing in the near future.
Did the Apache-Serf-for-proxying effort end up going anywhere? I seem to
remember Jim working on something related to this point.
--Jacob
Re: ocsp stapling improvements
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 13.06.2017 um 00:48 schrieb Hanno Böck <ha...@hboeck.de>:
>
> Hi,
>
> On Mon, 12 Jun 2017 17:25:39 +0200
> Stefan Eissing <st...@greenbytes.de> wrote:
>
>> 1. Hand out existing responses until expired
>> 2. Persist responses (is this just a config/default issue?)
>> 3. Start update responses at server start/regular intervals
>> 4. Use something better than HTTP/1.0 requests
>
> 1-3 covers the important issues, I'm not sure http/1.0 is a major
> problem. Are there any problems with that / CAs that serve OCSP only
> over HTTP/1.1?
> (to be clear: certainly desirable to have a better solution here, but I
> feel that isn't the most important issue.)
Agreed.
> What I think needs also be handled:
> * There's
> https://bz.apache.org/bugzilla/show_bug.cgi?id=59049
> which indicates that faulty responses from the OCSP server may bring
> the server into a faulty state from which it doesn't recover. I
> haven't tried to reproduce this, but it certianly should be fixed as
> well, probably just some missing error check tough.
> * Some of the existing options imho don't make any sense and should
> default to off and maybe even be forced off (so that setting them to
> "on" doesn't do anything). That includes SSLStaplingFakeTryLater and
> SSLStaplingReturnResponderErrors. Unless I'm missing something I
> don't see any situation in which stapling OCSP errors is desirable.
Will have a look.
- Stefan
> --
> Hanno Böck
> https://hboeck.de/
>
> mail/jabber: hanno@hboeck.de
> GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
Re: ocsp stapling improvements
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 13.06.2017 um 00:48 schrieb Hanno Böck <ha...@hboeck.de>:
>
> What I think needs also be handled:
> * There's
> https://bz.apache.org/bugzilla/show_bug.cgi?id=59049
> which indicates that faulty responses from the OCSP server may bring
> the server into a faulty state from which it doesn't recover. I
> haven't tried to reproduce this, but it certianly should be fixed as
> well, probably just some missing error check tough.
I would expect to catch that with the change in handling responses. If we
never replace an existing OCSP response one with an error, the problem
should disappear. As I read the code, we currently use the response cache
to signal communication errors to other connections to avoid spamming
the OCSP responder.
If we have only one mod_watchdog thread querying responders, there no
longer is need for that, it seems.
> * Some of the existing options imho don't make any sense and should
> default to off and maybe even be forced off (so that setting them to
> "on" doesn't do anything). That includes SSLStaplingFakeTryLater and
> SSLStaplingReturnResponderErrors. Unless I'm missing something I
> don't see any situation in which stapling OCSP errors is desirable.
I think we want any enhancements to be applicable to 2.4.x and there
we cannot silently change the defaults. I propose to add a new stapling
directive that changes to a different default set for the other ones.
SSLStaplingResilience on|off|enforce
with "on" and "off" to change defaults to new/old ones. And "enforce"
to only allow new ones and log warnings when old are ignored. Something
to detect/verify settings in a large configuration.
Re: ocsp stapling improvements
Posted by Hanno Böck <ha...@hboeck.de>.
Hi,
On Mon, 12 Jun 2017 17:25:39 +0200
Stefan Eissing <st...@greenbytes.de> wrote:
> 1. Hand out existing responses until expired
> 2. Persist responses (is this just a config/default issue?)
> 3. Start update responses at server start/regular intervals
> 4. Use something better than HTTP/1.0 requests
1-3 covers the important issues, I'm not sure http/1.0 is a major
problem. Are there any problems with that / CAs that serve OCSP only
over HTTP/1.1?
(to be clear: certainly desirable to have a better solution here, but I
feel that isn't the most important issue.)
What I think needs also be handled:
* There's
https://bz.apache.org/bugzilla/show_bug.cgi?id=59049
which indicates that faulty responses from the OCSP server may bring
the server into a faulty state from which it doesn't recover. I
haven't tried to reproduce this, but it certianly should be fixed as
well, probably just some missing error check tough.
* Some of the existing options imho don't make any sense and should
default to off and maybe even be forced off (so that setting them to
"on" doesn't do anything). That includes SSLStaplingFakeTryLater and
SSLStaplingReturnResponderErrors. Unless I'm missing something I
don't see any situation in which stapling OCSP errors is desirable.
--
Hanno Böck
https://hboeck.de/
mail/jabber: hanno@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
Re: ocsp stapling improvements
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 20.06.2017 um 17:19 schrieb Hanno Böck <ha...@hboeck.de>:
>
> On Tue, 20 Jun 2017 13:39:56 +0200
> Stefan Eissing <st...@greenbytes.de> wrote:
>
>> Can we push the burden of getting a OCSP response to the client, even
>> for must-staple certificates?
>
> No, you can't.
> The whole point is that must staple enforces stapling.
>
> This has a bit to do with the history of certificate revocation and why
> it's broken.
>
> All browsers do OCSP checks in a soft-fail mode (or not at all). This
> basically makes it pointless, as an attacker can just block OCSP
> requests.
>
> OCSP stapling was invented to move away from that unreliable mechanism.
> Must-staple enforces that mechanism. There is no way to fall back to
> the old unreliable mechanism if you want to have it secure.
So, the extension protects clients with incomplete or silently graceful
fallbacks from exposing their users. Understood. Not sure if I share this
strategy 100%, but it is what it is.
If httpd persists responses and tries to renew a good amount of time before
they expire (btw. do you know what common validity durations are?), this
hopefully does not become a huge DoS opportunity.
-Stefan
Re: ocsp stapling improvements
Posted by Hanno Böck <ha...@hboeck.de>.
On Tue, 20 Jun 2017 13:39:56 +0200
Stefan Eissing <st...@greenbytes.de> wrote:
> Can we push the burden of getting a OCSP response to the client, even
> for must-staple certificates?
No, you can't.
The whole point is that must staple enforces stapling.
This has a bit to do with the history of certificate revocation and why
it's broken.
All browsers do OCSP checks in a soft-fail mode (or not at all). This
basically makes it pointless, as an attacker can just block OCSP
requests.
OCSP stapling was invented to move away from that unreliable mechanism.
Must-staple enforces that mechanism. There is no way to fall back to
the old unreliable mechanism if you want to have it secure.
--
Hanno Böck
https://hboeck.de/
mail/jabber: hanno@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
Re: ocsp stapling improvements
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 20.06.2017 um 17:43 schrieb William A Rowe Jr <wr...@rowe-clan.net>:
>
> On Tue, Jun 20, 2017 at 6:39 AM, Stefan Eissing
> <st...@greenbytes.de> wrote:
>>
>>> Am 12.06.2017 um 21:35 schrieb Ruediger Pluem <rp...@apache.org>:
>>>
>>>> 2. Persist responses (is this just a config/default issue?)
>>>
>>> This could become tricky given the various so cache implementations we have. I could
>>> only think of persisting the whole cache when Apache is shutdown.
>>
>> I am not very experienced with those. Would the current Stapling implementation not work with a "socache_dbm"? And what would be the drawback of that?
>>
>> As an alternative, use of mod_watchdog offers advantages here. If we have only one thread (for all or for a particular certificate) that writes the cache in a server (all processes), it becomes easy to use the file system, I think. Write per tmpfile+rename should be good enough and it should no longer need a global mutex. Server names are distinct and make for an easy directory tree.
>>
>> The question then is if mod_watchdog jobs still have privileges or if those files have common ownership and if that is a problem.
>>
>> Does this makes sense or am I insane?
>
> I consider it very unwise to use root to perform client queries, almost
> as unwise as serving any responses. The problem in both cases is
> that every defect in parsing (and there is 'input' in either case) opens
> up the remote possibility of a root exploit.
>
> All client requests, for stapling, for health check, for any purposes
> whatsoever should be performed as httpd configured user. Whether
> that happens in an ombudsman resource process or the typical
> worker process is a design question.
>
> Yes, a dbm certainly should survive a server restart, that's why one
> would use dbm for the SSL Session Cache (before session tickets
> offered a fresh solution - although these suffer just as many issues
> as our OCSP implementation so far.)
I share your point of view. I do not want to make OCSP requests as root.
As far as I can tell, that would mean the dbm file is owned by the configured
user.
My question is: is this acceptable or do we have an alternative?
Re: ocsp stapling improvements
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Tue, Jun 20, 2017 at 6:39 AM, Stefan Eissing
<st...@greenbytes.de> wrote:
>
>> Am 12.06.2017 um 21:35 schrieb Ruediger Pluem <rp...@apache.org>:
>>
>>> 2. Persist responses (is this just a config/default issue?)
>>
>> This could become tricky given the various so cache implementations we have. I could
>> only think of persisting the whole cache when Apache is shutdown.
>
> I am not very experienced with those. Would the current Stapling implementation not work with a "socache_dbm"? And what would be the drawback of that?
>
> As an alternative, use of mod_watchdog offers advantages here. If we have only one thread (for all or for a particular certificate) that writes the cache in a server (all processes), it becomes easy to use the file system, I think. Write per tmpfile+rename should be good enough and it should no longer need a global mutex. Server names are distinct and make for an easy directory tree.
>
> The question then is if mod_watchdog jobs still have privileges or if those files have common ownership and if that is a problem.
>
> Does this makes sense or am I insane?
I consider it very unwise to use root to perform client queries, almost
as unwise as serving any responses. The problem in both cases is
that every defect in parsing (and there is 'input' in either case) opens
up the remote possibility of a root exploit.
All client requests, for stapling, for health check, for any purposes
whatsoever should be performed as httpd configured user. Whether
that happens in an ombudsman resource process or the typical
worker process is a design question.
Yes, a dbm certainly should survive a server restart, that's why one
would use dbm for the SSL Session Cache (before session tickets
offered a fresh solution - although these suffer just as many issues
as our OCSP implementation so far.)
Re: ocsp stapling improvements
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 20.06.2017 um 14:35 schrieb Plüm, Rüdiger, Vodafone Group <ru...@vodafone.com>:
>
> It might cause I/O overhead compared with socache_shmcb, but it might be a good solution
> for those who want to have persisted OCSP responses. Other people might priorize
> a distributed cache like dc or memcache. So I like the idea of just staying
> with the current approach to define the socache provider used for caching.
> Who knows? Maybe someone writes a socache_staggered that allows to go through several
> socache providers one after another in case of a cache miss? That would allow to have
> a shmcb first and a dbm second.
I agree to the re-use and the more flexible architecture we already have in place here.
The only bone I have with this is that it has "only" cache semantics and is not a store. Sure, we can document that an admin should make the cache "large enough", but it's not totally under his control as the size of the answers can vary.
If we update the answers regularly by watchdog, we should remove the request trigger during connection setup (e.g. complexity, race conditions). A too small cache could really hurt.
OTOH: is dbm really size limited? Maybe it is not. Then this would be my preference.
>>
>> As an alternative, use of mod_watchdog offers advantages here. If we
>> have only one thread (for all or for a particular certificate) that
>> writes the cache in a server (all processes), it becomes easy to use the
>> file system, I think. Write per tmpfile+rename should be good enough and
>> it should no longer need a global mutex. Server names are distinct and
>> make for an easy directory tree.
>>
>> The question then is if mod_watchdog jobs still have privileges or if
>> those files have common ownership and if that is a problem.
>>
>> Does this makes sense or am I insane?
>
> I guess this is all solvable, but as stated above I am in favor of just using the
> socache API for that and let our requirements be solved by an appropriate socache
> provider.
"staggered" cache with store semantics would be cool.
-Stefan
AW: ocsp stapling improvements
Posted by Plüm,
Rüdiger,
Vodafone Group <ru...@vodafone.com>.
> -----Ursprüngliche Nachricht-----
> Von: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
> Gesendet: Dienstag, 20. Juni 2017 13:40
> An: dev@httpd.apache.org
> Betreff: Re: ocsp stapling improvements
>
>
> > Am 12.06.2017 um 21:35 schrieb Ruediger Pluem <rp...@apache.org>:
> >
> > I guess the core mistake we do today is that we expire the entries in
> the cache
> > after SSLStaplingStandardCacheTimeout. But we should keep them in the
> cache as long as
> > they are valid (so either whats in the next update field of the
> response or this update
> > + SSLStaplingResponseMaxAge).
>
> +1
>
> > Instead we should have a refresh parameter that I would set as
> percentage of the
> > expired time (so between this update and next update or as percentage
> of already
> > expired SSLStaplingResponseMaxAge). Once this refresh time is passed
> OCSP responses
> > should get refreshed by a background job (possibly implemented by
> mod_watchdog).
>
> +1
>
> >> 2. Persist responses (is this just a config/default issue?)
> >
> > This could become tricky given the various so cache implementations we
> have. I could
> > only think of persisting the whole cache when Apache is shutdown.
>
> I am not very experienced with those. Would the current Stapling
> implementation not work with a "socache_dbm"? And what would be the
> drawback of that?
It might cause I/O overhead compared with socache_shmcb, but it might be a good solution
for those who want to have persisted OCSP responses. Other people might priorize
a distributed cache like dc or memcache. So I like the idea of just staying
with the current approach to define the socache provider used for caching.
Who knows? Maybe someone writes a socache_staggered that allows to go through several
socache providers one after another in case of a cache miss? That would allow to have
a shmcb first and a dbm second.
>
> As an alternative, use of mod_watchdog offers advantages here. If we
> have only one thread (for all or for a particular certificate) that
> writes the cache in a server (all processes), it becomes easy to use the
> file system, I think. Write per tmpfile+rename should be good enough and
> it should no longer need a global mutex. Server names are distinct and
> make for an easy directory tree.
>
> The question then is if mod_watchdog jobs still have privileges or if
> those files have common ownership and if that is a problem.
>
> Does this makes sense or am I insane?
I guess this is all solvable, but as stated above I am in favor of just using the
socache API for that and let our requirements be solved by an appropriate socache
provider.
>
> >> 3. Start update responses at server start/regular intervals
> >
> > What I want to avoid is that the server "hangs" at start because of a
> "hanging" OCSP server.
> > I admit that this can happen already today on the very first SSL
> request with stapling turned
> > on, but IMHO this is a bad behavior. So either just do the stuff on a
> regular basis in the background
> > and do not staple if there is no valid OCSP response yet (I know Hanno
> won't like that :-))
> > Or have an initial (valid) OCSP response being loaded from a file
> during startup. It would be up to
> > the admin to fill this file with a valid OCSP response before it
> starts httpd.
>
> Can we push the burden of getting a OCSP response to the client, even
> for must-staple certificates? This would be nice as a fall back in case
> of errors. The error might be in the data center for outgoing
> connections, so the client might succeed where the server fails.
I would be in favor of this. I think it is still reasonable to have the client
try the OCSP server if the server cannot get a valid response to staple.
But this is my personal opinion, so others might have different requirements.
The question to me is what do we need to do in mod_ssl code to offer this?
I mean the changes that are now on the table should ensure that we get a more
reliable stapling infrastructure within mod_ssl that allows people to try
must-staple. Anything else we need or can do?
Regards
Rüdiger
Re: ocsp stapling improvements
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 12.06.2017 um 21:35 schrieb Ruediger Pluem <rp...@apache.org>:
>
> I guess the core mistake we do today is that we expire the entries in the cache
> after SSLStaplingStandardCacheTimeout. But we should keep them in the cache as long as
> they are valid (so either whats in the next update field of the response or this update
> + SSLStaplingResponseMaxAge).
+1
> Instead we should have a refresh parameter that I would set as percentage of the
> expired time (so between this update and next update or as percentage of already
> expired SSLStaplingResponseMaxAge). Once this refresh time is passed OCSP responses
> should get refreshed by a background job (possibly implemented by mod_watchdog).
+1
>> 2. Persist responses (is this just a config/default issue?)
>
> This could become tricky given the various so cache implementations we have. I could
> only think of persisting the whole cache when Apache is shutdown.
I am not very experienced with those. Would the current Stapling implementation not work with a "socache_dbm"? And what would be the drawback of that?
As an alternative, use of mod_watchdog offers advantages here. If we have only one thread (for all or for a particular certificate) that writes the cache in a server (all processes), it becomes easy to use the file system, I think. Write per tmpfile+rename should be good enough and it should no longer need a global mutex. Server names are distinct and make for an easy directory tree.
The question then is if mod_watchdog jobs still have privileges or if those files have common ownership and if that is a problem.
Does this makes sense or am I insane?
>> 3. Start update responses at server start/regular intervals
>
> What I want to avoid is that the server "hangs" at start because of a "hanging" OCSP server.
> I admit that this can happen already today on the very first SSL request with stapling turned
> on, but IMHO this is a bad behavior. So either just do the stuff on a regular basis in the background
> and do not staple if there is no valid OCSP response yet (I know Hanno won't like that :-))
> Or have an initial (valid) OCSP response being loaded from a file during startup. It would be up to
> the admin to fill this file with a valid OCSP response before it starts httpd.
Can we push the burden of getting a OCSP response to the client, even for must-staple certificates? This would be nice as a fall back in case of errors. The error might be in the data center for outgoing connections, so the client might succeed where the server fails.
-Stefan
Re: ocsp stapling improvements
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 12.06.2017 um 21:35 schrieb Ruediger Pluem <rp...@apache.org>:
>
>
>
> On 06/12/2017 05:25 PM, Stefan Eissing wrote:
>> I talked to the people orignally writing our ssl OCSP code regarding
>> feedback we got from the Let's Encrypt server outage [1]. We agreed
>> that some valid points for improvement were raised and we need a
>> discussion about what should be done about it, here.
>>
>> I identified the following points so far:
>>
>> 1. Hand out existing responses until expired
>
> I guess the core mistake we do today is that we expire the entries in the cache
> after SSLStaplingStandardCacheTimeout. But we should keep them in the cache as long as
> they are valid (so either whats in the next update field of the response or this update
> + SSLStaplingResponseMaxAge).
> Instead we should have a refresh parameter that I would set as percentage of the
> expired time (so between this update and next update or as percentage of already
> expired SSLStaplingResponseMaxAge). Once this refresh time is passed OCSP responses
> should get refreshed by a background job (possibly implemented by mod_watchdog).
+1
>> 2. Persist responses (is this just a config/default issue?)
>
> This could become tricky given the various so cache implementations we have. I could
> only think of persisting the whole cache when Apache is shutdown.
Hmm, if there is a single watchdog job fetching/updating the OCSP responses, we'd no
long have requests triggered by new connections in child processes, right? That
would make a file based lookup quite simple, I'd assume?
>> 3. Start update responses at server start/regular intervals
>
> What I want to avoid is that the server "hangs" at start because of a "hanging" OCSP server.
> I admit that this can happen already today on the very first SSL request with stapling turned
> on, but IMHO this is a bad behavior. So either just do the stuff on a regular basis in the background
> and do not staple if there is no valid OCSP response yet (I know Hanno won't like that :-))
> Or have an initial (valid) OCSP response being loaded from a file during startup. It would be up to
> the admin to fill this file with a valid OCSP response before it starts httpd.
The goal would be anyway, given watchdog refreshes at appropriate times, to always have
persisted and valid ocsp responses. Only when a new cert gets deployed, there would be the
chance of "missing" ocsp responses until the watchdog job can retrieve it.
If we serve the connection then without, or fail after a small grace timeout, will probably need to be decided by the admin.
>> 4. Use something better than HTTP/1.0 requests
>
> What issues do we have with the HTTP/1.0 requests?
None i know of in ocsp. So, disregard this please. I take it back.
>> I think 1) should be not too complicated code changes without
>> any big restructuring. I saw Ruediger already doing some changes.
>>
>> The reason for 2) is not clear to me. Is this just a configuration
>> issue to have a persistent cache or is our giving up privileges
>> limiting here?
>>
>> As to 3, starting a task at server start or after a certain interval,
>> do we have some infrastructure for this? Do we need something new?
>>
>> On 4, it seems, we lack a good http(s) client. The code we use
>> for proxying is not easily reused for new connections, or? I see
>> more need for such a thing in the near future.
>>
>> Feedback appreciated.
>
> Regards
>
> Rüdiger
Re: ocsp stapling improvements
Posted by Ruediger Pluem <rp...@apache.org>.
On 06/12/2017 05:25 PM, Stefan Eissing wrote:
> I talked to the people orignally writing our ssl OCSP code regarding
> feedback we got from the Let's Encrypt server outage [1]. We agreed
> that some valid points for improvement were raised and we need a
> discussion about what should be done about it, here.
>
> I identified the following points so far:
>
> 1. Hand out existing responses until expired
I guess the core mistake we do today is that we expire the entries in the cache
after SSLStaplingStandardCacheTimeout. But we should keep them in the cache as long as
they are valid (so either whats in the next update field of the response or this update
+ SSLStaplingResponseMaxAge).
Instead we should have a refresh parameter that I would set as percentage of the
expired time (so between this update and next update or as percentage of already
expired SSLStaplingResponseMaxAge). Once this refresh time is passed OCSP responses
should get refreshed by a background job (possibly implemented by mod_watchdog).
> 2. Persist responses (is this just a config/default issue?)
This could become tricky given the various so cache implementations we have. I could
only think of persisting the whole cache when Apache is shutdown.
> 3. Start update responses at server start/regular intervals
What I want to avoid is that the server "hangs" at start because of a "hanging" OCSP server.
I admit that this can happen already today on the very first SSL request with stapling turned
on, but IMHO this is a bad behavior. So either just do the stuff on a regular basis in the background
and do not staple if there is no valid OCSP response yet (I know Hanno won't like that :-))
Or have an initial (valid) OCSP response being loaded from a file during startup. It would be up to
the admin to fill this file with a valid OCSP response before it starts httpd.
> 4. Use something better than HTTP/1.0 requests
What issues do we have with the HTTP/1.0 requests?
>
> I think 1) should be not too complicated code changes without
> any big restructuring. I saw Ruediger already doing some changes.
>
> The reason for 2) is not clear to me. Is this just a configuration
> issue to have a persistent cache or is our giving up privileges
> limiting here?
>
> As to 3, starting a task at server start or after a certain interval,
> do we have some infrastructure for this? Do we need something new?
>
> On 4, it seems, we lack a good http(s) client. The code we use
> for proxying is not easily reused for new connections, or? I see
> more need for such a thing in the near future.
>
> Feedback appreciated.
Regards
Rüdiger