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)
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.
: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)
Comment 3•7 years ago
|
||
(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.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•