consider treating stapled OCSP as an optimization
Categories
(Core :: Security: PSM, enhancement, P3)
Tracking
()
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
- valid
- matches the serial number of the certificate in use
- 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?
Comment 2•3 years ago
|
||
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.
Comment 3•3 years ago
|
||
Re-assigning it to the right component. I think the issue should be investigated by Security::PSM team.
Comment 4•3 years ago
|
||
(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
- valid
Actually it expired in January.
- 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.
It does not. The certificate in use has serial number
0376b0ad045810bcd0db30ca8e965fb183d5, whereas the OCSP response is for a certificate with serial number0441d076ba90bef011c032bd2ddef9d486ab.
Thank you very much for your response. Would you allow me to learn how you obtained the certificate serial number from the OCSP response?
Comment 6•3 years ago
|
||
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
...
Comment 8•3 years ago
|
||
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
| Reporter | ||
Comment 10•3 years ago
|
||
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?
Comment 11•3 years ago
|
||
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.
Description
•