932734 - If caching side channel OCSP information fails, don't fail certificate authentication

Status: RESOLVED INVALID

(Core :: Security: PSM, defect)

Description

[Kai Engert [:KaiE:]]

If caching side channel OCSP information fails, don't fail certificate authentication.
This suggestion was made in bug 932020.

As of today, PSM's AuthCertificate() does:

  if (stapledOCSPResponse) {
    rv = CERT_CacheOCSPResponseFromSideChannel();
    if (rv != SECSuccess) {
      return rv;
    }
  }

Suggestion is to ignore the return value and rather rely on the separate hard-fail settings for fresh revocation information.

Comment 1

[Dana Keeler (she/her) [:keeler]]

Wouldn't that violate the spec? (rfc6066 section 8 stipulates the client must terminate the connection if the response is "not satisfactory")

Comment 2

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

I think we shouldn't worry so much about whether we'd be violating that spec., because that spec. isn't very good, and it leaves out a lot of details we've had to figure out ourselves.

We want Firefox to be able to help developers debug OCSP stapling problems. The easiest way for us to do that, that doesn't require us to do a bunch of devtools work, is to simply fail the connection when we get a bad OCSP response. Server-side implementations seem to be doing some validation to prevent themselves from sending us bad responses anyway, except for expired responses. We will work around the expired response issue, hopefully just temporarily, in another bug.

So, I'd rather WONTFIX this.

Also, I think tstclnt should be changed to match the Firefox behavior, without the workaronud for expired responses. tstclnt is really an end-user testing tool and it is more useful for users to get these errors reported than it would be for tstclnt to fall back to fetching revocation information over the network when it receives a bad stapled OCSP response.

Comment 3

[Kai Engert [:KaiE:]]

(In reply to Brian Smith from comment #2)
> tstclnt is really an end-user
> testing tool and it is more useful for users to get these errors reported
> than it would be for tstclnt to fall back to fetching revocation information
> over the network when it receives a bad stapled OCSP response.

tstclnt already has an option to enforce the validation of side channel information, without falling back to actively fetching: "-T -F -M 1"
and to report the result (exit code).

-T                   Enable the cert_status extension (OCSP stapling).
-F                   Require fresh revocation info from side channel.
                     -F once means: require for server cert only
                     -F twice means: require for intermediates, too
                     (Connect, handshake with server, disable dynamic download
                      of OCSP/CRL, verify cert using CERT_PKIXVerifyCert.)
                     Exit code:
                     0: have fresh and valid revocation data, status good
                     1: cert failed to verify, prior to revocation checking
                     2: missing, old or invalid revocation data
                     3: have fresh and valid revocation data, status revoked
-M                   Test -F allows 0=any (default), 1=only OCSP, 2=only CRL

Comment 4

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

Gecko is working as intended here. If we find out that we're causing interop issues by being too strict, we can re-open this. AFAICT, the only thing we need to do is fall back to fetching when we get an expired-but-otherwise-Successful (Good,Unknown,Revoked) response. David, do you know which bug is tracking that?

Comment 5

[Dana Keeler (she/her) [:keeler]]

Looks like bug 929617.