Open Bug 1390648 Opened 7 years ago Updated 2 years ago

"Connection is Not Secure" message appears even for 127.0.0.1

Categories

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

54 Branch
defect

Tracking

()

UNCONFIRMED

People

(Reporter: flarn2006, Unassigned)

Details

(Whiteboard: [domsecurity-backlog1])

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170612122310

Steps to reproduce:

1. Start any application that runs a local HTTP (not HTTPS) server.

2. Navigate to a locally-hosted page in Firefox, via the name "localhost" or the IP "127.0.0.1".

3. Click the "(i)" icon to the left of the URL, and the arrow on the right of the popup.


Actual results:

The message "Your connection to this site is not private. Information you submit could be viewed by others (like passwords, messages, credit cards, etc.)." appears. This message is incorrect, as while connections to localhost go through the OS's network stack (specifically the local loopback driver), they never go through any actual network hardware or leave the computer in any way. It is simply an internal connection between two processes on the local computer, which could never be intercepted in any way by an attacker unless they've compromised your computer, in which case all bets are off and even HTTPS can't be trusted.


Expected results:

Whenever Firefox detects it's connected to localhost, even via plain HTTP, it should treat it as a secure connection and report it as such. Maybe even have a new message appear instead, saying something to the effect of "You are connected to another application on your computer. This connection is entirely within your own computer and cannot be intercepted."
Component: Untriaged → Security
Product: Firefox → Core
Component: Security → DOM: Security
Technically this is correct. Although localhost _should_ be the loopback address, in the real world some people have it resolve elsewhere. Google reports something like 0.3% of their DNS requests are for localhost!

Still, you're right. We fixed this for the mixed content blocker (no longer blocking http://localhost as insecure bug 903966) we could consider treating an original document as secure. On the other hand bug 1346835 directly contradicts this one. What's in the spec?

I'm not really concerned about the message when someone clicks the info box (who does that?). More relevant is that message is triggered by the same state that prevents the use of some features that are only allowed on a "secure" page, and developers might want to be testing those.
Priority: -- → P3
Whiteboard: [domsecurity-backlog1]

This seems to have been fixed now but I'm not sure if I can resolve it as such.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.