Closed Bug 1274691 Opened 9 years ago Closed 9 years ago

Browsing to IP Addresses automatically attempts HTTPS even if HTTP is specified

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Version:
45 Branch
Platform:
x86_64
Windows
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 968273

People

(Reporter: darien, Assigned: dragana)

Details

(Whiteboard: [necko-active])

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:45.0) Gecko/20100101 Firefox/45.0 Cyberfox/45.0.3 Build ID: 20160408215516 Steps to reproduce: Visit an IP address that is HTTPS. Try to visit the same IP address but without HTTPS. Manually typing http:// or just the IP address or even specifying http://123.456.789:80 Actual results: Unable to connect Firefox can't establish a connection to the server at 192.168.1.1. or Secure Connection Failed The connection to 192.168.1.1:80 was interrupted while the page was loading. The page you are trying to view cannot be shown because the authenticity of the received data could not be verified. Expected results: Page should load normally over HTTP.
OS: Unspecified → Windows
Hardware: Unspecified → x86_64
I've only been able to reproduce this on Windows. Android behaves as expected. For some reason Firefox automatically issues a 301, see HAR below: { "log": { "version": "1.1", "creator": { "name": "Cyberfox", "version": "45.0.3" }, "browser": { "name": "Cyberfox", "version": "45.0.3" }, "pages": [ { "startedDateTime": "2016-05-20T23:25:15.022-07:00", "id": "page_2", "title": "Problem loading page", "pageTimings": { "onContentLoad": -1, "onLoad": -1 } } ], "entries": [ { "pageref": "page_2", "startedDateTime": "2016-05-20T23:25:15.022-07:00", "time": 0, "request": { "bodySize": 0, "method": "GET", "url": "http://192.168.1.1/", "httpVersion": "HTTP/1.1", "headers": [ { "name": "Host", "value": "192.168.1.1" }, { "name": "User-Agent", "value": "Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:45.0) Gecko/20100101 Firefox/45.0 Cyberfox/45.0.3" }, { "name": "Accept", "value": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" }, { "name": "Accept-Language", "value": "en-US,en;q=0.5" }, { "name": "Accept-Encoding", "value": "gzip, deflate" }, { "name": "Cookie", "value": "tomato_menu_status=overview.asp; tomato_status_overview_refresh=3" }, { "name": "Connection", "value": "keep-alive" } ], "cookies": [ { "name": "tomato_menu_status", "value": "overview.asp" }, { "name": "tomato_status_overview_refresh", "value": "3" } ], "queryString": [], "postData": { "mimeType": "", "params": [], "text": "" }, "headersSize": 0 }, "response": { "status": 301, "statusText": "Moved Permanently", "httpVersion": "HTTP/1.1", "headers": [ { "name": "Server", "value": "nginx" }, { "name": "Date", "value": "Fri, 20 May 2016 01:18:17 GMT" }, { "name": "Content-Type", "value": "text/html" }, { "name": "Content-Length", "value": "178" }, { "name": "Location", "value": "https://192.168.1.1/" }, { "name": "X-Frame-Options", "value": "SAMEORIGIN" } ], "cookies": [], "content": { "mimeType": "text/plain", "size": 0, "encoding": "base64", "text": "" }, "redirectURL": "https://192.168.1.1/", "headersSize": 0, "bodySize": 0 }, "cache": { "afterRequest": null }, "timings": { "blocked": 0, "dns": 0, "connect": 0, "send": 0, "wait": 0, "receive": 0 } }, { "pageref": "page_2", "startedDateTime": "2016-05-20T23:25:15.031-07:00", "time": 251, "request": { "bodySize": 0, "method": "GET", "url": "https://192.168.1.1/", "httpVersion": "", "headers": [ { "name": "Host", "value": "192.168.1.1" }, { "name": "User-Agent", "value": "Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:45.0) Gecko/20100101 Firefox/45.0 Cyberfox/45.0.3" }, { "name": "Accept", "value": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" }, { "name": "Accept-Language", "value": "en-US,en;q=0.5" }, { "name": "Accept-Encoding", "value": "gzip, deflate, br" }, { "name": "Cookie", "value": "tomato_menu_status=overview.asp; tomato_status_overview_refresh=3; PHPSESSID=1dghkoa228fuvh43bubtlckdt0081dc8" }, { "name": "Connection", "value": "keep-alive" } ], "cookies": [ { "name": "tomato_menu_status", "value": "overview.asp" }, { "name": "tomato_status_overview_refresh", "value": "3" }, { "name": "PHPSESSID", "value": "1dghkoa228fuvh43bubtlckdt0081dc8" } ], "queryString": [], "postData": { "mimeType": "", "params": [], "text": "" }, "headersSize": 429 }, "response": { "status": 0, "statusText": "", "httpVersion": "", "headers": [], "cookies": [], "content": { "mimeType": "text/plain", "size": 0, "encoding": "base64", "text": "" }, "redirectURL": "", "headersSize": -1, "bodySize": -1 }, "cache": {}, "timings": { "blocked": 0, "dns": 251, "connect": 0, "send": 0, "wait": 0, "receive": 0 } } ] } }
That's not Firefox issuing a 301, that's a response from the server.
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
(In reply to Robert Longson from comment #2) > That's not Firefox issuing a 301, that's a response from the server. But its a "cached" 301 response, look at the times. Caching these make sense for CDN, and dynamic content but I don't think this is the expected behavior for IP addresses, especially when I explicitly browse to http://192.168.1.1 instead of https://192.168.1.1 http://192.168.1.1:80 does not resolve correctly either. If this is the intended behavior then how can I disable besides clearing my browser history each time I change networks.
configure the server so that its responses are no-cache.
(In reply to Robert Longson from comment #4) > configure the server so that its responses are no-cache. This isn't really a choice, especially for private IP ranges. Either the caches for private IPs should have a setting to be disabled, or manually typing http://192.168.1.1 should ignore the cache. Example: You have to go to a captive portal hosted on 192.168.1.1 and its over HTTPS. Later you go to a different network with a captive portal on 192.168.1.1 but on HTTP. You cant access the second one now.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
I can not reproduce this issue on fx 45 or Nightly 49.0a1. When manually typing in http://. . . I am redirected to https://. . . Can you try testing on the latest Nightly 49.0a1 or with a clean profile https://support.mozilla.org/en-US/kb/refresh-firefox-reset-add-ons-and-settings#
Flags: needinfo?(darien)
Clean profile, FF 49.0a1 (2016-05-24). Reproduction Steps: 1. Visit IP address with a server that redirects 301 from http to https. 2. Visit same IP but on a different network. On this network the host is not HTTPS aware. Typing in xxx.xxx.xxx.xxx automatically redirects to HTTPS. Typing http://xxx.xxx.xxx.xxx automatically redirects to HTTPS. Typing http://xxx.xxx.xxx.xxx:80 attempts to use HTTPS over port 80 instead of plain http. Why this issue needs a workaround other than clearing the profile: Suppose you are a non-technical user who visits places that have free wi-fi. Each network has a captive portal but one is secure. Network 1's portal issues a 301 redirect to HTTPS. Later user visits a different network but with the same IP scheme. Network 2's portal is hosted on same IP but does not use HTTPS. To the user it appears that the wi-fi is down, even though it is FF that is at fault. This behavior does not occur on chrome or IE. HAR below: Note the times, 301 is issued in the past, not at access time. { "log": { "version": "1.1", "creator": { "name": "Firefox", "version": "49.0a1" }, "browser": { "name": "Firefox", "version": "49.0a1" }, "pages": [ { "startedDateTime": "2016-05-24T13:57:05.077-07:00", "id": "page_1", "title": "Problem loading page", "pageTimings": { "onContentLoad": -1, "onLoad": -1 } } ], "entries": [ { "pageref": "page_1", "startedDateTime": "2016-05-24T13:57:05.077-07:00", "time": 0, "request": { "bodySize": 0, "method": "GET", "url": "http://192.168.1.1/", "httpVersion": "HTTP/1.1", "headers": [ { "name": "Host", "value": "192.168.1.1" }, { "name": "User-Agent", "value": "Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:49.0) Gecko/20100101 Firefox/49.0" }, { "name": "Accept", "value": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" }, { "name": "Accept-Language", "value": "en-US,en;q=0.5" }, { "name": "Accept-Encoding", "value": "gzip, deflate" }, { "name": "Connection", "value": "keep-alive" }, { "name": "Upgrade-Insecure-Requests", "value": "1" } ], "cookies": [], "queryString": [], "postData": { "mimeType": "", "params": [], "text": "" }, "headersSize": 0 }, "response": { "status": 301, "statusText": "Moved Permanently", "httpVersion": "HTTP/1.1", "headers": [ { "name": "Content-Length", "value": "178" }, { "name": "Content-Type", "value": "text/html" }, { "name": "Date", "value": "Tue, 24 May 2016 20:53:43 GMT" }, { "name": "Location", "value": "https://192.168.1.1/" }, { "name": "Server", "value": "nginx" }, { "name": "x-frame-options", "value": "SAMEORIGIN" } ], "cookies": [], "content": { "mimeType": "text/plain", "size": 0, "encoding": "base64", "text": "" }, "redirectURL": "https://192.168.1.1/", "headersSize": 0, "bodySize": 0 }, "cache": { "afterRequest": null }, "timings": { "blocked": 0, "dns": 0, "connect": 0, "send": 0, "wait": 0, "receive": 0 } }, { "pageref": "page_1", "startedDateTime": "2016-05-24T13:57:05.091-07:00", "time": 1256, "request": { "bodySize": 0, "method": "GET", "url": "https://192.168.1.1/", "httpVersion": "", "headers": [ { "name": "Host", "value": "192.168.1.1" }, { "name": "User-Agent", "value": "Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:49.0) Gecko/20100101 Firefox/49.0" }, { "name": "Accept", "value": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" }, { "name": "Accept-Language", "value": "en-US,en;q=0.5" }, { "name": "Accept-Encoding", "value": "gzip, deflate, br" }, { "name": "Cookie", "value": "PHPSESSID=nsgqk6ql5uncdgn8hnrouica31iaimls" }, { "name": "Connection", "value": "keep-alive" }, { "name": "Upgrade-Insecure-Requests", "value": "1" } ], "cookies": [ { "name": "PHPSESSID", "value": "nsgqk6ql5uncdgn8hnrouica31iaimls" } ], "queryString": [], "postData": { "mimeType": "", "params": [], "text": "" }, "headersSize": 376 }, "response": { "status": 0, "statusText": "", "httpVersion": "", "headers": [], "cookies": [], "content": { "mimeType": "text/plain", "size": 0, "encoding": "base64", "text": "" }, "redirectURL": "", "headersSize": -1, "bodySize": -1 }, "cache": {}, "timings": { "blocked": 0, "dns": 1256, "connect": 0, "send": 0, "wait": 0, "receive": 0 } } ] } }
Flags: needinfo?(darien)
sorry should have said this last comment but can you please provide the ip addresses and urls you are using so I can see exactly what you are.
Please contact Mozilla support for this issue https://support.mozilla.org/en-US/products/firefox
Flags: needinfo?(darien)
I can reproduce this issue on Win 8.1 on Nightly 49.0a1
I have created a post but I think this issue is more core related. https://support.mozilla.org/en-US/questions/1124363 There was another user who had the opposite problem (http wouldn't redirect to https) but the mentioned workaround was removed in the nightly build. A fix I propose is that FF does not cache 301 redirects for RFC 1918 and 4193 addresses.
Flags: needinfo?(darien)
Component: Untriaged → Networking: HTTP
Product: Firefox → Core
the http vs https thing is a bit of a red herring. If I read this bug right, the issue is that basically you can't flush a cached redirect (of any kind) and that results in a kind of capture. Dragana is working on another bug (that may have landed on 50) in which an explicit page reload would revalidate the original uri, not just the one currently in the location bar (which is the result of the redirect). so its possible this can just be dup'd to that.
Flags: needinfo?(dd.mozilla)
I am not sure that bug 968273 has fixed this, I rather believe not. Justin, may I ask you to try with latest Nightly 50?
Flags: needinfo?(dd.mozilla) → needinfo?(jwilliams)
Dragana - feel free to bump this down to next/unassign yourself if this ends up being more complex, but based on comment 14 I'm marking this active and assigning to you for now.
Assignee: nobody → dd.mozilla
Whiteboard: [necko-active]
Dragana this issue is still persistent on Nightly 50.
Flags: needinfo?(jwilliams)
(In reply to Justin [:JW_SoftvisionQA] from comment #16) > Dragana this issue is still persistent on Nightly 50. just making sure you pressed reload in your test. did you? please attach the http log. https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging I'm opposed to any special casing of ip addresses and whatnot.. this seems like a general cache management issue. Or am I misunderstanding it?
May I ask you to make a log from comment 17?
Flags: needinfo?(jwilliams)
Issue still occurs in Nightly 50.0a1 (2016-07-21) https://paste.ubuntu.com/20415277/ (In reply to Dragana Damjanovic [:dragana] from comment #18) > May I ask you to make a log from comment 17? (In reply to Patrick McManus [:mcmanus] from comment #17) > (In reply to Justin [:JW_SoftvisionQA] from comment #16) > > Dragana this issue is still persistent on Nightly 50. > > just making sure you pressed reload in your test. did you? > > please attach the http log. > https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging > > I'm opposed to any special casing of ip addresses and whatnot.. this seems > like a general cache management issue. Or am I misunderstanding it?
For your log: it is reading from the cache which has stored 301 Moved Permanently, therefore it is redirecting to https. Have you try cleaning cache? bug 968273 is not that easy to solved, because it cause other problems.
(In reply to Dragana Damjanovic [:dragana] from comment #20) > For your log: it is reading from the cache which has stored 301 Moved > Permanently, therefore it is redirecting to https. > > Have you try cleaning cache? > > bug 968273 is not that easy to solved, because it cause other problems. You shouldn't need to clear the cache for this. The login (captive portal) pages for many public hotspots are in local IP ranges, a normal user would not know about 301 redirects. bug 968273 is similiar yes, but we could just for now force re-validation for rfc 1918 addresses. What is stranger is that in the original request to the secure server, the server specifies "headers": [ { "name": "Cache-Control", "value": "no-store, no-cache, must-revalidate, post-check=0, pre-check=0" } ] So should't the client be revalidating in all subsequent connections?
( > > What is stranger is that in the original request to the secure server, the > server specifies > "headers": [ > { > "name": "Cache-Control", > "value": "no-store, no-cache, must-revalidate, post-check=0, > pre-check=0" > } > ] > > So should't the client be revalidating in all subsequent connections? the cache-control information on the 301 response (which is what is cached) would govern revalidation.
dragana - I still don't understand why this isn't a dup of bug 968273
(In reply to Patrick McManus [:mcmanus] from comment #23) > dragana - I still don't understand why this isn't a dup of bug 968273 This is not a dup of bug 968273. That bug should start revalidating from the original uri. Here we do start from http://192.168.1.1 (the original one) but we go to the cache that has 301 stored and we redirect to https: 2016-07-22 05:39:42.900000 UTC - [Main Thread]: V/nsHttp nsHttpChannel::OnCacheEntryCheck enter [channel=a69464a800 entry=a6950546d0] 2016-07-22 05:39:42.900000 UTC - [Main Thread]: D/nsHttp nsHttpResponseHead::ParseCachedOriginalHeader [this=a68f7f9800] 2016-07-22 05:39:42.900000 UTC - [Main Thread]: D/nsHttp nsHttpResponseHead::ParseCachedHead [this=a68f7f9800] 2016-07-22 05:39:42.900000 UTC - [Main Thread]: D/nsHttp nsHttpResponseHead::ParseVersion [version=HTTP/1.1 301 Moved Permanently] 2016-07-22 05:39:42.900000 UTC - [Main Thread]: D/nsHttp Have status line [version=11 status=301 statusText=Moved Permanently] 2016-07-22 05:39:42.900000 UTC - [Main Thread]: D/nsHttp ParseContentType [type=text/html] 2016-07-22 05:39:42.900000 UTC - [Main Thread]: D/nsHttp nsHttpResponseHead::MustValidate ?? 2016-07-22 05:39:42.900000 UTC - [Main Thread]: D/nsHttp no mandatory validation requirement 2016-07-22 05:39:42.900000 UTC - [Main Thread]: D/nsHttp nsHttpResponseHead::ComputeFreshnessLifetime [this = a68f7f9800] Assign an infinite heuristic lifetime 2016-07-22 05:39:42.900000 UTC - [Main Thread]: V/nsHttp NowInSeconds()=1469165982, expiration time=4294967295, freshness lifetime=4294967295, age=431 2016-07-22 05:39:42.900000 UTC - [Main Thread]: V/nsHttp not validating, expire time not in the past 2016-07-22 05:39:42.900000 UTC - [Main Thread]: V/nsHttp Not validating based on expiration time 2016-07-22 05:39:42.900000 UTC - [Main Thread]: V/nsHttp Redirection-chain does not contain key http://192.168.1.1/ 2016-07-22 05:39:42.900000 UTC - [Main Thread]: V/nsHttp Will skip read of cached redirect entity 2016-07-22 05:39:42.900000 UTC - [Main Thread]: V/nsHttp nsHTTPChannel::OnCacheEntryCheck exit [this=a69464a800 doValidation=0 result=0] 2016-07-22 05:39:42.900000 UTC - [Main Thread]: V/nsHttp nsHttpChannel::OnCacheEntryAvailable [this=a69464a800 entry=a695a57ca0 new=0 appcache=0 status=0 mAppCache=0 mAppCacheForWrite=0] 2016-07-22 05:39:42.900000 UTC - [Main Thread]: V/nsHttp nsHttpChannel::ReadFromCache [this=a69464a800] Using cached copy of: http://192.168.1.1/ 2016-07-22 05:39:42.900000 UTC - [Main Thread]: V/nsHttp Skipping skip read of cached redirect entity 2016-07-22 05:39:42.900000 UTC - [Main Thread]: V/nsHttp nsHttpChannel::ContinueBeginConnectWithResult result [this=a69464a800 rv=0 mCanceled=0] 2016-07-22 05:39:42.900000 UTC - [Main Thread]: V/nsHttp nsHttpChannel::Starting nsChannelClassifier a695a57ac0 [this=a69464a800] 2016-07-22 05:39:42.900000 UTC - [Main Thread]: V/nsHttp nsHttpChannel::SuspendInternal [this=a69464a800] 2016-07-22 05:39:42.900000 UTC - [Main Thread]: V/nsHttp nsHttpChannel::OnLookupComplete [this=a69464a800] prefetch complete: success status[0x0] 2016-07-22 05:39:42.900000 UTC - [Main Thread]: D/nsHttp nsHttpHandler::NotifyObservers [chan=9464a848 event="http-on-examine-cached-response"] 2016-07-22 05:39:42.900000 UTC - [Main Thread]: V/nsHttp Waiting until resume to do async redirect [this=a69464a800] 2016-07-22 05:39:42.905000 UTC - [Main Thread]: V/nsHttp nsHttpChannel::ResumeInternal [this=a69464a800] 2016-07-22 05:39:42.905000 UTC - [Main Thread]: V/nsHttp nsHttpChannel::HandleAsyncRedirect [this=a69464a800] 2016-07-22 05:39:42.905000 UTC - [Main Thread]: V/nsHttp nsHttpChannel::AsyncProcessRedirection [this=a69464a800 type=301] 2016-07-22 05:39:42.905000 UTC - [Main Thread]: V/nsHttp redirecting to: https://192.168.1.1/ [redirection-limit=20] 2016-07-22 05:39:42.905000 UTC - [Main Thread]: D/nsHttp nsHttpHandler::NewProxiedChannel [proxyInfo=0] 2016-07-22 05:39:42.905000 UTC - [Main Thread]: V/nsHttp Creating HttpBaseChannel @9464b000 2016-07-22 05:39:42.905000 UTC - [Main Thread]: V/nsHttp Creating nsHttpChannel [this=a69464b000] 2016-07-22 05:39:42.905000 UTC - [Main Thread]: V/nsHttp HttpBaseChannel::Init [this=a69464b000] 2016-07-22 05:39:42.905000 UTC - [Main Thread]: V/nsHttp host=192.168.1.1 port=-1 2016-07-22 05:39:42.905000 UTC - [Main Thread]: V/nsHttp uri=https://192.168.1.1/
the cache is "poisoned". There is nothing wrong with using the cache here, the problem is that it is poisoned. You should be able to fix that corruption with a reload, however I believe we have a bug that says when you reload we reload the page that you were redirected to rather than the page that triggered the redirection. That is the essence of 968273 (though that problem can be driven either by the docshell history or the cache, which is part of the confusion about dup'ing.. but the solution seems to be the same - revalidate the earliest uri in the chain when doing reload). I think dragana and I agree on this now (out of band chat).
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago → 9 years ago
Resolution: --- → DUPLICATE
(In reply to Darien from comment #21) > What is stranger is that in the original request to the secure server, the > server specifies > "headers": [ > { > "name": "Cache-Control", > "value": "no-store, no-cache, must-revalidate, post-check=0, > pre-check=0" > } > ] > > So should't the client be revalidating in all subsequent connections? If the 301 response you get stuck on contains these cache response headers, then it's: - not stored across sessions (no-store) - is always revalidated (no-cache) But it's strange you mention that it's "the original request to the _secure_ server". But you said in comment 3 you were redirecting from (entering to the address bar) an http address. So where is the true?
(In reply to Honza Bambas (:mayhemer) from comment #26) > (In reply to Darien from comment #21) > > What is stranger is that in the original request to the secure server, the > > server specifies > > "headers": [ > > { > > "name": "Cache-Control", > > "value": "no-store, no-cache, must-revalidate, post-check=0, > > pre-check=0" > > } > > ] > > > > So should't the client be revalidating in all subsequent connections? > > If the 301 response you get stuck on contains these cache response headers, > then it's: > - not stored across sessions (no-store) > - is always revalidated (no-cache) > > But it's strange you mention that it's "the original request to the _secure_ > server". But you said in comment 3 you were redirecting from (entering to > the address bar) an http address. So where is the true? Yes, when I type http://192.168.1.1 into the address bar it autimatically uses the cached 301 request from the previous visit, even though the above headers are there.
(In reply to Darien from comment #27) > (In reply to Honza Bambas (:mayhemer) from comment #26) > > (In reply to Darien from comment #21) > > > What is stranger is that in the original request to the secure server, the > > > server specifies > > > "headers": [ > > > { > > > "name": "Cache-Control", > > > "value": "no-store, no-cache, must-revalidate, post-check=0, > > > pre-check=0" > > > } > > > ] > > > > > > So should't the client be revalidating in all subsequent connections? > > > > If the 301 response you get stuck on contains these cache response headers, > > then it's: > > - not stored across sessions (no-store) > > - is always revalidated (no-cache) > > > > But it's strange you mention that it's "the original request to the _secure_ > > server". But you said in comment 3 you were redirecting from (entering to > > the address bar) an http address. So where is the true? > > Yes, when I type http://192.168.1.1 into the address bar it autimatically > uses the cached 301 request from the previous visit, even though the above > headers are there. I did test that and it behaves as expected for me (not cached in a new session, revalidated on load). Are you offline?
Flags: needinfo?(jwilliams)
You need to log in before you can comment on or make changes to this bug.