OCSP domain request go to system resolver even when network.trr.mode=3
Categories
(Core :: Networking: DNS, defect, P2)
Tracking
()
People
(Reporter: moviuro, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [necko-triaged])
Steps to reproduce:
In about:config, set network.trr.mode=3 and configure a DoH server.
I'm using Firefox 102.12.0esr on Win10
Actual results:
My local DNS server (not the DoH server) receives DNS requests from firefox for OCSP domains, such as:
- r3.o.lencr.org
- ocsp.digicert.com
- pki-goog.l.google.com
- zerossl.ocsp.sectigo.com
Expected results:
My local DNS server receives no DNS requests from firefox, as network.trr.mode=3 documentation says "Only. Only use TRR, never use the native resolver."; also the TRR is reachable.
|
||
Comment 1•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Networking: DNS' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 2•2 years ago
|
||
So, the reason we currently don't use DNS over HTTPS for OCSP requests is that there's a bootstrap problem.
Connect to DoH -> Do OCSP to verify the cert of the DoH server -> need to resolve domain name for OCSP check -> Connect to DoH
I do wonder if it's possible to bypass OCSP validation only for the DoH certificate only?
I've tried to follow the cert validation code back to necko, but I'm not sure if it's really possible to choose whether the OCSP check is performed on a per-channel basis.
@Dana, do you know if this would be possible without some horrible hack? :)
|
||
Comment 3•2 years ago
|
||
If Necko sets some sort of flag on the channel that PSM can check, we can pass FLAG_LOCAL_ONLY to CertVerifier, which means it won't do OCSP fetching (incidentally, this may be a more effective solution for things like PAC loading: https://searchfox.org/mozilla-central/rev/b91e9bef5a6d6f7b549fbc9cba70cb4665ed3866/security/manager/ssl/nsNSSCallbacks.cpp#245).
Description
•