8

I understand that modern HTTPS protocols are secure enough for an average user.

However, since these protocols need to fetch files from the server while the file protocol just tells the browser to find the file in your computer, I think file protocols are more secure than HTTPS protocols.

Thus, why are browsers marking HTTPS protocols secure while marking file protocols not secure?

Peter Mortensen
  • 877
  • 5
  • 10
freezable
  • 118
  • 8

3 Answers3

18

The Connection is secure badge is in respect to the information transmitted via the network / internet. As you correctly observed, the file:// protocol uses no network connection, neither a mechanism to secure the same (because there is none), hence the badge absent.

Note that the browser does not label the file:// protocol as insecure. The browser simply has no reason to notify about the presence of security mechanisms that TLS provides.

ig-dev
  • 1,118
  • 5
  • 13
  • Hi! Thank you for your answer. However, I observed that, in Firefox, there is a broken lock icon in the information menu for file URLs. If file URLs are not explicitly marked as insecure, I expect Firefox to not display an icon at all. Thus, I doubt if there is a reason that they are explicitly marked as insecure by Firefox. Or should I just treat them as a bug in Firefox? – freezable Nov 23 '19 at 23:51
  • Is the icon really "broken", or just open? In the latter case, the above reasoning still applies. On my Firefox (v.69) it just shows an "info" symbol with the detail `This page is stored on your computer`. – ig-dev Nov 24 '19 at 00:20
  • The icon is really "broken". It's a grey lock with a red slash with the detail `This page is stored on your computer` on my Firefox (v.70). – freezable Nov 24 '19 at 00:38
  • I've now seen the icon you are talking about. When you open the connection details, it's an (arguably) closed lock that has a red dash crossing it out with `This page is stored on your computer`. I take this to mean that security mechanisms are absent, as described above. Not that "the connection is insecure". Otherwise I'd consider it a bug. I agree though that grey for the dash would have been a better choice of color than warning-red. – ig-dev Nov 24 '19 at 00:47
  • Thank you. That's helpful. – freezable Nov 24 '19 at 00:49
4

I think file protocols are more secure than https protocols.

You would be correct, if the file is coming from local storage.

What if you are loading a file from an FTP mount (FTP protocol has no security, even passwords are sent as plain text)? Or from a remote (insecure) service over unencrypted wifi? A consumer access point with an attached drive could be set up like this.

The browser has no way of knowing if any of these connections are in fact secure. And even if it was possible to determine if direct filesystem links were secure, we cannot know if the next step in the chain is.

So, the browser simply doesn't guarantee what it doesn't know.

peter
  • 49
  • 1
  • I wonder if would be practical to have a standard for a "self-authenticating URL" which would contain a hash of either the resource identified thereby, or a header in the resource which would in turn contain hashes of particular parts of its content (avoiding the need to retrieve everything before being able to trust anything). – supercat Nov 23 '19 at 19:36
  • Hi. Thank you for your contribution. This seems reasonable. However, if that is the case, I would expect Chromium to treat all file URLs insecure. (Now it does not indicate if it is secure.) At least, if security cannot be determined, it's better to treat it as not secure. Just as any CA that haven't gone through an audit cannot be trusted. – freezable Nov 23 '19 at 23:53
  • 3
    The browser does not care what happens beyond the point of contact, i.e. the remote server, or the local file-system. Even though unlikely, the remote HTTPS server could also simply forward the request via HTTP to some other server, or transmit information in other insecure ways. It's only making a statement about the connection it itself holds. So the above reasoning is not correct – ig-dev Nov 24 '19 at 00:23
  • This isn't a good answer. The browser can't verify the next hop in the case of HTTPS servers either. In fact, it's very common to terminate HTTPS and then proxy on via plain HTTP. – Brad Nov 24 '19 at 05:47
  • @Brad @ ig-dev you are correct about https to the server. But the question asks about the file: protocol. So your comment is out of scope. – peter Nov 25 '19 at 00:47
0

Actually, file:// isn't as secure as one might thought.

Suppose we're in a login session with bunch of background processes running as the user, there's no bullet-proof guarantee that some of these processes might modify the file a user might open in their browser.

Remember the 2017 WannaCry virus storm was executed over bad SMB implementation. Who is to say someone on the LAN won't exploite remote code execution to modify other people's files?

DannyNiu
  • 328
  • 2
  • 14