SSO to trusted URIs and proxies not working in Private Browsing mode

RESOLVED FIXED in Firefox 52

Status

()

Core
Networking
--
major
RESOLVED FIXED
a year ago
5 months ago

People

(Reporter: Arnis Rukis, Assigned: mayhemer)

Tracking

48 Branch
mozilla52
Points:
---

Firefox Tracking Flags

(firefox52 fixed)

Details

(Whiteboard: [necko-active][ntlm])

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

a year ago
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160623154057

Steps to reproduce:

Open page in private mode with SSO configured in mozilla.cfg


Actual results:

page asks for credentials


Expected results:

SSO to page.
It works in FF47 and older versions.
Not tested with 48.x
(Reporter)

Comment 1

a year ago
SSO configured in mozilla.cfg using

network.automatic-ntlm-auth.trusted-uris
and
network.negotiate-auth.trusted-uris

In normal browsing all works fine
Severity: normal → major

Comment 2

a year ago
Arnis, could you tell me step by step to reproduce on my machine?
If I create mozilla.cfg with the lines your provided, which website do I need to visit to repro the bug?
Flags: needinfo?(a.rukis)
(Reporter)

Comment 3

a year ago
Use domain joined windows computer and webserver with integration to active directory

1. Make Firefox config for SSO using network.negotiate-auth.trusted-uris or network.automatic-ntlm-auth.trusted-uris depends on your webserver configuration. I configured this in mozilla.cfg file.
2. Test configuration in "normal" mode, open company website - should authenticate in company website(works fine for me).
3. Open new "Private" tab and open company website - it asks for signing credentials (this is problem, in earlier versions 47.x in private mode SSO works and automatically signs in company website)
Flags: needinfo?(a.rukis)

Updated

a year ago
Component: Untriaged → Networking
Product: Firefox → Core

Comment 4

a year ago
Hum, it will be hard for me to reproduce the issue as I don't have any webserver with authentication to test.
(Assignee)

Comment 5

a year ago
This was made intentional.  However, I may start thinking we may want to allow this for the trusted list of URIs and only completely disable SSO (via sspi) for non-trusted URIs (i.e. somewhat loose the restrictions added in bug 1248564.)

Jan, what do you think?
Blocks: 1248564
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(jhorak)
Assignee: nobody → honzab.moz
Whiteboard: [necko-active]

Updated

a year ago
Version: 49 Branch → 48 Branch
The plan was to set network.negotiate-auth.trusted-uris to "https://", which basically sends authentication data to every https:// site which asks for them. Sending data also in Private browsing might be an unpleasant surprise for the user.

We'd better ask for reasoning our man for SSO stuff who proposed that change.
Flags: needinfo?(jhorak) → needinfo?(ab)

Comment 7

a year ago
If you would allow it only for network.negotiate-auth.trusted-uris, you would let Private Mode let loose against your enterprise infrastructure. Your domain controllers will know about the resources you access. This is of a less problem with NTLMSSP on Windows but it is still a sizable privacy leak.

The real problem is that people confuse Privacy Mode with "Do not remember cookies and a history" mode. 

Honza, if you want to reduce restrictions for Private Mode, it would be good to have a knob that could be set by distributions to 'false' to disallow leaking privacy details to your enterprise domain controllers about the servers you access in the Privacy Mode.
Flags: needinfo?(ab)
(Reporter)

Comment 8

a year ago
I think if I as admin specify sites for which I need SSO in parameters: "network.negotiate-auth.trusted-uris" and "network.automatic-ntlm-auth.trusted-uris" using cfg file and set this sites as locked preference this is enough to trust to this resources and send autentification data to make SSO.

I think that SSO if is configured must work in privacy mode too.

If you think that this is problem make additional configuration parameter to allow or deny sending credentials in privacy mode.
(Assignee)

Updated

a year ago
Flags: needinfo?(honzab.moz)
(Assignee)

Comment 9

a year ago
(In reply to Alexander Bokovoy from comment #7)
> Honza, if you want to reduce restrictions for Private Mode, it would be good
> to have a knob that could be set by distributions to 'false' to disallow
> leaking privacy details to your enterprise domain controllers about the
> servers you access in the Privacy Mode.

I agree.  Let's add a pref and maybe turn it to false by default.  See also bug 1315680 that may be related.
Status: NEW → ASSIGNED
Flags: needinfo?(honzab.moz)
(Reporter)

Comment 10

a year ago
About proxy server authentication - yes it is problem, too. In private mode asks for credentials. For proxy settings in FF is use system settings.
(Assignee)

Comment 11

a year ago
(In reply to Arnis Rukis from comment #10)
> About proxy server authentication - yes it is problem, too. In private mode
> asks for credentials. For proxy settings in FF is use system settings.

That's a good point too, actually.  Proxy should go all the time.  I think that's bug 1315680 at its whole glance.  Thanks.  I will incorporate it in the patch for this bug.
(Assignee)

Comment 12

a year ago
Created attachment 8808318 [details] [diff] [review]
v1 (always sso to proxy, pref for sso to server in a PB window)
Attachment #8808318 - Flags: review?(jduell.mcbugs)
Comment on attachment 8808318 [details] [diff] [review]
v1 (always sso to proxy, pref for sso to server in a PB window)

Review of attachment 8808318 [details] [diff] [review]:
-----------------------------------------------------------------

::: extensions/auth/nsHttpNegotiateAuth.cpp
@@ +78,5 @@
>      }
>  
>      nsCOMPtr<nsIPrefBranch> prefs = do_GetService(NS_PREFSERVICE_CONTRACTID);
>      if (!prefs) {
> +        return false;

All the other error paths here return 'true'--and this specific test used to return false--are you sure you should have changed this to 'false' here?  I guess this is mostly academic, because I assume if we can't get the PrefBranch service things will already be fairly messed up.

::: netwerk/protocol/http/nsIHttpAuthenticableChannel.idl
@@ +107,5 @@
>      void onAuthCancelled(in boolean userCancel);
> +
> +    /**
> +     * Tells the channel to drop and close any sticky connection, since this
> +     * connection oriented schema cannot be negoticated second time on

negotiated
Attachment #8808318 - Flags: review?(jduell.mcbugs) → review+
(Assignee)

Comment 14

a year ago
(In reply to Jason Duell [:jduell] (needinfo me) from comment #13)
> Comment on attachment 8808318 [details] [diff] [review]
> v1 (always sso to proxy, pref for sso to server in a PB window)
> 
> Review of attachment 8808318 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: extensions/auth/nsHttpNegotiateAuth.cpp
> @@ +78,5 @@
> >      }
> >  
> >      nsCOMPtr<nsIPrefBranch> prefs = do_GetService(NS_PREFSERVICE_CONTRACTID);
> >      if (!prefs) {
> > +        return false;
> 
> All the other error paths here return 'true'--and this specific test used to
> return false--are you sure you should have changed this to 'false' here?  I
> guess this is mostly academic, because I assume if we can't get the
> PrefBranch service things will already be fairly messed up.

Actually, I think false is correct here.  At this moment we've established that channel is in PB mode.  We can only return true (i.e. to behave as if the channel were not in PB mode) when one of the privatebrowsing.autostart or private-browsing-sso prefs are set.  But they can't be set, so return false.  I can rewrite the patch to make this more clear.

The code before was wrong.
Summary: SSO not working in Private mode → SSO to a proxy not working in Private mode + don't renegotiate on the same connection
(Assignee)

Updated

a year ago
Summary: SSO to a proxy not working in Private mode + don't renegotiate on the same connection → SSO to trusted URIs and proxies not working in Private Browsing mode + don't renegotiate on the same connection
(Assignee)

Comment 15

a year ago
Created attachment 8809767 [details] [diff] [review]
v1.1 (always sso to proxy, pref for sso to server in a PB window)

I split out the part with sticky conn.  It actually belongs to a different bug.
Attachment #8808318 - Attachment is obsolete: true
(Assignee)

Updated

a year ago
Summary: SSO to trusted URIs and proxies not working in Private Browsing mode + don't renegotiate on the same connection → SSO to trusted URIs and proxies not working in Private Browsing mode
(Assignee)

Updated

a year ago
Duplicate of this bug: 1315680
(Assignee)

Comment 17

a year ago
(not try, since there are no tests that would be affected)
Keywords: checkin-needed
(Assignee)

Updated

a year ago
Attachment #8809767 - Flags: review+

Comment 18

a year ago
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/720a160f4c0c
Pref to send default NTLM creds in PB, Always send default creds to proxies in PB. r=jduell
Keywords: checkin-needed

Comment 19

a year ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/720a160f4c0c
Status: ASSIGNED → RESOLVED
Last Resolved: a year ago
status-firefox52: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla52
(Assignee)

Updated

7 months ago
Whiteboard: [necko-active] → [necko-active][ntlm]
(Assignee)

Updated

5 months ago
Duplicate of this bug: 1300680
You need to log in before you can comment on or make changes to this bug.