1410365 - (dev-https-everything) [meta] Improve secure context development experience

Status: NEW

(DevTools :: General, enhancement, P3)

Description

[Jonathan Kingston [:jkt] he/him]

Meta bug for secure context developer experience improvements.

Comment 1

[Glenn Linderman]

The real problem "little guy" developers face with secure contexts and development is their cobbled-together "local server".  Providing an easy-to-configure local server that serves files off of a local disk, and an easy-to-generate local certificate would go a long way toward solving the developer experience. It is a pain in the neck to configure Apache or IIS to run locally, and they bog down the local machine.  On the other hand, there will be some "big guy" developers that need all the facilities of Apache or IIS, but presumably they have more resources and knowledge of server configuration, and have development servers available.

For example, I develop using a Python HTTP server as my local server. It was not at all obvious how to configure it to do HTTPS, but I finally did. And then it was not at all obvious how to configure it to handle multiple requests simultaneously (which caused certain features of Chrome to hang the server), but then I finally found the right Google query and bug reports and comments to get me past that.  I deploy to Apache, but am no Apache expert for running it on my own machine. I finally figure out how to upgrade my self-signed certificate to use something more secure than SHA-1, to quiet the thousands of warnings being spewed to the web console.  None of this stuff is straightforward to the web developer that isn't also an IT administrator, and searching out all the pieces to put together to get it to work was time-consuming, even though once each piece was found, it wasn't terribly hard to perform the necessary steps.

So a light-weight server that supports multiple simultaneous requests, CGI, serves from a CWD, and comes with a tool to generate a modern self-signed certificate (maybe even generating its own internally on first use), would go a long ways towards enabling the "little guy" to be able develop comfortably using a secure context instead of complaining bitterly that secure contexts get in the way of development.

I did a survey of "light weight" server tools when I got stuck hanging my server trying to experiment with web apps in Chrome (which seems to have the lead in supporting same, hopefully Firefox will catch up soon). All the ones I found had some limitation that prevented it from being useful... one didn't support CGI, one supported CGI but only in cgi-bin, one seemed to support everything I needed, but was a library that had to be invoked from a self-written main routine, in a language I don't use, etc. So I was extremely happy to finally stumble across a comment telling me how to get my Python HTTP to do multiple requests.

Comment 2

[Glenn Linderman]

I didn't emphasize in comment 1 that having this stuff be well-documented is key. It would also be handy to have easily installable CGI plugins... I suppose PHP is popular enough to be one of them, and WordPress another. Personally I use a Python back-end, although it is invoked from the Python server via CGI so the environment is a bit more like when it is invoked from Apache via CGI.

I should mention node.js... that was easy to get running on my machine, but the cheapo web hosting services don't provide it, so it isn't really an option for "little guy" developers on the low end of the spectrum.

And the other problem with low-end deployment is the extra charges for certificates and private IP addresses to support the certificates. There needs to be a solution for using HTTPS with shared IP addresses, so that web hosts can't offer teaser rates for HTTP, and quadruple them when you add private IP address and HTTPS.... today, the only solution for that is to redirect from one's own HTTP domain, to the host's HTTPS domain: instead of  http://www.mydomain.com/... you wind up with some atrocious thing like   https://www.cheapo-web-hosting.com/~accountname/...

Comment 3

[Julien Wajsberg [:julienw]]

I won't answer to all your points but this one:

> There needs to be a solution for using HTTPS with shared IP addresses,

This is possible for some time [1], the support is quite good now. 
[1] https://en.wikipedia.org/wiki/Server_Name_Indication

Comment 4

[r.otten]

The "little guy" isn't your only concern here.
What about the "big guy" that has server-infrastructure with load-balancing and HTTPS termination at the load-balancer. Local dev builds will run over plain HTTP in that situation. Depending on what tech stack and frameworks are in use it can be quite a pain to configure solutions to run with HTTPS locally, and without when deployed.

You can solve that easily enough though: offer a way to white-list domains.

Comment 5

[Glenn Linderman]

@Julien - thanks, I had heard of SNI. I guess the issue is whether the shared host is configured for that. Will investigate.

@r.otten - interesting. I'm "little guy" enough that I never thought about the case you mention, and while I can understand the situation and concern, the big guy should be able to configure a solution to have a (copy of) the load-balancing front end in front of the development server: testing in any other way might be useful for some things but until tested with the load-balancing front end in place, would not test everything, so deployment of something not tested with the front end in place would be risky, especially if configured differently regarding HTTPS.

Comment 6

[r.otten]

@glenn
It's not a deployed internal testing environment that's the issue. The issue is with doing development work on a web solution and needing to run it locally on the workstation of the developer.

Just having 'localhost' white-listed would solve the base problem. 
(Is it already? I think this is what Chrome does, atleast...)

However, just that is not enough.
Sometimes third-party software your solution relies on a domain name and won't accept localhost. What you eventually end up with to make that work is adding a host mapping for something like `local-dev.example.com` to `127.0.0.1` and accessing the locally running site like that.

This is why a configurable white-list is a must.

Comment 7

[Damian Yerrick]

Using any sort of localhost solution when testing a mobile site would require porting a proxy to each mobile operating system. Would Apple allow it?

Comment 8

[Glenn Linderman]

@damian Android has a reverse proxy as part of recent versions ADB, so the Android device can be connected via USB to the host running a localhost server, and everything works. So I'm not sure what kind of proxy you are talking about porting, but maybe there are two possible proxy options.

Comment 9

[Cam]

Just my 2¢, just allow a whilelist of domains to treat equivalently to localhost. That'll allow people on my_hostname.local mdns domains, localhost, 127.0.0.1, or whatever variant of dev.example.com that they use to work.

Comment 10

[Victor]

I think there should be no discussion at all that 1) localhost is not enough; and 2) media.devices.insecure.enabled it's heavy artillery. A whitelist or a command line switch (like --unsafely-treat-insecure-origin-as-secure in Chrome) may be a perfect solution.

Comment 11

[Darkspirit]

IMHO all these *.insecure.enabled prefs should be removed.
Please run a local https server like nginx (Linux, Windows, MacOS) with https://github.com/FiloSottile/mkcert to test your application properly and avoid any occurences of http:// and ws://. You could also use it as reverse proxy in front of your http://127.0.0.1:port/ app.

Comment 12

[Cam]

@Jan if that were feasible that would be nice, but dictating that everyone use nginx is pretty unrealistic. And some people are already working on projects that use the webpack dev server directly or indirectly (for example create-react-app uses it under the hood and doesn't allow configuring it without creating a LOT more ongoing work for yourself).

Honestly anything that resolves to 127.0.0.1, ::1 or the like should be treated the same as localhost for the purpose of trust.

Comment 13

[zbinyakov]

since 4 years, any update ? It is pretty sad to not able to run app enclosed in docker vpn, just because there is not enough wish to make our life more easy.

Comment 14

[Hadrien DELAITRE]

Pls, we need this feature for FF. It's the only LAST reason that I am still using Chrome today.

Comment 15

[Leo Zhen]

My company build the code-server on top of http connection. it there any way to select that these urls are secure? like Insecure origins treated as secure in microsoft edges

Comment 16

[Alex]

Please run a local https server like nginx (Linux, Windows, MacOS) with https://github.com/FiloSottile/mkcert to test your application properly and avoid any occurences of http:// and ws://. You could also use it as reverse proxy in front of your http://127.0.0.1:port/ app.

How's that going to help us observer SSL certs for IP addresses? Not many issuers provide us with direct certs for ips.