Closed Bug 1375579 Opened 7 years ago Closed 7 years ago

"Access denied" when browsing particular sites via NTLM proxy

Categories

(Core :: Networking, defect)

55 Branch
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: raynebc, Assigned: mayhemer)

Details

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

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0 Build ID: 20170619071723 Steps to reproduce: A user pointed out that he couldn't access various usnews.com subdomains (ie. http://travel.usnews.com/ ) with Firefox. Other websites in general can be browsed without such issue, there must be something peculiar about this one. Actual results: An "Access Denied You don't have permission to access ... on this server." message is displayed. I can reproduce this in the current latest beta: Firefox 55.0b3 (32 bit). The page loads if I disable my use of the proxy server, but the page loads perfectly fine in IE and Chrome when they're using our proxy server, so I don't expect the proxy server is at fault in this instance. This may be related to reliability problems recent Firefox builds have had with NTLM authenticating proxy servers (ie. bug #1351462 and #1365302). We have contacted the company that develops our proxy server and they are convinced that Firefox mishandles NTLM communication (see https://bugzilla.mozilla.org/show_bug.cgi?id=1351462#c29 ). Expected results: The page should load as it does in IE and Chrome.
Component: Untriaged → Networking
Product: Firefox → Core
raynebc, good you can reproduce. can you please provide a log as before? Thanks! https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging To react to what the proxy developer responded: the conclusion I've made in bug 1351462 is based on only one log you ever have sent me where only one channel (to http://maps.googleapis.com/maps/vt?) raises the prompt and I double checked again (with better log analyzes tools) that the problem is really coming from the proxy, not Firefox. But someone has to step back and fix the problem, and since I may know how (as outlined in bug 1351462) I can introduce a patch. But first, let's find out what's wrong here, with this bug with different symptoms.
Assignee: nobody → honzab.moz
Flags: needinfo?(raynebc)
Whiteboard: [ntlm][necko-active]
Flags: needinfo?(raynebc)
I enabled the logging with the same environment variable as in the previous ticket (MOZ_LOG=timestamp,sync,nsHttp:5,negotiateauth:5) and restarted Firefox. I loaded the Google webpage. I attempted to load http://www.usnews.com, but got the access denied message. I attempted to load http://travel.usnews.com, but got the access denied message. I loaded https://www.usnews.com without problem. For some reason after this, www.usnews.com and travel.usnews.com would load up without issue. I can't tell why the problem went away or if that means the web site had a problem that they resolved. The logging for that browser session is attached. I can't reproduce the problem anymore at this time.
In the log I can see more than one access to http://www.usnews.com. The first one is authenticating to the proxy as expected, no prompt popped up (hence, using the windows default credentials), response from the server (AkamaiGHost) is 403. The second request - less than two minutes later - to the same URL finds a cached entry with 403, which we always revalidate (make a request to the server). This time the request is made through an already authenticated connection to the proxy. There were only one request made on that connection to http://usnews.com/ that goes through the NTLM proxy auth dance and ends up with a 301 redirect (from AkamaiGHost server) to https://www.usnews.com/. I can see also a request e.g. to http://detectportal.firefox.com/success.txt witch behaves as expected. No idea what this was, could the proxy failure or (more likely) interference or the end server intermediate problem. Closing as invalid.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
(Note that responses from the https server are coming from Apache-Coyote/1.1 server, not AkamaiGHost)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: