I see no reason not to blindly trust localhost - there is no way to MITM the connection anyway.

Of course you can mitm localhost. The privileges required to do so just usually happen to come packaged with ones that obviate the need.

That's interesting. I've never tried so I don't know, but can you issue an SSL cert to CN "localhost" or does it need a fully qualified ___domain name?

In don't think any ca is going to give you a cert for local host, but open ssl is happy to make a self-signed cert for random single-word CNs, and chrome will trust them if you tell it to.

Couldn't you make your own root authority, install it locally, and sign a wildcard cert to cover your dev websites?

For example, if they're all *.local that wouldn't be easily abusable.

That's a heck of a lot more complicated than

    python3 -m http.server

and then opening http://[::1]:8000/ in your web browser.

But then again, carrier-grade NAT means that anyone who is tinkering like this has to do some sort of NAT-punching to show their work off to a friend, so maybe this could be solved by an automated wrapper ala localtunnel or ngrok.

    openssl s_server -accept 4443 -WWW -cert mycert.pem

Is not much more complicated.

Especially not when you pretend mycert.pem magically already exists, costs nothing yet works on all your subdomains, and that Firefox/Chrome trust it.

That's a lot of trouble to go through that I don't today. Everything in production is fronted by a load balancer that terminates SSL, so I never have to worry about SSL certs in the course of a normal day.

It's a bit of trouble because no project has made it really easy yet.

All-in-all, this is something that could easily be made into an app and automated.

No, it's a bit of trouble because security takes time to set up. To automate this, you would need a CA that is trusted by your (and the rest of your team's) browser that also creates arbitrary certs upon request. You can see why this is a bad idea.

Secure versions of this exist - and the security requirements they introduce are part of the reason enterprise IT is so much of a pain in the ass.

Honestly, I have no problem with plain HTTP support being available but only enabled via about:config. If you are a developer, sure go for it. Having said that, the suggestion of running your own CA for your dev environments takes less time to grok and set up than Python's VirtualEnvWrapper.

It's not running your own CA that's the problem; it's remembering how to integrate with it for every project you do. Especially considering almost nobody runs SSL on their web apps - you will almost always terminate SSL at a load balancer of some sort, so it's not something web developers normally need to worry about nor is it reflective of how apps run in a production environment.

Turns out, not everybody runs an AWS-style setup with a load balancer and backend servers. In some cases that's not what you want.

Regardless, we are talking about users' browsers dropping plain HTTP. These browsers will never hit your backend servers, so you need not worry about them. In your scenario, they'll always use HTTPS. You are worried about your one in a million case as a developer. That's fine, go into about:config and enable plain HTTP. Everyone else isn't an expert in security and shouldn't be allowed to shoot themselves in the foot by default.

I would be in favor of more of an alert-based implementation. i.e. if you go to a page that is HTTP, your address bar turns red with an "insecure" icon. A setting in about:config is ok, just a minor pain in the ass because I'll have to Google it any time I need to use it.

Good. I guess we are more or less on the same page. My only qualm about permitting plain HTTP and giving a passive alert is that it allows an attacker to run arbitrary JS on your machine before you notice that it was loaded over plain HTTP and decide to disable it. However, this may be a very good transition step.

Terminate SSL at a local 'load balancer' (nginx, haproxy, vulcand) - voila, your setup is now substantially more similar to production.

I think easing the setup of personal/enterprise CAs would be hugely useful to gaining adoption. Imagine a CA hosted by Google or the like that's tied your personal or business account where you can authenticate certs. Trusted if it's your own (or vouched by a trusted second party).

Why does it have to be valid?

Chrome already blocks self signed certs out of the box.

... and then you click the "Advanced" link and click on "Proceed to x.x.x.x (unsafe)"

Not always - some "unsafe" cipher combinations it will simply refuse to load with no workaround. Though you usually only see this on dodgy IoT gadgets out of China/Korea.

I've encountered that a bunch of times. I understand needing to make it look dangerous and deterring people who don't know what they are doing from continuing, but it's silly of Chrome not to offer any way of proceeding for people who do know for certain that they want to.

Unlike FF, Chrome doesn't offer an option for a permanent exception once you click "Proceed to ..."

I recently set up a self-signed cert for a development site, and Chrome remembered it until I told it to forget it (so I could install a CA-signed cert).

It does, just not on the warning page like ff does. You can install your self-signed cert in the settings panel.

if you're on a mac, you can add the cert to your keychain and then all your dev sites that operate over *.dev will be fine.

> if you're on a mac

Thanks. I know about that, but I am not on a mac.

This gets rather tedious after a few dozen times.