Open Bug 1815931 Opened 3 years ago Updated 3 years ago

consider treating stapled OCSP as an optimization

Categories

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

enhancement

Tracking

()

UNCONFIRMED

People

(Reporter: ra3r7o+5ejjce8je5mxs, Unassigned)

Details

(Whiteboard: [psm-backlog])

User Agent: Mozilla/5.0 (X11; OpenBSD amd64; rv:102.0) Gecko/20100101 Firefox/102.0

Steps to reproduce:

I browsed to the website https://tcm-mueller.berlin

Actual results:

I'm getting the following error:

An error occurred during a connection to tcm-mueller.berlin. The OCSP response does not include a status for the certificate being verified.

Error code: MOZILLA_PKIX_ERROR_OCSP_RESPONSE_FOR_CERT_MISSING

Expected results:

Website should show up normally as it does with many other browsers (e.g. chrome, safari).

This website uses ocsp stapling.

When I inspect the ocsp response that is stapled I can see that it is

  1. valid
  2. matches the serial number of the certificate in use
  3. uses hash algorithmn sha1

If required I'm happy to share instructions how to obtain all this information.

Is there a way to get more specific output from firefox about the origin of the error?

The Bugbug bot thinks this bug should belong to the 'Core::Networking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Networking
Product: Firefox → Core

Re-assigning it to the right component. I think the issue should be investigated by Security::PSM team.

Component: Networking → Security: PSM

(In reply to Reik from comment #1)

This website uses ocsp stapling.

When I inspect the ocsp response that is stapled I can see that it is

  1. valid

Actually it expired in January.

  1. matches the serial number of the certificate in use

It does not. The certificate in use has serial number 0376b0ad045810bcd0db30ca8e965fb183d5, whereas the OCSP response is for a certificate with serial number 0441d076ba90bef011c032bd2ddef9d486ab.

The website is misconfigured, but I'm going to take the opportunity to potentially rethink how Firefox treats stapled OCSP.

Severity: -- → N/A
Type: defect → enhancement
Priority: -- → P3
Summary: MOZILLA_PKIX_ERROR_OCSP_RESPONSE_FOR_CERT_MISSING → consider treating stapled OCSP as an optimization
Whiteboard: [psm-backlog]
Version: Firefox 102 → unspecified

It does not. The certificate in use has serial number 0376b0ad045810bcd0db30ca8e965fb183d5, whereas the OCSP response is for a certificate with serial number 0441d076ba90bef011c032bd2ddef9d486ab.

Thank you very much for your response. Would you allow me to learn how you obtained the certificate serial number from the OCSP response?

I used Wireshark and configured Firefox to log TLS secrets with the environment variable SSLKEYLOGFILE.

Ok I will try to resproduce what you did.

When I inspect the ocsp response file on the server the serial number matches the certificate:


cat file.ocsp | ocsptool --response-info

OCSP Response Information:
Response Status: Successful
Response Type: Basic OCSP Response
Version: 1
Responder ID: CN=R3,O=Let's Encrypt,C=US
Produced At: Wed Feb 08 15:06:00 UTC 2023
Responses:
Certificate ID:
Hash Algorithm: SHA1
Issuer Name Hash: 48dac9a0fb2bd32d4ff0de68d2f567b735f9b3c4
Issuer Key Hash: 142eb317b75856cbae500940e61faf9d8b14c2c6
Serial Number: 0376b0ad045810bcd0db30ca8e965fb183d5
Certificate Status: good
This Update: Wed Feb 08 15:00:00 UTC 2023
Next Update: Wed Feb 15 14:59:58 UTC 2023
Extensions:
Signature Algorithm: RSA-SHA256
...

This is what I'm seeing:

% ocsptool --response-info < stapled.ocsp 
OCSP Response Information:
	Response Status: Successful
	Response Type: Basic OCSP Response
	Version: 1
	Responder ID: CN=R3,O=Let's Encrypt,C=US
	Produced At: Wed Jan 11 01:00:00 UTC 2023
	Responses:
		Certificate ID:
			Hash Algorithm: SHA1
			Issuer Name Hash: 48dac9a0fb2bd32d4ff0de68d2f567b735f9b3c4
			Issuer Key Hash: 142eb317b75856cbae500940e61faf9d8b14c2c6
			Serial Number: 0441d076ba90bef011c032bd2ddef9d486ab

Perhaps there's a cache that needs to get refreshed? Or maybe the server needs restarting?

Hello and yes, after restarting the server it works again. It is not a Firefox but a server setup issue. This bug can be closed.

Before restarting the server I did try to debug and see the error myself:
Setting the SSLKEYLOGFILE env variable (e.g. to /tmp/file.log) and starting firefox did not write anything.
Is this a feature that needs to be enable at compile time?
Why are "TLS secrets" logging needed, shouldn't wireshark by itself be sufficient to log the data?

Answers to these questions are of course optional.

Thank you very much for your support. +1

One more note though: how come others browsers worked with the website?
Does it mean they do not correctly validate a stapled outdated ocsp response?

SSLKEYLOGFILE only works in pre-release versions of Firefox (Nightly, Beta).

TLS 1.3 encrypts as much of the TLS handshake as possible, so if you want to be able to inspect all of a handshake, it's helpful.

Chrome and other browsers are a bit more lenient with stapled OCSP information than Firefox is, and often choose to ignore issues with the given information rather than report them.

You need to log in before you can comment on or make changes to this bug.