Websites cannot be accessed with security.OCSP.require=true and network.trr.mode=3
Categories
(Core :: Networking: DNS, defect, P2)
Tracking
()
People
(Reporter: cgeorgiu, Assigned: valentin, NeedInfo)
References
Details
(Whiteboard: [necko-triaged])
Attachments
(1 file)
Affected versions
- latest Nightly 85.0a1
- RC1 84.0
- Release 83.0
Affected platforms
- Windows 10 x64
- macOS 10.15
- Ubuntu 18.04 x64
Steps to reproduce
- Launch Firefox on a clean profile.
- Set the following pref in
about:config
:
- security.OCSP.enabled=1 (is default value)
- security.OCSP.require=true
- network.trr.mode=3
- Restart the browser.
- Access any website by the hostname, e.g. https://www.google.com/
Expected result
- The website is correctly opened.
Actual result
- "Hmm. We’re having trouble finding that site.
We can’t connect to the server at www.google.com." message is displayed.
Suggested Severity
- S3, since this does appear to be an old issue.
Regression range
- Not a regression, I was able to reproduce the bug all to way back to Nightly 66.0a1 (Build ID 20181210220553).
Additional notes
- I filled this, based on the steps from bug 1556194 comment 36.
- Please observe the HTTP logs here https://drive.google.com/file/d/182v3EijASlBIkp9zWJMHIyezfKoee5pc/view?usp=sharing.
Comment 1•3 years ago
|
||
The log file is quite big and I can't find anything wrong in the log at the first look. It seems all requests to www.google.com are successful.
In addition, I also can't reproduce on my laptop.
Could you try to get the http log again? Please connect to a simple website this time. e.g., www.example.com. I think the log file should be smaller and easy to diagnose.
Thanks.
Reporter | ||
Comment 2•3 years ago
|
||
Sure, I hope this log file helps: https://drive.google.com/file/d/1H9JBWaEuSPNBeMUnriNCiUCZffzJ3Qz8/view?usp=sharing. Let me know if I can help with more info.
Comment 3•3 years ago
|
||
(In reply to Ciprian Georgiu [:ciprian_georgiu], Release Desktop QA from comment #2)
Sure, I hope this log file helps: https://drive.google.com/file/d/1H9JBWaEuSPNBeMUnriNCiUCZffzJ3Qz8/view?usp=sharing. Let me know if I can help with more info.
Thanks for the log. This really helps a lot.
The log shows that all http connections to trr server failed because of the error code below. It seems -8071
is SEC_ERROR_OCSP_SERVER_ERROR
.
2020-12-15 15:55:41.093000 UTC - [Parent 11048: Socket Thread]: D/nsSocketTransport ErrorAccordingToNSPR [in=-8071 out=805a1f87]
Valentin, do you have any idea here?
Assignee | ||
Comment 4•3 years ago
|
||
Could be a regression. Bug 1556194 was supposed to fix this exact scenario. Maybe something changed in the OCSP code.
I had the same issue, where I was getting SEC_ERROR_OCSP_SERVER_ERROR when accessing google.com. What eventually fixed it for me was going to the Network Settings, and changing from "Auto-detect proxy settings for this network" to "Use system proxy settings"
Assignee | ||
Comment 6•3 years ago
|
||
Ciprian, can you still reproduce this bug?
Comment 7•3 years ago
|
||
Not Ciprian but I can reproduce this bug 100% of the time on my system. Arch Linux, 5.4 kernel (also reproducible on 5.10 kernel, not that I expect the kernel to matter), Firefox version 85.0.2. Just tried it with a fresh Firefox profile and setting security.OCSP.require=true and network.trr.mode=3.
Assignee | ||
Comment 8•3 years ago
|
||
(In reply to 22f270b9-4713-4981-880d-eaf31fb1ce76 from comment #7)
Not Ciprian but I can reproduce this bug 100% of the time on my system. Arch Linux, 5.4 kernel (also reproducible on 5.10 kernel, not that I expect the kernel to matter), Firefox version 85.0.2. Just tried it with a fresh Firefox profile and setting security.OCSP.require=true and network.trr.mode=3.
Could you try with the latest Nightly? https://nightly.mozilla.org/
Comment 9•3 years ago
|
||
It's reproducible with the latest Nightly, and it's even worse. With 85.0.2, if security.OCSP.require=true at startup, I can at least temporarily set it to false, visit a page, and then reenable security.OCSP.require and have all sites load successfully afterwards. With the nightly, I must keep security.OCSP.require off while network.trr.mode is set to 3.
Reporter | ||
Comment 10•3 years ago
|
||
(In reply to Valentin Gosu [:valentin] (he/him) from comment #6)
Ciprian, can you still reproduce this bug?
Yes, it is also reproducible on my end with the same steps from comment 0. I've checked on macOS 10.15, running latest Nightly 87.0a1 (2021-02-17).
Assignee | ||
Comment 11•3 years ago
|
||
Otherwise the OCSP channel that tries to check the certificate for the DoH
server will also try to use TRR leading to DNS failures.
Comment 12•3 years ago
|
||
Pushed by valentin.gosu@gmail.com: https://hg.mozilla.org/integration/autoland/rev/6a085bb3fdf1 Exclude OCSP channels from using TRR in mode3 r=necko-reviewers,kershaw
Comment 13•3 years ago
|
||
bugherder |
Updated•3 years ago
|
Updated•3 years ago
|
Comment 14•3 years ago
|
||
Tried reproducing the issue but was unsuccessful, Ciprian as well on the affected builds under macOS 10.15 / 11 and Ubuntu 20.04.
Sebp, are you still able to reproduce it on the affected builds? And if so, could you then verify if it has been fixed on the latest build?
Comment 15•3 years ago
|
||
I'm happy to report I no longer experience this bug in Firefox 88.
Description
•