1838429 - OCSP requests use System Principal

Status: UNCONFIRMED

(Core :: Security: PSM, defect, P2)

Description

[aoia7rz7l]

Per bug 1837967 comment 5.

Prerequisites:

privacy.resistfingerprinting is set to true.

STR:

1. Set security.ssl.enable_ocsp_stapling to false.
2. Open about:networking#logging or about:logging and start logging to a file.
3. Visit https://news.ycombinator.com/.
4. Stop logging and open the logfile.
5. Confirm that there are entries such as using spoofed userAgent : Mozilla/5.0 (Windows NT 10.0; rv:109.0) Gecko/20100101 Firefox/115.0 for requests to https://news.ycombinator.com/, and that the actual request logged used the same UA.
6. Search for Host: ocsp.digicert.com in the logfile.

Expected Behavior:

OCSP requests use the spoofed User-Agent HTTP Header.

Actual Behavior:

OCSP requests use the real User-Agent HTTP Header.

Mozregression returned

Last good revision: 296cbb6e3709481a494f86dbfb37cb47ce087441
First bad revision: 1f7520bc1e0d703fae7cf3953adf178d31f84394
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=296cbb6e3709481a494f86dbfb37cb47ce087441&tochange=1f7520bc1e0d703fae7cf3953adf178d31f84394

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Networking: HTTP' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Tom Ritter [:tjr] (OOTO until 7/21)]

While the original context of the bug is that RFP doesn't apply to OCSP requests - this is because OCSP requests use the System Principal, which I consider to be a more general problem.

If this is a known behavior that is intentional, this can be closed as Invalid, but conceptually I think it would be preferable for OCSP requests not be this privileged - while they are important requests, I would think they should be made absent any special context or privileges.

Comment 3

[Valentin Gosu [:valentin] (he/him) {{ AFK in July }}]

I guess we could make the OCSP requests use a null principal instead?

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

Setting Regressed by field after analyzing regression range found by mozregression in comment #0.

Comment 5

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

That would make sense to me, but I don't necessarily know all of the security implications of using the null principal. Christoph?

Comment 6

[Christoph Kerschbaumer [:ckerschb]]

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

That would make sense to me, but I don't necessarily know all of the security implications of using the null principal. Christoph?

Yes, using a NullPrincipal for OCSP should work fine. I think we should use:
RefPtr<nsIPrincipal> nullPrincipal = mozilla::NullPrincipal::Create(mOriginAttributes);

Background info:
When we introduced loadinfo we decided to use SystemPrincipal for all loads that were truly triggered by the system and the URL of the channel can not be influenced by the webpage you are visiting. In that case, since it has no other implications, it's fine to use NullPrincipal.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:keeler, could you have a look please?

For more information, please visit BugBot documentation.

Comment 8

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

Using NullPrincipal seems to result in OCSP responses being blocked by Opaque Response Blocking - is there a flag I should set? Or does ORB need to be updated to handle this?

Comment 9

[Andreas Farre [:farre] (PTO -> Aug 1st)]

If this used to use the System Principal we'd trigger an exception to ORB, and if we don't want to block cross-origin opaque OCSP responses, then we'd need to add another expection to HttpBaseChannel::ShouldBlockOpaqueResponse. But I'm not sure of the implications of that. Christoph, is that an OK thing to allow?

Comment 10

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Andreas Farre [:farre] from comment #9)

If this used to use the System Principal we'd trigger an exception to ORB, and if we don't want to block cross-origin opaque OCSP responses, then we'd need to add another expection to HttpBaseChannel::ShouldBlockOpaqueResponse. But I'm not sure of the implications of that. Christoph, is that an OK thing to allow?

Probably it's best if we use a different content policy type that is not subject to Opaque Response Blocking. I would imagine that replacing nsIContentPolicy::TYPE_OTHER with TYPE_DOCUMENT would fix the problem. I am not entirely sure if TYPE_DOCUMENT is indeed the right type to use for OCSP, though it should suffice to test locally if that works. And then we could introduce a new policy type?

Probably it is fine to do what you suggested and add an early return for TYPE_OTHER to ShouldBlockOpaqueResponse. I would imagine that is just fine. At least I can't see a valid reason why TYPE_OTHER needs to be subject to ORB. I could imagine the only reason that never became a problem is because we most likely always pair TYPE_OTHER with a triggeringPrincipal of SystemPrincipal which bypasses ORB alltogether.

Summing it up, introducing an early return for TYPE_OTHER is probably fine, though we should have someone who knows all the details about ORB sign off on it.