8

I have just stumbled upon what is a very helpful flag in chrome (for developers):

chrome://flags/#allow-insecure-localhost

The flag is described as:

Allow invalid certificates for resources loaded from localhost.
Allows requests to localhost over HTTPS even when an invalid certificate is presented. – Mac, Windows, Linux, Chrome OS, Android

Having always had to generate self signed certs for multiple services this is great, but it begs the questions - is this secure? Is this secure to leave on all the time?

If this is not secure what are the attacks possible?

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
dendog
  • 185
  • 1
  • 1
  • 5

2 Answers2

13

It's most likely fine.

There are a few situations in which you want to communicate with localhost using HTTPS - such as running a local webserver for web development purposes or some other service that offers a web interface.

The way to do it "properly" is to generate a self-signed certificate, set up your web server to use that certificate, and then manually import that certificate as a trusted certificate. This is a tedious process, and in order to remove this friction, browsers give you the option of pretending like https://localhost is sending some trusted certificate, even though it's not.

So is this secure? That depends on your threat model. For day-to-day browsing activities, you'll likely be fine. It's difficult for an attacker even in your local network to impersonate localhost, since it's written directly in your hosts file, which on most setups has higher priority than DNS - which means even with a compromised DNS server, connections to localhost still would not be redirected to the attacker.

So why is this not the default if it's most likely secure? Because it's not the "expected" behavior of a browser. The expected behavior is that upon connecting to a host using HTTPS, the certificate is validated and the connection is refused if the certificate is invalid. You as end-user have to make a conscious decision to change this behavior and allow this exception.

So when would this be insecure? When would it actually pose a threat? To be honest, I struggle to think of an example that isn't completely contrived. Strange hostname resolution configurations in which localhost would be resolved via DNS and spoofed to be some host other than 127.0.0.1 would come to mind, but that is a very unlikely scenario, and one in which the user has to go out of their way to configure their system to be vulnerable. However, I don't want to say "it is perfectly fine in every possible setup", since there is always a chance I am missing something.

0

A similar situation is issuing a certificate (for example, from an internal corporate CA) with

dNSName = localhost
iPAddress = 127.0.0.1

I doubt any publicly-trusted CAs will issue a cert for localhost, so a setting like this is probably needed to make cert errors go away? (assuming you don't want to add the cert to your trust store, which is a way bigger risk).

I haven't yet run across a situation where this as dangerous; ie any attacks I can think of require the attacker to already be running code on the victim's computer.

One caveate I guess is if you install a lot of apps (fat clients) on your machine that host a local webserver so that browsers can interact with them. For example imagine a fat client for mikesgames.com that lets a browser game directly access your USB devices. Fine if you trust the app and know it's there, but it's hard to secure that local service properly, so you may be opening up for any random website to check for this fat client and then take control of your USB devices. I'm especially skeeved out by the idea of random websites probing localhost to see what ports you have listening and from there figuring out what fat clients you have installed.

I would prefer to see browsers by default block any connection to localhost with a popup "Do you want to allow mikesgames.com to communicate with apps on your machine?". If you click Yes, I don't think there's that much security difference between http, https with invalid cert, https with valid cert for those localhost connections. You would hope that app vendors have a way for the website and the fat client to mutually-authenticate each other to prevent abuse of the fat client by other sites, but that's really outside the scope of browser settings.

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207