643907 - HSTS sites for which we lack a recent valid OCSP response should be blocked

Status: RESOLVED INVALID

(Core :: Security: PSM, defect)

Description

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

If we have do not have an affirmative OCSP response for a site that is less than X minutes old (where X is yet to be determined), we should treat the lack of an OCSP response as an error for all HSTS-enabled sites, and/or all HSTS sites with certs for which we know and/or can discover OCSP responders. (The difference is whether or not we want HSTS to work for certs issued by CAs that don't have known/discoverable OCSP responders.)

Comment 1

[Jacob Appelbaum]

How is this supposed to be handled for EV certs?

Firefox appears to simply downgrade the UI indicators (with a small warning icon) but not actually hard fail.

Comment 2

[Sid Stamm [:geekboy or :sstamm]]

If we fix this bug: any EV or non-EV connection that uses HSTS will be blocked (cert fail) on lack of positive OCSP response, not UI-downgraded.  Fixing this bug won't change behavior for EV sites that don't use HSTS.

Comment 3

[Adam Langley]

This is currently the case in Chrome, although that might be a mistake. We currently have a few Google subdomains running in HSTS mode (in Chrome) and tying our fate to the serving ability of our CA is a little bit terrifying.

Comment 4

[Sid Stamm [:geekboy or :sstamm]]

I think requiring fresh OCSP responses for HSTS is less scary if we implement OCSP stapling along side fixing this bug.

Comment 5

[Adam Langley]

OCSP stapling for NSS exists in the Chromium tree if you want it. However, OCSP stapling doesn't work.

One can only staple a single OCSP response and nearly everybody has a chained certificate these days. Even if OCSP stapling were extended to include two responses, they're so large (1-2KB) that it would overflow the initial congestion window. One can open up an initcwnd, but many clients enforce the standard initcwnd with the flow window. We also don't want to be sending that much extra data if possible.

Comment 6

[Daniel Veditz [:dveditz]]

The spec justification for this is from
http://tools.ietf.org/id/draft-ietf-websec-strict-transport-sec-01.txt

   7.3.  Errors in Secure Transport Establishment

   When connecting to a Known HSTS Host, the UA MUST terminate the
   connection with no user recourse if there are any errors (e.g.
   certificate errors), whether "warning" or "fatal" or any other error
   level, with the underlying secure transport.

where lack of OCSP response is interpreted as an "error ... with the underlying secure transport". I'm not sure that's what the spec authors had in mind, but it is certainly one way to look at it.

(In reply to comment #1)
> How is this supposed to be handled for EV certs?
> 
> Firefox appears to simply downgrade the UI indicators (with a small warning
> icon) but not actually hard fail.

Whether EV requires an OCSP response or not is an orthogonal issue and should be handled in a separate bug, although both bugs may require common back-end work to surface the certificate issues up to higher layers.

Simply switching the OCSP requirement on for all TLS connections would be an alternate fix for this bug (or make it obsolete, depending on how you want to look at it).

(In reply to comment #0)
> (The difference is whether or not we want HSTS to work for certs issued
> by CAs that don't have known/discoverable OCSP responders.)

We do. The site owners asked for HSTS and also chose a cert with no OCSP responder. Why does one choice negate the other?

Comment 7

[Adam Langley]

Chrome will be going the other way on this: i.e. we are going to make revocation check failures non-fatal for HSTS sites.

I understand that some will view this as a mistake but several Google properties are already HSTS and we would like to deploy more. However, there's just no way that we could tenably end up in a position where Gmail is down because a server that we don't control is down and we don't know when it'll be back up.

(Admittedly, this is already the case with the gTLD/root DNS servers. However, we believe that these services are sufficiently robust and we don't have much of a choice.)