Open Bug 1389783 Opened 7 years ago Updated 2 years ago

no authentication dialog given for ocsp system connections

Categories

(Core :: Security: PSM, enhancement, P5)

Other Branch
x86_64
Linux
enhancement

Tracking

()

UNCONFIRMED

People

(Reporter: pubkeypin, Unassigned)

References

Details

(Whiteboard: [psm-backlog])

[I might have choosen the wrong bugzilla product and/or component. Please change it if necessary.]


Via network settings a http and a https proxy are configured with different addresses. Both need authentication with different usernames and passwords.
Certificates are configured to require ocsp verification.

If the first visited web page after firefox startup is connected via https and needs (not stapled) to query an ocsp responder, firefox asks for the https proxy credentials but not for the http proxy username and password, needed for the connection to the ocsp responder.

An error page is shown because of the failed verification.

Firefox should ask for authentication to both proxies.

If the http username and password are given before (while fetching some sites unencrypted via http), the following https connection succeeds (after giving https proxy credentials), because http proxy username and password seem to be cached.

I'm seeing this with firefox-57.0a1.en-US.linux-x86_64

https://bugzilla.mozilla.org/show_bug.cgi?id=1128278
might be related but in my case no "Private Browsing mode" is involved.
See Also: → 1128278
:keeler, does PSM drive OCSP connections? Feels to me like there might be something not right about the way those channels are being set up (or at least, not compatible with this... odd configuration), in which case this belongs in PSM, not necko. I'm willing to entertain the idea that I'm way off base here, though :)
Flags: needinfo?(dkeeler)
I suspect the code change will happen in PSM (it's where we create the request, etc.), but I might need help getting the right flags/settings. I'm assuming this is happening because we try to make the request as anonymous as possible, which could be resulting in necko not presenting an auth dialog.
Component: Networking → Security: PSM
Flags: needinfo?(dkeeler)
(In reply to David Keeler [:keeler] (use needinfo?) from comment #2)
> I suspect the code change will happen in PSM (it's where we create the
> request, etc.), but I might need help getting the right flags/settings. I'm
> assuming this is happening because we try to make the request as anonymous
> as possible, which could be resulting in necko not presenting an auth dialog.

If this is proxy auth, then no, it's not about flags (LOAD_ANONYMOUS).  We allow proxy auth when this flag is set.

The true reason is that the channel is missing the right notification callbacks: when a channel is part of a page load (which OCSP definitely isn't..), the channel's notification callbacks are set to the docshell or (in e10s) to TabParent which provides the necessary GetInterface'ed objects on the parent process.  One of them is the auth prompt provider which is necessary to open the auth dialog.

I think what you need is to make the OCSP request be part of the document load (be assigned the right notification callbacks).  This may be really hard since PSM probably doesn't know that.
Priority: -- → P5
Whiteboard: [psm-backlog]
Another observation might be related:

If Firefox is started in the described environment, but not used for browsing by the user
(no prompt for credentials and therefore nothing cached, no usage of the proxies),
after idling a while firefox starts using the network on its own for various tasks of "self employment".

For example it wants to connect to
https://shavar.services.mozilla.com/downloads
via the https proxy.

The proxy answers with:
HTTP/1.1 407 Proxy Authentication Required
but Firefox nevers asks me (the user) for the username and password for any proxy.

As a result these connections fail silently but can be seen in the browser console.

From my perspective it looks as if this "bug" isn't limited to ocsp queries, but affects other connection attemps of the browser as well.

What these requests seem to have in common, is the missing user context / associated tab or window.
They are initiated by the browser itself.


Hope this helps debugging or when searching for a solution.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.