Closed Bug 1423522 Opened 3 years ago Closed 3 years ago

We should not block http-authentication prompts for proxies.

Categories

(Core :: Networking: HTTP, enhancement, P3)

59 Branch
enhancement

Tracking

()

RESOLVED FIXED
mozilla59
Tracking Status
firefox59 --- fixed

People

(Reporter: dragana, Assigned: dragana)

Details

(Whiteboard: [necko-triaged])

Attachments

(1 file)

No description provided.
We should allow http-authentication for proxies, even though it would be blocked because it is triggered by a cross-origin image resource?
Flags: needinfo?(ckerschb)
Priority: -- → P3
Whiteboard: [necko-triaged]
Proxy auth is something way different from end-server auth.  Yes, allow proxy auth for such requests, for sure!
(In reply to Honza Bambas (:mayhemer) from comment #2)
> Proxy auth is something way different from end-server auth.  Yes, allow
> proxy auth for such requests, for sure!

Yeah indeed, we should allow proxy auth.
Flags: needinfo?(ckerschb)
Assignee: nobody → dd.mozilla
Status: NEW → ASSIGNED
Attachment #8934950 - Flags: review?(ckerschb)
Comment on attachment 8934950 [details] [diff] [review]
bug_1423522_v1.patch

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

Yeah, I am fine with that. Thanks for fixing that so quickly. r=me
Attachment #8934950 - Flags: review?(ckerschb) → review+
Pushed by dd.mozilla@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/40cefc4f51d4
We should not block http-authentication prompts for proxies. r=ckerschb
(In reply to Honza Bambas (:mayhemer) from comment #2)
> Proxy auth is something way different from end-server auth.  Yes, allow
> proxy auth for such requests, for sure!

Wait, why is it any different? If the key to recovering this phishing trick is to provide a link to a server that sends a 407 instead of a 401 then that's what the phishers are going to do! The effect is the same.
Flags: needinfo?(dd.mozilla)
Flags: needinfo?(ckerschb)
Attachment #8934950 - Flags: feedback-
(In reply to Daniel Veditz [:dveditz] from comment #7)
> (In reply to Honza Bambas (:mayhemer) from comment #2)
> > Proxy auth is something way different from end-server auth.  Yes, allow
> > proxy auth for such requests, for sure!
> 
> Wait, why is it any different? If the key to recovering this phishing trick
> is to provide a link to a server that sends a 407 instead of a 401 then
> that's what the phishers are going to do! The effect is the same.

I think that proxyAuth==true also mProxyAuth==true if we have a proxyinfo on the channel, i.e. if a proxy is configured.

I will check.
Flags: needinfo?(dd.mozilla)
(In reply to Dragana Damjanovic [:dragana] from comment #9)
> We do reject 407 if a proxy is not configured:
> 
> https://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/
> nsHttpChannelAuthProvider.cpp#187

Exactly :)  that would be a really big bug ;)
https://hg.mozilla.org/mozilla-central/rev/40cefc4f51d4
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
(In reply to Honza Bambas (:mayhemer) from comment #10)
> (In reply to Dragana Damjanovic [:dragana] from comment #9)
> > We do reject 407 if a proxy is not configured:
> > 
> > https://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/
> > nsHttpChannelAuthProvider.cpp#187
> 
> Exactly :)  that would be a really big bug ;)


The users with a setup proxy will be affected. If someone intercept the proxy connection, sends 307, or any redirect, to another location it could trigger the http-authentication dialog with 407.

But in this case the authentication dialog will say "The proxy ... is requesting ...".
This is not really phishing and it can be done with any resource.

Am I missing something?
Flags: needinfo?(dveditz)
(In reply to Dragana Damjanovic [:dragana] from comment #12)
> But in this case the authentication dialog will say "The proxy ... is
> requesting ...".
> This is not really phishing and it can be done with any resource.
> 
> Am I missing something?

Just as the <img> triggered dialog clearly says "evil.com" is requesting your password when you're on "good.com", victims won't read it closely enough to know the difference.

The check in comment 9 reassures me. I'm not too worried about injections between the user and their chosen proxy (https is safe, http is already hackable) and most users won't have set up a proxy anyway.
Flags: needinfo?(dveditz)
(In reply to Daniel Veditz [:dveditz] from comment #13)
> The check in comment 9 reassures me. I'm not too worried about injections
> between the user and their chosen proxy (https is safe, http is already
> hackable) and most users won't have set up a proxy anyway.

Thanks Dan for checking in - it seems my ni? has become superfluous in the meantime...
Flags: needinfo?(ckerschb)
You need to log in before you can comment on or make changes to this bug.