1330795 - Basic HTTP auth fails on Linksys WRT120N - Upgrade-Insecure-Requests related?

Status: RESOLVED WONTFIX

(Core :: DOM: Security, defect, P3)

Description

[David C. Mores]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0 SeaMonkey/2.46
Build ID: 20161213183751

Steps to reproduce:

I am trying to login on my Cisco/Linksys WRT120N home router admin page at http://192.168.0.1/ using Firefox.  I get a pop up window prompting for 'A username and password are being requested by http://192.168.0.1. The site says: "WRT120N" '. 


Actual results:

Clicking the OK button after entering the login info causes the window to close, but pop up again.  This repeats as long as you continue to click OK.  Clicking the Cancel button results in an error page:

401 Authorization Required
Browser not authentication-capable or authentication failed. 


Expected results:

The login should have completed successfully and rendered the router admin page.

Comment 1

[David C. Mores]

This same login process completes successfully on the Google Chrome or MS Edge browsers.  It also completes successfully on Seamonkey 2.40, but not on Seamonkey 2.46.

Comment 2

[Loic]

Is there a public demo of this router firmawre to reproduce the issue?

If not, could you save the page, testit locally to see if the bug is here and if that's the case, zip it and attach it to the bug report.

Comment 3

[David C. Mores]

Attachment: 401 error page

Not sure if this is what you want.  I does not show anything new

Comment 4

[David C. Mores]

There is no public demo available on this issue that I am aware of.

I am not clear on what you are asking for that could help you test it.  Save what page specifically?

My take on this is:  As I understand it, the Seamonkey browser migrates in changes in Firefox code.  Between Seamonkey 2.40 and 2.46 the Firefox changes likely broke Firefox and consequently Seamonkey code on this issue.  I do not know what version of Firefox corresponds to Seamonkey 2.40

Comment 5

[David C. Mores]

Attachment: The login info pop up page

This is the login pop up window that prompts for the username/password info.

Comment 6

[Ciprian Muresan [:cmuresan], Ecosystem QA]

Could you please try to reproduce the issue on the latest Firefox release 50.1 (https://www.mozilla.org/en-US/firefox/new/) and on the latest Nightly (https://nightly.mozilla.org) and post your results?

Comment 7

[David C. Mores]

Firefox 50.1 and Nightly 53.0a1 both fail as originally reported.

Comment 8

[Ciprian Muresan [:cmuresan], Ecosystem QA]

Thanks for the fast response. Could you also check check and see if there are any errors that appear in the Browser Console (Ctrl+Shift+J) as you are trying to log-in and post a screen shot if there are any?

Comment 9

[David C. Mores]

After I enter the login-in info and click OK, there is one line in the Browser Console window as follows expanded:

GET 
http://192.168.0.1/ [HTTP/1.0 401 Unauthorized 219ms]
Headers
Response
Response body was not stored.

Sorry, I do not know how to make/save a screen shot.

Comment 10

[Ciprian Muresan [:cmuresan], Ecosystem QA]

For making and saving a screenshot I do the following:
Press Prt Scrn (the keyboard button), then go into Paint and press Ctrl+V and then save the image somewhere on the local drive. 
If you want to save a specific window you need to click the window in question and press Alt+Prn Scrn, then do the same thing as above in Paint.

Comment 11

[David C. Mores]

Attachment: Screen shot of browser console per request.

Comment 12

[Loic]

David, did it use to work with old versions on Firefox?
http://ftp.mozilla.org/pub/firefox/releases/

Comment 13

[David C. Mores]

Ran the following versions:
Nightly 53.0 Broken, updated today
50.1 Broken
46.0 Works
49.0 Broken
48.0 Broken
47.0 Works
47.0.2 Works

So it would seem that it broke between versions 47.0.2 and 48.0.

Comment 14

[Loic]

So there is definitively a regression since FF47.
As you're able to reproduce the issue on your machine, could you download the tool Mozregression and find a regression range in FF47.
See http://mozilla.github.io/mozregression/ for details.

Run "mozregression --good=46" and copy here the final pushlog.

Comment 15

[David C. Mores]

Final output from "mozregession --good=47" is in attachment.

Comment 16

[David C. Mores]

Attachment: mozregression run requested

Comment 17

[Loic]

Instead of a screenshot, it's possible to select and copy the console output. ;)

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=8a9823b951f6af481fe247fb5a57dac5a2f8bf13&tochange=471a58815a860a006858c5c8b5bfc6838b65719a
Christoph Kerschbaumer — Bug 1243586 - Implement Upgrade-Insecure-Requests HTTP Request Header Field. r=rbarnes 

It could be a TE bug.

Comment 18

[David C. Mores]

Sorry, no.  At first I tried unsuccessfully to copy/paste it, but that did not work for a command prompt window (Windows 10).  The mozregression process was long and tedious - not something I would like to do again.

Comment 19

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Loic from comment #17)
> https://hg.mozilla.org/integration/mozilla-inbound/
> pushloghtml?fromchange=8a9823b951f6af481fe247fb5a57dac5a2f8bf13&tochange=471a
> 58815a860a006858c5c8b5bfc6838b65719a
> Christoph Kerschbaumer — Bug 1243586 - Implement Upgrade-Insecure-Requests
> HTTP Request Header Field. r=rbarnes 

I doubt that adding a new request header will cause this problem. Setting the uir request header just indicates that the connecting user agent understands upgrade-insecure-requests. I would imagine that the header is just ignored if not used. I would also imagine that Chrome sends the same request header. If there is more evidence that Bug 1243586 caused the problem or potentially some STRs, I am happy to take a closer look.

Comment 20

[Loic]

Patrick, do you have an idea to help the user about finding the regressing bug about FF not able to log in to the router admin page, like saving a connection log?

Comment 21

[Patrick McManus [:mcmanus]]

I wouldn't rule out some kind of screwed up sensitivity to the request header.. probably worth a try build that just doesn't send the header to see if that makes it work.

Comment 22

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Patrick McManus [:mcmanus] from comment #21)
> I wouldn't rule out some kind of screwed up sensitivity to the request
> header.. probably worth a try build that just doesn't send the header to see
> if that makes it work.

For what it's worth, you would have to comment out that code:
https://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/nsHttpChannel.cpp#344

Comment 23

[Daniel Veditz [:dveditz]]

(In reply to David C. Mores from comment #0)
> Clicking the OK button after entering the login info causes the window to
> close, but pop up again.  This repeats as long as you continue to click OK. 
> Clicking the Cancel button results in an error page:
> 
> 401 Authorization Required
> Browser not authentication-capable or authentication failed. 

You're getting the same error in both cases. If you enter a bad password the site returns a 401 so we re-show the dialog, until you give up and hit cancel at which point we go ahead and display the 401 response. In this case apparently some other error is causing the site to return 401, but Firefox doesn't know why so it assumes you'll want to try the password again.

Comment 24

[Christoph Kerschbaumer [:ckerschb]]

I did a TRY push with the code in question commented out, from there you should be able to download a binary. Can you try this version and see if the problem still occurs?

https://treeherder.mozilla.org/#/jobs?repo=try&revision=3952851996696c4573f2dc4775ce3c70995ecc37

Comment 25

[David C. Mores]

I would be glad to try it, but clicking on your link brings me to a page where it is entirely not obvious what to do next.  Clicked on various links with nothing but confusion resulting.  Please be more specific.

Comment 26

[Loic]

(In reply to David C. Mores from comment #25)
> I would be glad to try it, but clicking on your link brings me to a page
> where it is entirely not obvious what to do next.  Clicked on various links
> with nothing but confusion resulting.  Please be more specific.

Download the zipped build (firefox-54.0a1.en-US.win32.zip) from here:
https://archive.mozilla.org/pub/firefox/try-builds/[e-mail]-3952851996696c4573f2dc4775ce3c70995ecc37/try-win32-debug/

And test it with your router.

Comment 27

[David C. Mores]

It works!  The router login was completely successful.

Comment 28

[David C. Mores]

So where do you stand on this?  If the request header is the problem, is the path to resolution clear?

Comment 29

[Loic]

Christoph, what's is the next step after the user tested with success your try build in comment #24?

Comment 30

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Loic from comment #29)
> Christoph, what's is the next step after the user tested with success your
> try build in comment #24?

Thanks for testing David. Still surprises me and to be honest I would rather think it's a bug in the router's software than in Firefox. The only open question to me is, why does this work with Chrome? Are they not sending the upgrade-insecure-requests header? In fact they should, but maybe Chrome does not follow the spec precisely there. At this point I rather close this bug as invalid.

Comment 31

[David C. Mores]

Christoph: It's not just Chrome that works; it's Microsoft Edge too.  Surely, it's not just a Chrome fluke.  Two different browsers from two different vendors work successfully.  It seems to me that this favors a problem with Firefox.

I would be willing to try other vendor's browser or other tests, that you would recommend, if you wish.

Comment 32

[Christoph Kerschbaumer [:ckerschb]]

(In reply to David C. Mores from comment #31)
> Christoph: It's not just Chrome that works; it's Microsoft Edge too. 
> Surely, it's not just a Chrome fluke.  Two different browsers from two
> different vendors work successfully.  It seems to me that this favors a
> problem with Firefox.

Beats me.

Firefox: 
> Host: cnn.com
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:50.0) Gecko/20100101 Firefox/50.0
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> Accept-Language: en-US,en;q=0.5
> Accept-Encoding: gzip, deflate
> Cookie: ...
> DNT: 1
> Connection: keep-alive
> Upgrade-Insecure-Requests: 1

Chrome:
> GET / HTTP/1.1
> Host: cnn.com
> Connection: keep-alive
> Upgrade-Insecure-Requests: 1
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
> Accept-Encoding: gzip, deflate, sdch
> Accept-Language: en-US,en;q=0.8
> Cookie: ...

So for regular pages, that means Chrome also sends the upgrade-insecure-requests header. Maybe it does not send it for all top level loads as Firefox does. Can you check the request headers for Chrome and Edge when connecting to your router?

Comment 33

[Daniel Veditz [:dveditz]]

I see an Upgrade-Insecure-Request: 1 header from Chrome when connecting to my 192.168.x.1 home router

Comment 34

[Daniel Veditz [:dveditz]]

(In reply to David C. Mores from comment #31)
> Christoph: It's not just Chrome that works; it's Microsoft Edge too. 
> Surely, it's not just a Chrome fluke.  Two different browsers from two
> different vendors work successfully.  It seems to me that this favors a
> problem with Firefox.

Yes, but the problem WENT AWAY when we dropped a newly-specified header. That makes it sound like a router intollerance to that header. But chrome also sends that header. Edge does not so we would not expect a problem with Edge.

Unless you have an ancient version of Chrome? That would be surprising given their aggressive self-updating, but maybe you've disabled that and upgrade manually?

Comment 35

[Daniel Veditz [:dveditz]]

Going to be hard to fix if we can't reproduce this. Would it be possible for you to make/attempt the connection in each browser with the DevTools open to the Network tab in each browser and capture both the request headers and the response headers for Chrome and Firefox and paste them into this bug?

Comment 36

[David C. Mores]

Been thinking about this for awhile and trying things.

Another browser works just fine: OPERA 43.0

I tried to get Chrome and Firefox request and response headers, but no luck using "inspect element" for the page.  The problem is that the pop up window for the router login seems to get in the way of seeing any request/response network dialog - hence my delay for a "period of thinking".

Normally a login process presents a page with a form for login/password - NOT a popup window.  This seems to me rather uncommon.  So I'm thinking that perhaps something is going on that corrupts the transfer from the popup login window to the request header (if that contains the login info).  Perhaps you could reproduce this problem if you could fine a similar behavior for something that causes a pop up login window.  I cannot suggest one.  My login id is 'admin' (no quotes) with a 12 character password.

I assume that since versions 47.0.2 and 48.0 of Firefox (where it worked/broke) both made request headers, some corruption got in 48.0 - id/password got copied an maybe overflowed some array of something.

Comment 37

[Daniel Veditz [:dveditz]]

Most web pages use cookie-based authentication, but there's an older way to authenticate using the HTTP protocol. This is typical on home routers and results in the popup you're seeing; very uncommon on web sites because they like to control the presentation of the login.

I saw in the screenshot of the browser console several messages about unsafe/forbidden CPOW usage. Do you have a bunch of add-ons installed? Could be completely unrelated, but could you try this in a fresh profile or in "safe mode" (add-ons disabled) and see if you get the same results?

Comment 38

[David C. Mores]

I have no add-ons other than what is normally provided.  Restarting in "safe mode" makes no different - same results.  

Can anyone suggest a public site that uses the "older way" to authenticate using the HTTP protocol or whip something up for the same purpose.  I am not technically savvy on this, so I cannot do this.

Comment 39

[David E. Ross]

I have a Netgear N300 Wireless Router (WiFi disabled) that I bought new a little over a year ago.  For me to logon, it uses a popup for me to enter a user ID and password in an HTTP session, not HTTPS.  I have no trouble doing that.  

If this is "the 'older way' to authenticate", what information would you like me to collect to diagnose your problem?

Comment 40

[David C. Mores]

DER: what browser are you successful with?  Is it Firefox and what version?  Per the above discussion (Comment 36) older versions of Firefox work and later ones do not for me and my router.  If you can duplicate working/not working cases, then can you provide the network data request/reply dumps that others have requested?

Comment 41

[David E. Ross]

Attachment: headers.txt

Headers captured by the LiveHTTPheaders extension during login to Netgear N300 Wireless Router

Comment 42

[David E. Ross]

Attachment: warnings.txt

Error Console warnings captured during login to Netgear N300 Wireless Router; no errors or information entries

Comment 43

[David E. Ross]

Re: comment #40

Windows 7 Ultimate SP1 (x64)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:49.0) Gecko/20100101 SeaMonkey/2.46

See attachments "headers.txt" and "warnings.txt".

Comment 44

[David C. Mores]

Thanks for the dumps.  Apparently you used Seamonkey, which I used too, where I first encountered my router login problem.  I reported on Firefox because it malfunctions too and is the basis for Seamonkey.

The dumps do not seem to show anything relative to the login dialog - i.e. I cannot see any text showing the login id and password being sent to your router.  Maybe others can still see useful info.  Anyway, seeing a successful login dialog with the correct id and password and a failed login dialog with the correct id and incorrect password may shed more light on the problem.  If you can do this, I would recommend that you obscure your passwords in any posted attachments.

Comment 45

[Daniel Veditz [:dveditz]]

I don't know how to proceed here.

* a special build seems to indicate the UIR header caused a problem
* Chrome also sends the UIR header but does NOT have a problem
* Linksys routers are popular with millions in the field. Where are the duplicate bugs?

At this point I'm hoping 1) you have an ancient router that few people have, and 2) an ancient non-updating Chrome that doesn't send the header. Neither seems likely, but I can't think of another explanation for the above facts.

Comment 46

[David E. Ross]

I am sorry, but my Netgear router is the only situation where a login results in a popup for input of user ID and password.  Also, SeaMonkey 2.46 is my browser of choice.  I do not have -- and will not install -- any version of Firefox.  I do have Internet Explorer 11, but I do not know how to capture the data required for diagnosing this bug.

Comment 47

[Daniel Veditz [:dveditz]]

(In reply to David C. Mores from comment #44)
> The dumps do not seem to show anything relative to the login dialog - i.e. I
> cannot see any text showing the login id and password being sent to your router.

The http-auth ("popup") is triggered by the 401 response with the header
  WWW-Authenticate: Basic realm="NETGEAR WNR2000v5" 

The logging-in is done by re-sending the original request with the header
  Authorization: Basic YWRtaW46a3lOMVFIbXI3

"Basic" auth is terrible and essentially sending the results in the clear, but that's a short-coming in the router that you can't fix. "Digest" is what the router should have used.

David E. Ross: you probably want to change your router password now.

Comment 48

[David E. Ross]

As I stated in comment #46, I will not provide any data for diagnosing this bug using a browser other than SeaMonkey.  If I can provide more data via SeaMonkey, someone will have to tell me what data and how to collect it.  

Yes, I changed my password for my Netgear router.

Comment 49

[Daniel Veditz [:dveditz]]

I am not asking for information from David E. Ross who is not experiencing this bug and is using a different browser and router from the person who reported it. You don't have to keep telling us that.

What we need is more information from someone who _is_ experiencing the problem, or maybe someone with the same Linksys model and using Firefox who isn't so we can start teasing apart differences.



David C. Mores: have you tried testing in safe-mode or with a fresh Firefox profile? Since we're not getting the gazillion dupes I would expect if we broke Linksys log-in across the board it could be that some custom setting you have interacts badly with the upgrade to Firefox 48. Could be an extension you know you have, could be something your anti-virus is doing to the traffic, or could be some other preference setting. We should rule that out.

Start with safe-mode, it's easiest.
https://support.mozilla.org/t5/Procedures-to-diagnose-and-fix/Troubleshoot-Firefox-issues-using-Safe-Mode/ta-p/1687

Comment 50

[David C. Mores]

This problem for me started in Seamonkey, but I realized code comes from Firefox, so I checked it there where it failed too. See comments SM 1,4,44,46 and comments FF 13, 36 above.

I have tried safe-mode and fresh profile per comments 37 and 38 above.  Custom setting, extensions are not likely because I did not make any.  Seamonkey is my daily browser.  I used FireFox only to confirm my experience with Seamonkey.

New test idea:  I tried different length passwords for my router login.  My normal one is 12 characters.  I tried new router passwords of length 0,1 and 5 characters.  All failed for Seamonkey/FF, but worked for my other test browser Opera.

Comment 51

[Daniel Veditz [:dveditz]]

Jason: any ideas on this one? Did we make any networking changes in Firefox 48 that would break HTTP-auth on an old linksys router? We're stumped.

Comment 52

[Daniel Veditz [:dveditz]]

more info because TL;DR -- this broke for the reporter when the upgrade-insecure-request header was introduced (see comment 19), but he is not broken on chrome which sends the same header.

Comment 53

[Daniel Stenberg [:bagder]]

I'd like to shift focus to the *response* headers. I think everything said so far in this bug indicates that the router is actually sending back a 401 response to the proper HTTP request Firefox sends with the proper Basic encoded credentials.

And if the router is actually sending back a 401 to the otherwise correct request, the issue is actually more an interop issue with a (broken) HTTP server in the other end. I'm not suggesting we shouldn't work on finding a solution for this anyway, but I think it changes the nature of this a bit. If this is what happens, it would rather indicate that a specific header combination is to blame or perhaps even worse: that there's some sort of user-agent detection going on in the router that then behaves differently to different browsers/headers combos.

So, can you get a screenshot or something for us from the devtools or similar showing the response headers that Firefox receives back when it sent the login POST?

Comment 54

[David C. Mores]

Attachment: Requested screen shot for Daniel

It is not clear to me what you really mean by devtools.  The only thing I can find is to right click in my browser window and select Inspect Element.  Is this what you mean?  

A screen shot is attached, but showing "response headers" is not an obvious thing to do.  More specific instructions would be helpful.

Comment 55

[Daniel Stenberg [:bagder]]

Thanks!

I meant "Tools->Web Developer->Network" (Ctrl+Shift+Q), which you seem to have reached but when you click a specific request (the first one using the Basic auth) it should show you the request headers and the response headers.

In there, the request headers should include an "Authorization:" header that if you base64 decode the blurb at the end of the line is your "user name : password" (which you can verify with a base64 decode tool or online web service). The response to that HTTP request, which says 401 again since it for some still unknown reason doesn't accept the request, returns a set of headers and it would be interesting for us to see them. (Showing the Authorization: header reveals your username + password so feel free to edit it or change password after you show the used header to us.)

Do you happen to have curl installed on this machine? If you select the request with the authentication sent, and do "copy as curl", past that in a command line windows and exexcute it, what does it return? And of you manage to try this, can you show us what the curl command looks like and tell us what it returns? The curl command is meant to repeat the Firefox request very closely but with curl instead of Firefox, and it is then interesting to see how the server reacts to that. If it returns a 401 to that as well, it could be a tool to experiment with a little quicker to see exactly what is triggering this weird response.

Comment 56

[David C. Mores]

Attachment: More screen shots for comment #55

Comment 57

[David C. Mores]

Attachment: More screen shots for comment #55

Comment 58

[David C. Mores]

Attachment: More screen shots for comment #55

Comment 59

[David C. Mores]

Attachment: More screen shots for comment #55

This series of screen shots, per the request, show the before (1) during (2,3) and after (4).  I hope this is what you need.

Comment 60

[Daniel Stenberg [:bagder]]

I was expecting more details. When you see the screen as in comment #59, you can left-click the middle request (the second line with a "GET /") and it should split the tool section in two and use the other part to display request and response headers for that specific request. (You may want to expand that tool section then). I would like to see those headers!

Comment 61

[David C. Mores]

Attachment: More screen shots for comment #61

Finally - the headers.  Thanks for the training and your patience.
I changed the router password for this test.

Comment 62

[David C. Mores]

Attachment: Screen shot for comment #61

Per comment 13 where I found that ff 47.0.2 worked, I installed that version and rand it for the headers.  It still works and the screen shot attached shows the headers.  Hope this helps....

Comment 63

[Daniel Stenberg [:bagder]]

Now we're getting somewhere! In the 47 case, can you select the second "GET /" as well (the one that gets a 200 response) so that we get to see the successful request/response - the exact request that fails in the 52 case. Comparing those two will be educational and hopefully reveal something.

Comment 64

[David C. Mores]

Attachment: Screen shot for comment #63

Per your request.

Comment 65

[Daniel Stenberg [:bagder]]

As comment #19 was made by someone else, can you confirm if you can login fine with chrome on this router and if so, does it use the "Upgrade-Insecure-Requests:" header? It would surprise me.

I compare these two screendumps: https://bug1330795.bmoattachments.org/attachment.cgi?id=8857017 (FF52) and https://bug1330795.bmoattachments.org/attachment.cgi?id=8857455 (FF47) and it is clear that the requests are identical *except* for the UIR header. The 401 response that comes back in the FF52 case is clearly something that is decided by the server, and not the client even those they send identical bytes in the Authorization: headers. The exact same request minus UIR gets a 200 back, proven in the FF47 screendump.

I think everything this points to the culprit being a bad HTTP server. Unfortunately we don't provide any easy means of disabling the UIR header to allow us to work around this problem on a per-site or per-installation instance.

Have you checked if there's by any chance a router firmware upgrade available that possibly could change the behavior?

Comment 66

[David C. Mores]

I looked carefully at the headers too.  I noticed that the ff52 one contained a line with "Upgrade-Insecure-Requests: 1" and the ff47 did not.  I edited the ff52 request header to remove that line and resend it.  It succeeded with an OK response.  From what I can find about it at WWW org, it is (of course) a legitimate parameter.  But is it essential in the header?

I have found at the Cisco/Linksys site http://www.linksys.com/us/support-article?articleNum=148623 that there is a firmware update, but the release notes do not indicate to me that this problem is covered.  I have been reluctant to do the update and risk turning my router into a brick.  However, I do have another option.  I can set an option in the router for access via HTTPS which I have not tried yet.  I have been waiting to see what you would make of the headers that I finally provided.

I will proceed with my option and maybe the firmware update too.  I will advise.

Comment 67

[Daniel Veditz [:dveditz]]

(In reply to Daniel Stenberg [:bagder] from comment #65)
> As comment #19 was made by someone else, can you confirm if you can login
> fine with chrome on this router

In comment 1 (and others) the reporter said chrome (and Opera 43.0) worked. He has not said which version of chrome. Recent versions of Chrome do send that header (they added it before we did), though we don't know if the reporter's version is up to date.

Comment 68

[Christoph Kerschbaumer [:ckerschb]]

(In reply to David C. Mores from comment #66)
> However, I do have another option.  I can set an
> option in the router for access via HTTPS which I have not tried yet.  I
> have been waiting to see what you would make of the headers that I finally
> provided.

JFYI, I suppose using the HTTPS version is also not going to fix the problem because we send the upgrade-insecure-requests even for https loads, so probably it will result in the same problem.

Most interesting would be to know the version and/or what headers other browsers send.

[1] https://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/nsHttpChannel.cpp#377-390

Comment 69

[David C. Mores]

Attachment: chrome-58.0.3029.81-https.png

You are right - https://192.168.0.1/ does not work with router enabled for access via HTTPS.  I tried to use the "Inspect Element" mouse right click to inspect the request/response headers under the Network tab but could not find a way to do that from Chrome 58.0.3029.81 (64 bit) under Windows 10.

Comment 70

[David C. Mores]

Attachment: router-fw-upgrade.png

I tried to upgrade the routers firmware from 1.0.0.4 to 1,0.07.002 after download from the vendor website: http://www.linksys.com/us/support-article?articleNum=148623

However, that fails too for reasons I do not understand.  I'm running Windows 10 as the O/S.

Comment 71

[Daniel Stenberg [:bagder]]

In my efforts to get in touch with Linksys about this matter (as I believe it is an issue with the HTTP server in the router), I've communicated with the peeps behind the twitter account @LinksysCares (https://twitter.com/LinksysCares). They got back to me yesterday with the following message:

> "Apologies for this late update, Daniel. We've relayed your concern with our Engineering Team and since the WRT120N has already faced End-Of-Life for more than 6yrs - there are no more engineering resources to get for investigation. Moreover, since its software is already dated, continued use of this specific router may have security vulnerabilities that haven't been addressed yet. We highly suggest on investing in a new router instead."

Comment 72

[David C. Mores]

Daniel - Thanks for your efforts on my behalf.  I accept the Linksys advice.  I bought the WRT120N router in 2010, about a year before they declared it "E-O-L", and except for the issues reported here, it has performed to my satisfaction.  Anyway, time for a new router.  I am OK with you closing out this bug as you see fit.

Comment 73

[MAWA VANSMOOKEY]

Comment on attachment 8826862 [details]
401 error page

good

Comment 74

[MAWA VANSMOOKEY]

Comment on attachment 8826862 [details]
401 error page

fine

Comment 75

[David C. Mores]

I am okay with WONTFIX.  I have retired the router from service.