[prev in list] [next in list] [prev in thread] [next in thread]
List: apache-httpd-dev
Subject: Re: [RFC] Enable OCSP Stapling by default in httpd trunk
From: Brian Smith <brian () briansmith ! org>
Date: 2015-08-30 7:14:49
Message-ID: CAFewVt4v-6hR=O=FxvL_OupEqpGnFFF78S9N=daPSQhb=VjF4w () mail ! gmail ! com
[Download RAW message or body]
Kaspar Brand <httpd-dev.2014@velox.ch> wrote:
> On 28.08.2015 19:27, Jeff Trawick wrote:
> > For one, it is appropriate for the default config is there to enable
> > practices which are reasonable in most situations, and OCSP Stapling is
> > widely accepted as an appropriate feature for HTTP servers to enable.
>
> I have some doubts whether "widely accepted" is an accurate summary of
> today's situation, because this assessment misses the fact that with the
> current RFC-6066-based implementation, stapling can't fully achieve the
> goal of obviating OCSP queries for the clients - all publicly trusted
> CAs use hierarchies with at least two tiers these days, so effectively
> RFC 6961 support would be needed.
This is not true. In the case of Firefox, and I believe Chrome, it was
decided that the website is responsible for delivering the OCSP response
(via stapling) for the end-entity, and the browser is responsible for
getting the revocation info for the intermediates *in some unspecified
way*. In practice, that way is CRLSets. I think MSIE is or has also started
moving to that model.
In particular, browser makers aren't interested in RFC 6961 because of it
is a poor performance trade-off and also never implemented.
> And given that the most popular
> browser only enforces revocation checking for EV certificates (certainly
> less than 10% of all SSL certs out there), the benefit of turning on
> stapling for DV/OV certs by default is not so apparent either.
>
This is a chicken-and-egg problem. The proposed Must-Staple feature makes
OCSP useful. Obviously Must-Staple only works if the server staples the
response. Conversely, without Must-Staple, OCSP is useless in browsers.
> What wasn't mentioned in the original RFC [1], and what I'm still
> wondering about, is the primary motivation for enabling it on trunk?
The main motivation for OCSP stapling is to demonstrate that OCSP stapling
works in a widespread way, so that browsers can start implementing the
Must-Staple feature and gather useful metrics about the effects, including
any possible negative side effects.
> As I wrote in my reply at that time, changing the default in trunk will
> hardly help in getting broader real-world testing results.
It has to be changed on Trunk before it can be changed anywhere else, right?
> If the
> plan is to propose a backport to 2.4.x soon afterwards, however, then I
> would certainly oppose unless systematic coverage for OCSP stapling is
> added to the test framework (enabling a feature by default in a GA
> release for which there is not a single test is a no go, IMO).
>
I agree.
And, to be perfectly honest, there are a lot of things that can go wrong
with OCSP stapling and I've yet to see an implementation without a serious
flaw.
> It should be worth mentioning that the OCSP URI in a server cert is to
> be considered untrusted, as mod_ssl does not validate its own cert at
> startup.
>
Using that argument, it isn't safe to use the server's end-entity
certificate either, because it hasn't been checked for validity. In
particular, it hasn't been checked for revocation! The Heartbleed
vulnerability had such a huge impact partially because there was no
**effective** and easy-to-use way for servers to revoke certificates. We
need to find a solution to revocation and I think that Apache enabling OCSP
stapling by default is the next step towards a solution.
> The default configuration should not trigger unsolicited outgoing
> queries to untrusted systems, for both a) and b), that's how I would
> put it.
Look at IIS, which has been doing OCSP stapling by default, without
significant problems, for many years now. Has anybody really been harmed by
IIS's default? I don't think so. I think this is an instance of the perfect
being the enemy of the good.
> Additionally, features enabled by default need to have sufficient
> coverage in the test framework.
>
Again, I agree.
In case it would be helpful: When I was at Mozilla, my team created a new
certificate verification library for Firefox. That includes a complete
implementation of OCSP verification. It also includes a small test suite
for OCSP verification. We intentionally licensed it under the Apache 2.0
license so that Apache could use the code, if Apache wants to use it. If
nothing else, the OCSP tests [3] might be a useful model for Apache's tests.
After I left Mozilla, I separated out the implementation from Firefox's
repository and made it available on GitHub: [1]. I spent some time making
that code work with OpenSSL in a branch [2].
[1] https://github.com/briansmith/mozillapkix
[2] https://github.com/briansmith/mozillapkix/tree/feature/openssl
[3]
https://github.com/briansmith/mozillapkix/blob/master/test/gtest/pkixocsp_VerifyEncodedOCSPResponse.cpp
Cheers,
Brian
--
https://briansmith.org/
[Attachment #3 (text/html)]
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Kaspar Brand <span \
dir="ltr"><<a href="mailto:httpd-dev.2014@velox.ch" \
target="_blank">httpd-dev.2014@velox.ch</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span \
class="">On 28.08.2015 19:27, Jeff Trawick wrote:<br> > For one, it is appropriate \
for the default config is there to enable<br> > practices which are reasonable in \
most situations, and OCSP Stapling is<br> > widely accepted as an appropriate \
feature for HTTP servers to enable.<br> <br>
</span>I have some doubts whether "widely accepted" is an accurate summary \
of<br> today's situation, because this assessment misses the fact that with \
the<br> current RFC-6066-based implementation, stapling can't fully achieve \
the<br> goal of obviating OCSP queries for the clients - all publicly trusted<br>
CAs use hierarchies with at least two tiers these days, so effectively<br>
RFC 6961 support would be needed.</blockquote><div><br></div><div>This is not true. \
In the case of Firefox, and I believe Chrome, it was decided that the website is \
responsible for delivering the OCSP response (via stapling) for the end-entity, and \
the browser is responsible for getting the revocation info for the intermediates *in \
some unspecified way*. In practice, that way is CRLSets. I think MSIE is or has also \
started moving to that model.</div><div><br></div><div>In particular, browser makers \
aren't interested in RFC 6961 because of it is a poor performance trade-off and \
also never implemented.</div><div><br></div><div> </div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">And \
given that the most popular<br> browser only enforces revocation checking for EV \
certificates (certainly<br> less than 10% of all SSL certs out there), the benefit of \
turning on<br> stapling for DV/OV certs by default is not so apparent \
either.<br></blockquote><div><br></div><div>This is a chicken-and-egg problem. The \
proposed Must-Staple feature makes OCSP useful. Obviously Must-Staple only works if \
the server staples the response. Conversely, without Must-Staple, OCSP is useless in \
browsers. </div><div> <br></div><blockquote class="gmail_quote" style="margin:0px \
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">What \
wasn't mentioned in the original RFC [1], and what I'm still<br> wondering \
about, is the primary motivation for enabling it on \
trunk?</blockquote><div><br></div><div>The main motivation for OCSP stapling is to \
demonstrate that OCSP stapling works in a widespread way, so that browsers can start \
implementing the Must-Staple feature and gather useful metrics about the effects, \
including any possible negative side effects.</div><div> </div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> \
As I wrote in my reply at that time, changing the default in trunk will<br> hardly \
help in getting broader real-world testing \
results.</blockquote><div><br></div><div>It has to be changed on Trunk before it can \
be changed anywhere else, right?</div><div><br></div><div> </div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">If \
the<br> plan is to propose a backport to 2.4.x soon afterwards, however, then I<br>
would certainly oppose unless systematic coverage for OCSP stapling is<br>
added to the test framework (enabling a feature by default in a GA<br>
release for which there is not a single test is a no go, \
IMO).<br></blockquote><div><br></div><div>I agree.</div><div><br></div><div>And, to \
be perfectly honest, there are a lot of things that can go wrong with OCSP stapling \
and I've yet to see an implementation without a serious flaw.</div><div> \
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">It \
should be worth mentioning that the OCSP URI in a server cert is to<br> be considered \
untrusted, as mod_ssl does not validate its own cert at<br> \
startup.<br></blockquote><div><br></div><div>Using that argument, it isn't safe \
to use the server's end-entity certificate either, because it hasn't been \
checked for validity. In particular, it hasn't been checked for revocation! The \
Heartbleed vulnerability had such a huge impact partially because there was no \
**effective** and easy-to-use way for servers to revoke certificates. We need to find \
a solution to revocation and I think that Apache enabling OCSP stapling by default is \
the next step towards a solution.</div><div> <br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">The \
default configuration should not trigger unsolicited outgoing<br> queries to \
untrusted systems, for both a) and b), that's how I would<br> put \
it.</blockquote><div><br></div><div>Look at IIS, which has been doing OCSP stapling \
by default, without significant problems, for many years now. Has anybody really been \
harmed by IIS's default? I don't think so. I think this is an instance of the \
perfect being the enemy of the good.</div><div> <br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Additionally, \
features enabled by default need to have sufficient<br> coverage in the test \
framework.<br></blockquote><div><br></div><div>Again, I \
agree.</div><div><br></div><div>In case it would be helpful: When I was at Mozilla, \
my team created a new certificate verification library for Firefox. That includes a \
complete implementation of OCSP verification. It also includes a small test suite for \
OCSP verification. We intentionally licensed it under the Apache 2.0 license so that \
Apache could use the code, if Apache wants to use it. If nothing else, the OCSP tests \
[3] might be a useful model for Apache's tests.</div><div><br></div><div>After I \
left Mozilla, I separated out the implementation from Firefox's repository and \
made it available on GitHub: [1]. I spent some time making that code work with \
OpenSSL in a branch [2].</div><div><br></div><div>[1] <a \
href="https://github.com/briansmith/mozillapkix">https://github.com/briansmith/mozillapkix</a></div><div>[2] \
<a href="https://github.com/briansmith/mozillapkix/tree/feature/openssl">https://github.com/briansmith/mozillapkix/tree/feature/openssl</a></div><div>[3] \
<a href="https://github.com/briansmith/mozillapkix/blob/master/test/gtest/pkixocsp_Ver \
ifyEncodedOCSPResponse.cpp">https://github.com/briansmith/mozillapkix/blob/master/test \
/gtest/pkixocsp_VerifyEncodedOCSPResponse.cpp</a></div><div><br></div><div>Cheers,</div><div>Brian</div></div>-- \
<br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div \
dir="ltr"><div><a href="https://briansmith.org/" \
target="_blank">https://briansmith.org/</a></div><div><br></div></div></div></div></div></div></div>
</div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic