Closed Bug 1681683 Opened 3 years ago Closed 3 years ago

Websites cannot be accessed with security.OCSP.require=true and network.trr.mode=3

Categories

(Core :: Networking: DNS, defect, P2)

Product:
Core
Component:
Networking: DNS
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
88 Branch
Tracking Flags:
Tracking Status
firefox83 --- wontfix
firefox84 --- wontfix
firefox85 --- wontfix
firefox88 --- fixed

People

(Reporter: cgeorgiu, Assigned: valentin, NeedInfo)

References

Details

(Whiteboard: [necko-triaged])

Attachments

(1 file)

Bug 1681683 - Exclude OCSP channels from using TRR in mode3 r=#necko
48 bytes, text/x-phabricator-request
Details | Review

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

  1. Launch Firefox on a clean profile.
  2. Set the following pref in about:config:
  • security.OCSP.enabled=1 (is default value)
  • security.OCSP.require=true
  • network.trr.mode=3
  1. Restart the browser.
  2. 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

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.

Flags: needinfo?(ciprian.georgiu)

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.

Flags: needinfo?(ciprian.georgiu)

(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?

Flags: needinfo?(valentin.gosu)

Could be a regression. Bug 1556194 was supposed to fix this exact scenario. Maybe something changed in the OCSP code.

Assignee: nobody → valentin.gosu
Severity: -- → S3
Flags: needinfo?(valentin.gosu)
Priority: -- → P2
Whiteboard: [necko-triaged]

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"

Ciprian, can you still reproduce this bug?

Flags: needinfo?(ciprian.georgiu)

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.

(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/

Flags: needinfo?(22f270b9-4713-4981-880d-eaf31fb1ce76)

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.

Flags: needinfo?(22f270b9-4713-4981-880d-eaf31fb1ce76)

(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).

Flags: needinfo?(ciprian.georgiu)

Otherwise the OCSP channel that tries to check the certificate for the DoH
server will also try to use TRR leading to DNS failures.

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

https://hg.mozilla.org/mozilla-central/rev/6a085bb3fdf1

Status: NEW → RESOLVED
Closed: 3 years ago
status-firefox88: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 88 Branch
Flags: qe-verify+

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?

Flags: qe-verify+ → needinfo?(sebp)

I'm happy to report I no longer experience this bug in Firefox 88.

See Also: → 1837621
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: