Open Bug 803582 Opened 7 years ago Updated 1 year ago

Usage of OCSP fetching makes Firefox slow

Categories

(Core :: Security: PSM, enhancement, P3)

enhancement

Tracking

()

mozilla30

People

(Reporter: sfleiter, Unassigned)

References

(Depends on 2 open bugs, )

Details

(Keywords: parity-chrome, perf, privacy, Whiteboard: [psm-tracking][snappy])

I regularly read Taras Snappy Blog and have asked myself in which situations Firefox is slow for me using current Firefox Nightly builds.

I found out that reading mail in the web at http://www.web.de, a popular German mail provider, is slowed down by doing OCSP requests.
A simple login, switching to the mail view and a logout thereafter causes 18 OCSP requests.
According to the Charles HTTP Proxy all requests together lasted 41.18 seconds.
The fastest one lasted 16 ms, while the longest one lasted 10 seconds, mean time was 2.29 seconds.
All other requests lasted 1.08 seconds in total.
So OCSP request times totally dominate the load time of the pages.

Chrome fetches the revocation list asynchronously, so page load is not blocked by slow OCSP servers, see http://www.imperialviolet.org/2012/02/05/crlsets.html.

I marked this bug as [snappy] since this affects performance for every SSL site in Firefox, I hope this is ok.
I also added these OCSP bugs as dependencies which might improve the OCSP performance badness.


In the end I propose to discuss whether OCSP is still the right way to check revocation of SSL certificates or whether an asynchronous approach as chosen by Google Chrome would serve Firefox users better.
If it is decided to stay with OCSP its cost should be reduced as much as possible by fixing the dependent bugs.
After all the discussion on this, there are two unresolved issues still:

1. There are size/bandwidth constraints that mean we (and Chrome) cannot use CRLSet-like mechanisms for all revocations. So, besides revocations for intermediate CA certificates, and revocations that we know are due to mis-issuance, which revocations should be included in the asynchronous fetch? 

2. What do we do about the certificates that are not covered by the CRLSet-like mechanism? Do we require sites to opt in to guaranteed good performance (OCSP stapling), or do we require sites to opt out of the optimization to get their revocation fetching back (OCSP stapling with "must-staple" or similar)? And, if we require them to opt out of the optimization, on what time frame?
Component: Networking → Security: PSM
OS: Linux → All
Hardware: x86_64 → All
Summary: Usage of OCSP makes Firefox slow in comparison to Google Chrome → Usage of OCSP makes Firefox slow
Can I suggest something ?

Let's say Firefox supports OCSP stapling (which it currently does not ?). If I understand it correctly OCSP stapling only works for 1 certificate I believe and thus not the intermediates, right ?

Instead of querying (OCSP) or creating a list of revoked (CRL) certs.

Wouldn't it be easier to have a list of known good intermediates in Firefox which are updated regurlarly ? The chance of the an intermediate being revoked is probably a lot less anyway.

In that case if a site has OCSP stapling enabled and you have the list of known good intermediates, you don't need to go over the network anymore for these sites (performance problem solved ?).

Apache and OpenSSL both released stable versions with OCSP stapling support and Nginx now support OCSP stapling in their beta version. More sites are deploying HTTPS, many of them are also performance conscious.

Don't you think those sites will enable support for OCSP stapling if they knew servers and browsers support it ?
(In reply to Leen Besselink from comment #2)
> Wouldn't it be easier to have a list of known good intermediates in Firefox
> which are updated regurlarly ? The chance of the an intermediate being
> revoked is probably a lot less anyway.

We are already planning to handle the revocation of intermediates with a regularly-updated blacklist and/or whitelist of intermediates. Firefox effectively has a built-in blacklist of intermediates now; we don't do OCSP fetching for intermediates unless the user configures several things in about:config.

> Don't you think those sites will enable support for OCSP stapling if they
> knew servers and browsers support it ?
Depends on: 700693
No longer depends on: 360420
My mistake

Thanks for educating me.
Assignee: nobody → brian
Blocks: 771788
Severity: normal → enhancement
Depends on: 959026, 957665, 957667, 921907
Priority: -- → P2
Summary: Usage of OCSP makes Firefox slow → Usage of OCSP fetching makes Firefox slow
Target Milestone: --- → mozilla30
Assignee: brian → nobody
Whiteboard: [snappy], parity-chrome → [psm-tracking][snappy], parity-chrome
Tracking => P3
Priority: P2 → P3
I want to suggest to tidy up here a bit.

Depends on:
- add bug 1366100 <3
- close those legacy features bug 48597 (one can use a ServiceWorker) and bug 871954 as wontfix

Evaluate a MOSS project to fix OCSP Stapling for OCSP Must Staple in Nginx https://trac.nginx.org/nginx/ticket/812 and Apache
(or just call/write them and ask politely, maybe they would listen to you).

And if they listen to you, you could close this bug and the parent bug 771788 as fixed.

I found this bug after I saw https://twitter.com/TerraX_net/status/877230351323672576
and hope this comment is conform to https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Thank you for your great work <3.
Flags: needinfo?(dkeeler)
(In reply to Darkspirit from comment #6)
> - close those legacy features bug 48597 (one can use a ServiceWorker) and
> bug 871954 as wontfix

How do serviceworkers help with bug 48597? In any case, that's an NSS bug. NSS has different requirements from Firefox, so the NSS team may still want that feature (for that matter, we may still consider it for Firefox).

I agree bug 871954 is probably a wontfix, but I think we need to build a bit more organizational agreement on that.

> Evaluate a MOSS project to fix OCSP Stapling for OCSP Must Staple in Nginx
> https://trac.nginx.org/nginx/ticket/812 and Apache
> (or just call/write them and ask politely, maybe they would listen to you).

I recommend bringing this up on the moss mailing list: https://groups.google.com/forum/#!forum/mozilla.moss

> And if they listen to you, you could close this bug and the parent bug
> 771788 as fixed.

Bug 771788 is a bit orthogonal to this. In any case it's in the Firefox :: General component, so if they feel like it, they can close it.
Depends on: 1366100
Flags: needinfo?(dkeeler)
(In reply to David Keeler [:keeler] (use needinfo?) from comment #7)
> I recommend bringing this up on the moss mailing list:
> https://groups.google.com/forum/#!forum/mozilla.moss

MOSS doesn't drive projects in this way; someone would need to apply to MOSS to do the work. So the best place to start is the communities concerned.

Gerv
Keywords: parity-chrome
Whiteboard: [psm-tracking][snappy], parity-chrome → [psm-tracking][snappy]
Depends on: crlite
You need to log in before you can comment on or make changes to this bug.