1770123 - (CVE-2022-34472) Firefox allows user to visit webpages with revoked certificate when non-resolving proxy is set

Status: VERIFIED FIXED

(Core :: Networking, defect, P2)

Description

[Laurent Bigonville]

Hello

On my work laptop, I've a proxy setup (via a .pac file) in GNOME configuration. In Firefox, the configuration is set to use the system settings.

With the proxy is setup (when I'm disconnected from the VPN, the pac file or the proxy is not reachable, so it doesn't seem to matter if the proxy is actually used) if I go to https://revoked.badssl.com/ I get a red scary page telling me that I shouldn't be seeing this.

As soon as I disable the proxy in the GNOME configuration, I'm getting the SEC_ERROR_REVOKED_CERTIFICATE as expected.

Comment 1

[Dana Keeler (she/her) (use needinfo) [:keeler]]

Is your proxy blocking OCSP? (port 80)

Comment 2

[Laurent Bigonville]

I've the same issue when I'm at home and not connected to the company VPN and there port OSCP/80 is definitely not blocked

Comment 3

[Dana Keeler (she/her) (use needinfo) [:keeler]]

What's the value of security.OCSP.enabled in about:config?
What does Firefox do if you set security.OCSP.require to true?
Can you capture the packets of the handshake (and any OCSP requests) with https://revoked.badssl.com/ using Wireshark and attach the results here?
Thanks!

Comment 4

[Laurent Bigonville]

security.OCSP.enabled is set to 1

With the proxy set via a pac file, but nor the pac file nor the proxy is reachable (not at the office or connected via the VPN):

• When I'm forcing security.OCSP.require to true, I get the SEC_ERROR_OCSP_SERVER_ERROR for https://revoked.badssl.com/. I also get the same error when browsing to google.com

• When I'm forcing security.OCSP.require to true, going to my own website that has https via let's encrypt with OCSP stapling, it works. If I disable the security.ssl_enable_ocsp_stapling, my website become unreachable with the SEC_ERROR_OCSP_SERVER_ERROR error

• I don't see any call to the OCSP server (http://ocsp.digicert.com, IP: 93.184.220.29)

So really, if a proxy is set, direct queries to the OCSP server are disabled completely. I doubt it's that the expected behavior?

Comment 5

[Dana Keeler (she/her) (use needinfo) [:keeler]]

It's expected that OCSP requests don't occur while the PAC is loading, but they should happen when it's done loading (or presumably when it fails to load and Firefox continues without it).
Kershaw, any ideas as to if this is behaving correctly?

Comment 6

[Kershaw Chang [:kershaw]]

Hi Reporter,

Could you try to capture a http log for this?
Please also add pipnss:5,proxy:5 to MOZ_LOG environment variable.

Thanks.

Comment 7

[Laurent Bigonville]

Attachment: log.txt-main.25435.moz_log.gz

Hello,

I can reproduce this by literally setting http://proxy.example.com/proxy.pac as a pac file directly in firefox

I've attached the requested logs

Comment 8

[:Gijs (he/him)]

Moving this out of the Fx frontend product as this seems like a necko/tls issue.

Comment 9

[Daniel Veditz [:dveditz]]

What's happening makes sense, the question is how do we best help users? Warn them when their specified proxy isn't loading? Or maybe we just aren't communicating that the PAC loading failed back to the OCSP checking code?

Comment 10

[Laurent Bigonville]

So if I understand properly, when the proxy is reachable, the OCSP validation is not done by Firefox but is supposed to be delegated to the proxy?

Comment 11

[Dana Keeler (she/her) (use needinfo) [:keeler]]

No, if the proxy is reachable, OCSP requests should still occur.

Comment 12

[Laurent Bigonville]

I'm asking because that doesn't seem to happen either

I'll have to get the logs when I'm able to connect to the proxy also then

Comment 13

[Laurent Bigonville]

Attachment: log.txt-main.172064.moz_log.gz

Logs when the connection to the proxy succeed

Comment 14

[Laurent Bigonville]

Scratch my last comment (comment 12 and 13), the proxy is doing MITM by replacing the certificate but does not add OCSP information to it.

Comment 15

[Dana Keeler (she/her) (use needinfo) [:keeler]]

Kershaw, is this just bug 1639914? (see in particular bug 1639914 comment 4)

Comment 16

[Kershaw Chang [:kershaw]]

(In reply to Dana Keeler (she/her) (use needinfo) (:keeler for reviews) from comment #15)

Kershaw, is this just bug 1639914? (see in particular bug 1639914 comment 4)

No, I think the problem in this bug is not about pac request being cancelled.

I think the problem is in comment #4:

When I'm forcing security.OCSP.require to true, going to my own website that has https via let's encrypt with OCSP stapling, it works. If I disable the security.ssl_enable_ocsp_stapling, my website become unreachable with the SEC_ERROR_OCSP_SERVER_ERROR error

Why does the reporter's website work when the proxy is not reachable?
I am guessing maybe the content is loaded from cache.

Reporter, the log file is not completed because you only set MOZ_LOG to pipnss:5,proxy:5. We need to turn on more logging.
In this case, I think setting MOZ_LOG to nsHttp:5,cache2:5,nsSocketTransport:5,nsHostResolver:5,pipnss:5,proxy:5 should be enough.
Could you try to capture the log again? Thanks.

Comment 17

[Laurent Bigonville]

Attachment: log.txt-main.378256.moz_log.gz

I really don't think this has anything to do with the cache.

Forcing OCSP (via security.OCSP.require) and then toggling security.ssl_enable_ocsp_stapling prevents me (or not) to access my personal website.

You cannot reproduce this behavior on your side?

Comment 18

[Laurent Bigonville]

Attachment: log.txt-child.378784.moz_log

Comment 19

[Laurent Bigonville]

When the pac file is not reachable, firefox tries to connect directly: D/proxy pac not available, use DIRECT

Comment 20

[Kershaw Chang [:kershaw]]

(In reply to Laurent Bigonville from comment #17)

Created attachment 9278822 [details]
log.txt-main.378256.moz_log.gz

I really don't think this has anything to do with the cache.

Forcing OCSP (via security.OCSP.require) and then toggling security.ssl_enable_ocsp_stapling prevents me (or not) to access my personal website.

Thanks for the log. It shows Firefox sending one ocsp request.

[Parent 378256: SSL Cert #2]: D/pipnss DoOCSPRequest to 'http://r3.o.lencr.org'

Dana, do you have any idea here? Why toggling security.ssl_enable_ocsp_stapling makes difference?

Comment 21

[Dana Keeler (she/her) (use needinfo) [:keeler]]

Disabling OCSP stapling means the server won't include OCSP information in the TLS handshake, so Firefox won't have any OCSP information (assuming fetching OCSP is failing, which it looks like is happening). Combining that with security.OCSP.require would prevent you from reaching sites, as expected.

This bug is getting a bit confusing to me - you've outlined a number of different scenarios, and it's unclear to me what's happening and what you're expecting to happen. Can you maybe lay out the configurations you're concerned about in an ordered fashion?

Also, again, it would be very helpful to have a packet trace to see what requests Firefox is making and what responses it's getting. Thank you!

Comment 22

[Laurent Bigonville]

Attachment: log.txt-main.71082.moz_log.gz

Well not sure what's confusing here, when the pac file is not reachable, firefox is not sending any OCSP requests, I can reproduce that 100% of the time here. pac file not being reachable can happen often when people are using a corporate computer and not connected to their VPN or not being inside the corporate network

Anyway where what I'm doing:

1. Create an empty profile
2. Set the proxy to http://proxy.example.com:8080/proxy.pac
3. Set security.OCSP.require to true
4. Set security.ssl.enable_ocsp_stapling to false
5. Go to https://bigon.be
6. Website is not reachable (SEC_ERROR_OCSP_SERVER_ERROR error)
7. Set security.ssl.enable_ocsp_stapling to true
8. Go to https://bigon.be again
9. Website is reachable

That seems to suggest that OCSP is not completely broken, just OCSP requests are not being done as the proxy is not reachable

Comment 23

[Laurent Bigonville]

Attachment: log.txt-child.71812.moz_log

Comment 24

[Laurent Bigonville]

Attachment: ocsp.pcapng.gz

I attach here the capture my last attempt

I used the following filter: (ipv6.addr == 2001:bc8:25f1:100::1 and tcp.port == 443) or ocsp

As you can see, no OCSP requests are made

When disabling the proxy, I can see the OCSP requests being made again

Comment 25

[Kershaw Chang [:kershaw]]

Attachment: Bug 1770123 - Clear PAC loader when the load is failed, r=#necko

Comment 26

[Kershaw Chang [:kershaw]]

I found a problem that GetIsPACLoading always returns true when the pac is not reachable. This blocks sending ocsp request here.

Comment 27

[Daniel Veditz [:dveditz]]

If the PAC is actually loading we don't want to send OCSP because it's quite possible the OCSP request is for the PAC file itself. So it'd really be nice to know the difference between actually-loading and failed-loading.

Especially so if we've decided to let other network requests continue without waiting for the PAC to load.

This probably isn't that useful as an attack vector so maybe we can unhide the bug.

Comment 28

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Clear PAC loader when the load is failed, r=necko-reviewers,dragana
https://hg.mozilla.org/integration/autoland/rev/f6c203dbc605c69887d1547d5e89f4fb44c9ffcc
https://hg.mozilla.org/mozilla-central/rev/f6c203dbc605

Comment 29

[Mike Kaply [:mkaply]]

Should we uplift this to 102?

Comment 30

[Kershaw Chang [:kershaw]]

(In reply to Mike Kaply [:mkaply] from comment #29)

Should we uplift this to 102?

I can uplift this, since the change is not risky.

Comment 31

[Kershaw Chang [:kershaw]]

Comment on attachment 9279092 [details]
Bug 1770123 - Clear PAC loader when the load is failed, r=#necko

Beta/Release Uplift Approval Request

• User impact if declined: If there is a PAC URL set and the server that hosts the PAC is not reachable, OCSP requests are blocked.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: N/A
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This change is straightforward.
• String changes made/needed: N/A
• Is Android affected?: Yes

Comment 32

[Pascal Chevrel:pascalc]

Comment on attachment 9279092 [details]
Bug 1770123 - Clear PAC loader when the load is failed, r=#necko

Approved for 102 beta 6, thanks.

Comment 33

[Pascal Chevrel:pascalc]

https://hg.mozilla.org/releases/mozilla-beta/rev/c351fdbdb221

Comment 34

[Pascal Chevrel:pascalc]

Is that something we should uplift to the ESR 91 branch as well? ESR 102 will inherit from the uplift to the 102 beta branch.

Comment 35

[Kershaw Chang [:kershaw]]

(In reply to Pascal Chevrel:pascalc from comment #34)

Is that something we should uplift to the ESR 91 branch as well? ESR 102 will inherit from the uplift to the 102 beta branch.

Sure, I think we can also uplift to ESR 91.
Thanks.

Comment 36

[Kershaw Chang [:kershaw]]

Comment on attachment 9279092 [details]
Bug 1770123 - Clear PAC loader when the load is failed, r=#necko

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: If there is a PAC URL set and the server that hosts the PAC is not reachable, OCSP requests are blocked.
• User impact if declined: If there is a PAC URL set and the server that hosts the PAC is not reachable, OCSP requests are blocked.
• Fix Landed on Version: 103
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This patch is straightforward.

Comment 37

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9279092 [details]
Bug 1770123 - Clear PAC loader when the load is failed, r=#necko

Approved for 91.11esr.

Comment 38

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr91/rev/d517719645b2

Comment 39

[Ciprian Georgiu, Desktop QA]

I've reproduced this bug using an affected Nightly build from 2022-05-19, using the STR from comment 22.

The issue is verified as fixed on the latest builds: ESR 91.11, Beta 102.0b8 and latest Nightly 103.0a1.

Comment 40

[Tom Ritter [:tjr]]

Attachment: advisory.txt