Add option security.OCSP.require about privacy-settings HOT 8 OPEN

Since I am still not sure how Firefox is responding to invalid responses, I have no idea what should we recommend to users in the advance panel

My recommended settings for...

security.OCSP.enabled:

• For security, 1.
• For privacy, 0.
• For compatibility, either. It soft-fails (gracefully).

Descriptions of values: http://kb.mozillazine.org/About:config_entries#Security.

security.OCSP.require can be set to true to have Firefox terminate the connection instead.
Source: https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/

As of Firefox 41, Firefox will not do “live” (CA) OCSP queries for sufficiently short-lived certs (with a lifetime shorter than the value set in “security.pki.cert_short_lifetime_in_days”). Instead, Firefox will just assume the certificate is valid. There is currently no default threshold set, so users need to configure it. We are collecting telemetry on certificate lifetimes, and expect to set the threshold somewhere around the maximum OCSP response lifetime specified in the baseline requirements.
Source: https://blog.mozilla.org/security/2015/11/23/improving-revocation-ocsp-must-staple-and-short-lived-certificates/

security.OCSP.require:

• For security, true.
• For privacy, false.
• For compatibility, false.

Overall, I think it is unfortunately best for security.OCSP.require = false to be the recommended default at the present time because the current low adoption of OCSP by websites and its latency causes a true to break some sites. The privacy recommendation could be true if enable_ocsp_stapling = true and must_staple = true and if the fallback behavior of must_staple was not dependent on whether the certificate of the website has the Must-Staple extension, but it is dependent. More on that below.

security.ssl.enable_ocsp_stapling:

• For security, true.
• For privacy, if must_staple = true, then true. Else, false.
• For compatibility, either. It soft-fails (gracefully falls back to normal OCSP) if must_staple = false or the certificate does not have the Must-Staple extension.

The privacy category depends on the state of must_staple. This should be reflected in the interface somehow.

“OCSP-must-staple” [gives] sites a way of saying “any connection to this site must include a stapled OCSP response”. This is still in development.
Source: https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/

Must-Staple [lets] sites opt in to hard failures.... When a CA adds this extension to a certificate, it requires your browser to ensure a stapled OCSP response is present in the TLS handshake. If an OCSP response is not present, the connection will fail and Firefox will display a non-overridable error page.
Source: https://blog.mozilla.org/security/2015/11/23/improving-revocation-ocsp-must-staple-and-short-lived-certificates/

The OCSP must-staple extension for certificates [allows] the browser to fail if a stapled OCSP response is not present.... a certificate with this extension will never have a live OCSP lookup (at least for browsers that support the extension).
Source: https://wiki.mozilla.org/CA:RevocationPlan#OCSP_must-staple

Websites that implement OCSP Must-Staple will get Hard Fail Revocation. A website may use OCSP Must-Staple to mandate support for revocation checking via OCSP stapling. A site that tells clients that an OCSP status response will always be stapled enables the browser to immediately stop processing when the response is not stapled.
Source: https://wiki.mozilla.org/CA:ImprovingRevocation#OCSP_Must-Staple

Those quotes mean that Firefox only has partial say on security and privacy with the Must-Staple extension because Firefox's behavior is also dependent on the website's certificate. Even if Firefox has stapling and must_staple enabled, if the certificate does not have the Must-Staple extension, Firefox will fall back to normal OCSP. As far as I know, there is no setting that gives Firefox total control to hard-fail immediately if the certificate does not have the stapling extension. That somewhat complicates the decision for recommendations. Other browsers may have different criteria and settings for fallback behavior. I have not read the IETF's specifications for the Must-Staple extension -- rfc7633, rfc6066, and rfc6961 -- to know if Firefox's fallback behavior is mandated in those specifications for all browsers.

security.ssl.enable_ocsp_must_staple:

• For security, true.
• For privacy, true. This setting only applies to certificates that have Must-Staple. Certificates without it would make Firefox use normal OCSP anyway.
• For compatibility, either. If a certificate has Must-Staple, the website should be by definition prepared to handle requests and not break.

In an ideal world, the browser would perform an online status check (such as OCSP) whenever it verifies a certificate, and reject the certificate if the check failed.
Source: https://blog.mozilla.org/security/2015/11/23/improving-revocation-ocsp-must-staple-and-short-lived-certificates/

In the long run, we would like to make live OCSP checks hard-fail by default when the browser is unable to reach an OCSP responder.
Source: https://wiki.mozilla.org/CA:RevocationPlan#Hard-fail_Measurement_.26_Enablement

OCSP responders are not yet reliable enough for us to do hard fail. OCSP stapling will help to make hard-fail possible. Must-Staple will be a way to opt into hard-fail.
Source: https://wiki.mozilla.org/CA:ImprovingRevocation#Changes_In_Progress

Any of my recommendations may change if the behavior of the settings in Firefox is modified or new settings are introduced (or if I misunderstood something somewhere).

from privacy-settings.

OCSP has a few drawbacks. First, it slows down new HTTPS connections. When the browser encounters a new certificate, it has to make an additional request to a server operated by the CA. Second, it leaks to the CA what HTTPS sites the user visits, which is concerning from a privacy perspective. Additionally, if the browser cannot connect to the CA, it must choose between two undesirable options. It can terminate the connection on the assumption that something is wrong, which decreases usability. Or, it can continue the connection, which defeats the purpose of doing this kind of revocation checking.

Noting these drawbacks, I am not sure if this is a must have. What do you think?

from privacy-settings.

The excerpt you quoted is about old, non-stapled OCSP, and I agree that its drawbacks are concerning. However:

OCSP stapling resolves both problems in a fashion reminiscent of the Kerberos Ticket. In a stapling scenario, the certificate holder queries the OCSP server themselves at regular intervals, obtaining a signed time-stamped OCSP response. When the site's visitors attempt to connect to the site, this response is included ("stapled") with the TLS/SSL Handshake via the Certificate Status Request extension response (note: the TLS client must explicitly include a Certificate Status Request extension in its ClientHello TLS/SSL handshake message). While it may appear that allowing the site operator to control verification responses would allow a fraudulent site to issue false verification for a revoked certificate, the stapled responses can't be forged as they need to be directly signed by the certificate authority, not the server. If the client does not receive a stapled response [from the certificate holder], it will just contact the OCSP server (the CA) by itself. However, if the client receives an invalid stapled response, it will abort the connection. The only increased risk of OCSP stapling is that the notification of revocation for a certificate may be delayed until the last-signed OCSP response expires.

As a result, clients continue to have verifiable assurance from the certificate authority that the certificate is presently valid (or was quite recently), but no longer need to individually contact the OCSP server. This means that the brunt of the resource burden is now placed back on the certificate holder. It also means that the client software no longer needs to disclose users' browsing habits to any third party (CA).

Overall performance is also improved: When the client fetches the OCSP response directly from the CA, it usually involves the lookup of the domain name of the CA's OCSP server in the DNS as well as establishing a connection to the OCSP server. When OCSP stapling is used, the certificate status information is delivered to the client through an already established channel, reducing overhead and improving performance.

As said in the original post, OCSP stapling favors privacy and security, but the fallback behavior may change that. I am concerned about the statement, "If the client does not receive a stapled response [from the certificate holder], it will just contact the OCSP server (the CA) by itself." If Firefox falls back to non-stapled OCSP, the setting would have less value in Privacy Settings. This relates to the last point in your quote that is about non-stapled OCSP:

if the browser cannot connect to the CA, it must choose between two undesirable options. It can terminate the connection on the assumption that something is wrong, which decreases usability. Or, it can continue the connection, which defeats the purpose of doing this kind of revocation checking.

If Firefox falls back for invalid responses on every one of the three tiers, the sequence would be:

1. Attempt stapled OCSP (security and privacy)
2. Attempt old, non-stapled OCSP (security only)
3. Use the certificate without checking its revocation status (privacy only -- Relative to the tiers before it. All of the tiers have more security relative to connections without SSL, but the criteria I am using is only relative to connections with SSL.)

By default, that is what it does because security.OCSP.require = false.

Stapling is the most secure and private of the configurations, but we must find out what exactly Firefox does when it receives an invalid response. Under what conditions does it fall back or close the connection? Ideally, stapling would be required, and Firefox would terminate the connection for any non-'good' stapled response or invalid response, ensuring both privacy and security. One of the settings for stapling, security.ssl.enable_ocsp_must_staple, sounds like it is the stapling analogue to security.OCSP.require, but it may not actually be so, as I said in the original post. What does it actually do? I am not sure. My research has been inconclusive. We must find out.

If Firefox falls back to non-stapled OCSP on an invalid staple, privacy is sacrificed because it would then contact a third-party CA, but security may be preserved as long as security.OCSP.require = true. (It is false by default.) The setting prevents Firefox from falling back to not using OCSP at all, meaning that if the setting is true and it receives any non-'good' OCSP response, the connection will be terminated. Another problem here is that we don't know whether that setting also prevents the stapling tier (if stapling is enabled) from falling back to this tier, non-stapled OCSP. Which tier(s) does the setting affect? I am not sure. My research has been inconclusive. We must find out.

If Firefox attempts the non-stapled OCSP tier and security.OCSP.require = false (default) and it receives an invalid OCSP response, it will fall back to not using OCSP which would sacrifice security but preserve privacy because it would not check revocation status but not contact a third-party CA.

from privacy-settings.

Thanks for the clarification.
This sounds like a good fit to #42

from privacy-settings.

format of the advanced panel;

What we need:

security.ssl.enable_ocsp_stapling

• description: enable OCSP stapling
• true: Enable OCSP stapling (default)
• false: Disable OCSP stapling
• recommended value: true
• link: https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/
• tag: security and privacy

security.ssl.enable_ocsp_must_staple

• description: OCSP must be stapled
• true: ... (default)
• false: ...
• recommended value: ?
• link: https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/
• tag: security and privacy

security.OCSP.require

• description: Require certificate revocation check through OCSP protocol
• true: Check for certificate revocations (may break some websites like YouTube)
• false: Do not check for certificate revocations (default)
• recommended value: ?
• link: https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/
• tag: security and privacy

security.OCSP.enabled

• description: Query OCSP responder servers to confirm current validity of certificates
• 0: Disabled
• 1: Validate only certificates that specify an OCSP service URL (default)
• 2: Enable and use values in security.OCSP.URL and security.OCSP.signing
• recommended value: 1
• link: https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/
• tag: security and privacy

@ipatjolvur Since I am still not sure how Firefox is responding to invalid responses, I have no idea what should we recommend to users in the advance panel; see: http://www.ghacks.net/2015/08/18/a-comprehensive-list-of-firefox-privacy-and-security-settings/

@Gitoffthelawn, @berrythesoftwarecodeprogrammar, @jomo: any feedback on this?

from privacy-settings.

I apologize, I'm overbooked right now. Overall, I can say you are going in the right direction.

from privacy-settings.

current implementation of OCSP prefs;

For now the extension is recommending the defaults...

from privacy-settings.

This option is good, but isn't always implemented and it's badly managed.

Meanwhile related implementations are changed for motives totally unrelated to security.

The problems come from the various Certificates and the various errors that come from them (either from their issues or the servers that manage them).

Related: pyllyukko/user.js#246

from privacy-settings.