OCSP responder key/certificate thoughts
Kyle Hamilton
having to do with CA and browser interaction policies are discussed.]
I'm trying to figure out how much of the OCSP slowness and server
underpowering is due to the sizes of the keys used, or limitations of
the HSMs (and drivers) that these systems are using. I'm not sure
what the standard key size for OCSP responders is (and this is
something that should likely be asked of the CAB Forum, or at the very
least the various CA representatives which hang out around
dev-security-policy). Large keys provide more security, at the expense
of a near-exponential time increase in having to generate and use them
(at least with RSA). The converse is that low-sized keys are much
more easily crackable, even if they're quicker to perform the
calculations with to respond appropriately and in a timely fashion.
OCSP requires that its certificate be issued by the issuer that it
serves data for. This means that offline roots can't easily be used
to create new OCSP responder certificates, even if it would be useful
to use, say, a 512-bit RSA key that's valid for only 30 minutes. (If
a CA pregenerated them for an entire year, it would only need to pull
out the root key once that year and batch-sign all the OCSP responder
certs, at the same time it was used to certify new intermediate CAs.)
The other part of the equation is, what if OCSP stapling were properly
implemented? Webservers could go out and fetch their OCSP status,
good until the expiration of the associated certificate, which (since
it would be controlled by the CA) could notify and permit software to
enforce its own period of liability for that response. (CRLs are
going to be slow, OCSP as an instant responder seems to not be working
as well as the designers hoped, so why not use OCSP as -- in addition
to everything else -- a means of ensuring that servers know their own
certificates' statuses and could trigger an alarm to the technical
team if they're found to be revoked for any reason? Why not give OCSP
responses the same time-to-show-up policy as CRLs? Why not even,
during the time that the current OCSP responder is valid, generate
OCSP responses for all certificates in the database with the
next-valid key, so that the load can always be kept up with?)
(Eddy Nigg, one of the regulars on dev-security-policy, has pointed
out that it is stupid to have OCSP responses served by HTTPS. They're
already signed by the OCSP certificate, which is usually provided with
the response; this suggests that OCSP responses could be pregenerated
and then served by something with a kernel HTTP daemon.)
-Kyle H
On Sat, Oct 10, 2009 at 8:05 AM, Boris Zbarsky <bzba...@mit.edu> wrote:
> On 10/10/09 10:47 AM, Alexander Konovalenko wrote:
>>
>> Why is security.OCSP.require option set to false by default?
>
> Because in practice the OCSP servers most CAs run are completely
> dysfunctional at worst (e.g. always return HTTP 500) and woefully
> underpowered at best. Some of them can handle something on the order of 1-2
> OCSP requests per second, last it was tested (when AMO ended up down because
> the CA couldn't handle the OCSP requests for it). So requiring it would
> actually mean that sites that use OCSP would just stop working (due to the
> browser effectively executing a DDOS on severs not set up to handle it).
>
>> A man-in-the-middle attacker sitting close to the client can easily
>> arrange for the OCSP server to be inaccessible.
>
> Yes, this is a problem. There's no good solution without CAs updating their
> OCSP setup, or Firefox implementing OCSP stapling, or likely both....
>
> -Boris
> _______________________________________________
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security
>
Eddy Nigg
> I'm trying to figure out how much of the OCSP slowness and server
> underpowering is due to the sizes of the keys used, or limitations of
> the HSMs (and drivers) that these systems are using.
>
Kyle, it's a myth, there are CAs having very responsive OCSP responders
out there....Verisign claims one billion responses per day, I know that
StartCom pushes out Gigabytes of responses per day and Comodo probably a
couple more. It works and OCSP is meant to be fast, not slow. Being a
tool to provide ONLINE and instant information as compared to CRLs with
their lag.
Having said that, CRLs depending on its size probably requires more
resources than an OCSP responder.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Rob Stradling
> On 10/13/2009 11:26 PM, Kyle Hamilton:
> > I'm trying to figure out how much of the OCSP slowness and server
> > underpowering is due to the sizes of the keys used, or limitations of
> > the HSMs (and drivers) that these systems are using.
I'm led to believe that "OCSP slowness" is the primary reason Google have been
reluctant to roll out HTTPS-by-default for all Gmail webpages. Wan-Teh
hinted to me recently that they've found network latency (for round-trips to
an OCSP Responder) to be the main cause of OCSP slowness.
It seems that browsers tend to wait until they've received all of the OCSP
responses they've requested before displaying the webpage, and Google
understandably don't want their webpages to appear to load slowly.
Widespread support for OCSP stapling would solve this latency problem.
> Kyle, it's a myth, there are CAs having very responsive OCSP responders
> out there....Verisign claims one billion responses per day, I know that
> StartCom pushes out Gigabytes of responses per day and Comodo probably a
> couple more. It works and OCSP is meant to be fast, not slow. Being a
> tool to provide ONLINE and instant information as compared to CRLs with
> their lag.
Agreed. Some CAs are already providing good quality OCSP services. ipsCA's
OCSP problems are most certainly *not* typical of all CAs.
> Having said that, CRLs depending on its size probably requires more
> resources than an OCSP responder.
--
Rob Stradling
Senior Research & Development Scientist
C·O·M·O·D·O - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com
Comodo CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.
Eddy Nigg
> I'm led to believe that "OCSP slowness" is the primary reason Google have been
> reluctant to roll out HTTPS-by-default for all Gmail webpages. Wan-Teh
> hinted to me recently that they've found network latency (for round-trips to
> an OCSP Responder) to be the main cause of OCSP slowness.
>
But isn't that a one-time ping happening once per day for the same
certificate? I know that Firefox caches the response for 24 hours, it
appears to me faster and more efficient than CRLs. Obviously there is a
latency to be taken into account, I think it's not avoidable.
Rob Stradling
> On 10/14/2009 08:55 AM, Rob Stradling:
> > I'm led to believe that "OCSP slowness" is the primary reason Google have
> > been reluctant to roll out HTTPS-by-default for all Gmail webpages.
> > Wan-Teh hinted to me recently that they've found network latency (for
> > round-trips to an OCSP Responder) to be the main cause of OCSP slowness.
>
> But isn't that a one-time ping happening once per day for the same
> certificate?
Yes (unless they've got multiple load-balanced webservers for the same domain
each with their own certificate).
> I know that Firefox caches the response for 24 hours, it
> appears to me faster and more efficient than CRLs. Obviously there is a
> latency to be taken into account, I think it's not avoidable.
But Google's point seems to be that that latency *is* avoidable today...by
avoiding using OCSP (or CRL) at all. And the way to avoid using OCSP (or
CRL) at all in this context is...avoid using SSL.
Once OCSP stapling support becomes widespread, there will be a way to avoid
the latency *and* have the revocation checking. I'm sure Google are aware of
this. The task of adding OCSP stapling support to NSS is currently assigned
to a Google developer:
See https://bugzilla.mozilla.org/show_bug.cgi?id=360420
Ian G
>> On 10/13/2009 11:26 PM, Kyle Hamilton:
>>> I'm trying to figure out how much of the OCSP slowness and server
>>> underpowering is due to the sizes of the keys used, or limitations of
>>> the HSMs (and drivers) that these systems are using.
>
> reluctant to roll out HTTPS-by-default for all Gmail webpages. Wan-Teh
> hinted to me recently that they've found network latency (for round-trips to
> an OCSP Responder) to be the main cause of OCSP slowness.
> responses they've requested before displaying the webpage, and Google
> understandably don't want their webpages to appear to load slowly.
That makes a lot of sense! Thanks for that.
If you think about the network design aspects of OCSP, it is highly
likely that it will be this way: just slow enough and just unreliable
enough to turn enough people off using HTTPS, resulting in ... less
protection! So it's long run success is in doubt.
The notion that you set up a connection in order to verify a connection
... should have been a clue. And that's without getting into the
contortions of european privacy discussions, which will add further pain :)
Pragmatically, I feel OCSP is an interim solution, in the big picture.
> Widespread support for OCSP stapling would solve this latency problem.
Right. The verification / update should piggy back.
What is the general status of stapling? Are we years away?
iang
Michael Ströder
> Having said that, CRLs depending on its size probably requires more
> resources than an OCSP responder.
That depends very much on the deployment scenario. IMHO there's no general
rule whether CRL or OCSP gives better performance or uses less resources.
Ciao, Michael.
Jean-Marc Desperrier
> The notion that you set up a connection in order to verify a connection
OCSP staple solves that.
The question I think is why there's so little manpower available around
to solve what looks like such essentials problems for the global SSL
architecture.
Eddy Nigg
Is it? It's a problem for the top sites perhaps, but those have the most
interest and manpower to solve it - so the question perhaps needs to be
directed to there....
Rob Stradling
<snip>
> What is the general status of stapling? Are we years away?
Quite a few clients already support OCSP stapling. e.g. IE7/8 on Windows
Vista, Opera 9/10, OpenSSL 0.9.8g and above (thanks to a grant from MoFo).
It's mainly server support that is lacking.
https://issues.apache.org/bugzilla/show_bug.cgi?id=43822 is still "NEW".
I'm not sure about IIS.
My concern is that even when there is widespread server and client support for
OCSP stapling, it may prove hard to persuade many webmasters to bother to
switch it on.
Ian G
thanks for that!
On 15/10/2009 18:10, Rob Stradling wrote:
> On Wednesday 14 October 2009 15:38:16 Ian G wrote:
> <snip>
>> What is the general status of stapling? Are we years away?
>
> Quite a few clients already support OCSP stapling. e.g. IE7/8 on Windows
> Vista, Opera 9/10, OpenSSL 0.9.8g and above (thanks to a grant from MoFo).
>
> It's mainly server support that is lacking.
> https://issues.apache.org/bugzilla/show_bug.cgi?id=43822 is still "NEW".
> I'm not sure about IIS.
Given the history of getting TLS/SNI into the servers, I'd say then we
are years away. TLS/SNI is now in httpd, and we're waiting for the
linux distros to absorb it.
> My concern is that even when there is widespread server and client support for
> OCSP stapling, it may prove hard to persuade many webmasters to bother to
> switch it on.
Good point.
On 15/10/2009 17:30, Jean-Marc Desperrier wrote:
> The question I think is why there's so
> little manpower available around
> to solve what looks like such essentials
> problems for the global SSL architecture.
I've wondered that too. I think the answer is that the manpower that is
available for this area is all directed to large corporate "solutions"
... e.g. token support. And this domination also works to exclude
others. Most people in open development world are either paid to do the
work because their employer sells the results, or they do it for fun
(which includes such things as academic interest, innovation, research),
and there's no fun in this world. It's only the corporates.
I'm not entirely convinced of this answer, but there's something like
that going on.
iang
Jean-Marc Desperrier
> My concern is that even when there is widespread server and client support for
> OCSP stapling, it may prove hard to persuade many webmasters to bother to
> switch it on.
I'd say it's doable if the configuration is autodiscovered and it just
needs to be set to "on" to work.
So that would be next to SSLCertificateFile a parameter that's just :
SSLCertificateOCSPStaple on
Saying to the webmasters "this makes your SSL site faster" could prove
persuasive.
Eddy Nigg
> Rob Stradling wrote:
>> My concern is that even when there is widespread server and client
>> support for
>> OCSP stapling, it may prove hard to persuade many webmasters to
>> bother to
>> switch it on.
>
> I'd say it's doable if the configuration is autodiscovered and it just
> needs to be set to "on" to work.
>
> So that would be next to SSLCertificateFile a parameter that's just :
> SSLCertificateOCSPStaple on
>
That sounds like a good idea!
Kyle Hamilton
perceived as having value.
In order to get said herd of users/sysadmins to flock the direction
you want, it must be perceived as having more than marginal value over
the current system.
But in order to *truly* affect the direction that things go, you must
simply apply the logic of the law of large numbers: large numbers
(every new copy -- and update -- that's downloaded) can have the new
support coded in. Once the number of downloaded versions becomes
large enough...
I might suggest that the Apache forum get a page ready for "why am I
getting complaints that my is my site suddenly so slow?" when
SSLCertificateOCSPStaple becomes the default in their configuration
files. I would also suggest that we be nice, give them some number of
months (I prefer 6) to change over, and then we turn on OCSP checking.
(This might also be a situation where Apache et al might choose to
proactively enable it, if "SSLCertificateOCSPStaple off" is not
found.)
There might be some added value to another process thread in the
server obtaining its next OCSP credential ahead of time, locking and
updating the shared stapled value without having to perform any kind
of rekeying sequence -- but that's either a server implementation or a
server library implementation issue.
-Kyle H
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
David E. Ross
> In order to get a herd of users to flock to your product, it must be
> perceived as having value.
>
> In order to get said herd of users/sysadmins to flock the direction
> you want, it must be perceived as having more than marginal value over
> the current system.
>
> But in order to *truly* affect the direction that things go, you must
> simply apply the logic of the law of large numbers: large numbers
> (every new copy -- and update -- that's downloaded) can have the new
> support coded in. Once the number of downloaded versions becomes
> large enough...
>
> I might suggest that the Apache forum get a page ready for "why am I
> getting complaints that my is my site suddenly so slow?" when
> SSLCertificateOCSPStaple becomes the default in their configuration
> files. I would also suggest that we be nice, give them some number of
> months (I prefer 6) to change over, and then we turn on OCSP checking.
> (This might also be a situation where Apache et al might choose to
> proactively enable it, if "SSLCertificateOCSPStaple off" is not
> found.)
>
> There might be some added value to another process thread in the
> server obtaining its next OCSP credential ahead of time, locking and
> updating the shared stapled value without having to perform any kind
> of rekeying sequence -- but that's either a server implementation or a
> server library implementation issue.
>
Slowness can be a significant issue. See
<http://www.useit.com/alertbox/timeframes.html>.
On the other hand, it might discourage unnecessary use of SSL with pages
that don't really have to be secure.
--
David E. Ross
<http://www.rossde.com/>
Go to Mozdev at <http://www.mozdev.org/> for quick access to
extensions for Firefox, Thunderbird, SeaMonkey, and other
Mozilla-related applications. You can access Mozdev much
more quickly than you can Mozilla Add-Ons.
Jean-Marc Desperrier
> I might suggest that the Apache forum get a page ready for "why am I
> [...]
> There might be some added value to another process thread in the
> server obtaining its next OCSP credential ahead of time, locking and
> updating the shared stapled value without having to perform any kind
> of rekeying sequence -- but that's either a server implementation or a
> server library implementation issue.
Come on. If the implementation doesn't find a way do that (a light way,
not creating another process thread), I'll beg the mod_ssl owner to
*not* deploy it.
OCSP staple has a meaning *only* if the OCSP response is prefetched, if
it gets the reputation of slowing down sites, it's dead.
Gervase Markham
> OCSP staple has a meaning *only* if the OCSP response is prefetched, if
> it gets the reputation of slowing down sites, it's dead.
Presumably it would only slow down the very first request (i.e. the one
on which the OCSP response was requested for the first time)?
Gerv
Eddy Nigg
Yes, supposed there is a cache time of 24 hours, that delay would be
negligible.
Nelson Bolyard
> OCSP requires that its certificate be issued by the issuer that it serves
> data for.
I'm not sure what that means. RFC 2560 requires that the signature on the
OCSP response be verifiable by the public key in a certificate that
meets any one of these three criteria:
1) Is the issuer (CA) cert that issued the cert whose revocation is being
checked, or
2) Is issued directly by the issuer (CA) cert that issued the cert whose
revocation is being checked and bears a special OCSP responder extended
key usage extension, or
3) Is configured and trusted locally by the relying party for OCSP.
> This means that offline roots can't easily be used to create new OCSP
> responder certificates, even if it would be useful to use, say, a 512-bit
> RSA key that's valid for only 30 minutes. (If a CA pregenerated them for
> an entire year, it would only need to pull out the root key once that
> year and batch-sign all the OCSP responder certs, at the same time it was
> used to certify new intermediate CAs.)
Offline roots CAN easily be used to create OCSP responder certs for
responders that send responses for certs issued by those roots.
Nelson Bolyard
Isn't it obvious?
There's no money in web servers to pay for that sort of development.
The sales of web servers that formerly funded development of NSS and
other SSL/TLS libraries have mostly dried up as customers have switched
to a free server.
David E. Ross
Has anyone looked into a grant from the U.S. Department of Homeland
Security for this?
Moudrick M. Dadashov
I'm sure it's not the only source for funding. As these things have
international importance, I'd suggest someone to take the initiative and
present initial info on the development efforts needed along with some
estimated costs.
Thanks,
M.D.
cell: +370-699-26662
Jean-Marc Desperrier
But then it becomes random wether or not it's delayed.
And in small scale testing it will often be delayed.
Do we have some stats for how long the response is marked as valid in
most OCSP server currently ?