Deno: Require https for url imports

[brandonkal]

It would be interesting to require a specific scheme for url imports. If code attempts to use an insecure protocol for input (or because of redirect) the engine will die. This will help secure third party modules.

As a cli flag and with http allowed for localhost urls.

[sholladay]

It has become easier in recent years to setup HTTPS on localhost. It would be pretty awesome if Deno chose to be opinionated and didn't make any exceptions for localhost.

Resources:

• Automated way: https://github.com/FiloSottile/mkcert
• Manual way: https://www.freecodecamp.org/news/how-to-get-https-working-on-your-local-development-environment-in-5-minutes-7af615770eec/

[ry]

We will to match browser behavior on this - so until that changes we will support http.

[sholladay]

HTTP without TLS is deprecated.

• https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/
• https://wp-rocket.me/blog/googles-enforcing-https-website-ready-chrome-68/
• https://www.engadget.com/2019/10/04/chrome-security-block-http-content/
• https://security.googleblog.com/2019/10/no-more-mixed-messages-about-https_3.html

If Deno desires to be browser compatible even with legacy technology, then it should at least give better affordance to HTTPS. For example, it could _accept_ http: prefixed URLs, but automatically upgrade them to HTTPS. Or, if not, then it should respect the Upgrade-Insecure-Requests header and deno.land/x should always send that header.

[ry]

Thanks for the reference. Your suggestion makes sense to me.

[kitsonk]

Also, to point out, Service Workers require HTTPS as part of the specification, so yeah, the industry is trying to chip away at it. I agree it makes sense for Deno to not introduce deprecated concepts where it can.

[kevinkassimo]

And maybe respect HSTS that would be enforced even when scripts are reloaded

[brandonkal]

There is nothing in those links that suggests the HTTP protocol without TLS is deprecated. They only speak about the browser context (websites).
The articles just talk about blocking mixed content in browsers.

• HTTPS on localhost requires installing an untrusted CA, which often means you need root. No trusted CA will sign for localhost or a subdomain of localhost. The tradeoffs there just are not worth the risk.
• HTTP without TLS is still very useful on localhost. And there is no benefit to forcing HTTPS there. Browsers will never do it. They will always have an exception for localhost.

I see no "introduction of deprecated concepts" here.

[kevinkassimo]

IMHO http is definitely still useful and totally fine in some contexts, but there are also something that we might want to do such as mentioned in #1064

[sholladay]

I respectfully disagree. From the Mozilla article (emphasis mine):

Deprecating Non-Secure HTTP

Today we are announcing our intent to phase out non-secure HTTP.
...
Mozilla is committing to focus new development efforts on the secure web, and start removing capabilities from the non-secure web.

In other words, not only is plain HTTP deprecated, they are gradually breaking it. You may not like that plan, but it's where the industry is going. As @kitsonk mentioned, service workers require HTTPS, and that is the precedent that I strongly believe Deno should follow.

As for setting up HTTPS on localhost, follow the directions I linked to here.

[kevinkassimo]

My personal attitude is we can stop supporting HTTP imports once any one of the major browsers (Firefox/Chrome/Safari) drops HTTP just like that of FTP these days. But before that, the best thing we can do might be just warnings or using explicit flags...

[brandonkal]

@sholladay I'm well aware of how to set up https on localhost. My point is that it requires root and it is a bad idea. You install a new Root CA, which can then sign certificates for any domain. Once you've trusted it, any malware can cause your bogus CA to sign a cert for https://bank.com for example. You are much better off obtaining a public cert and configuring your DNS to resolve that domain to localhost.

From your notes:

Today we are announcing our intent...

Intent !== deprecation of a protocol.
Also localhost !== web. My point is no major browser will ever force https on localhost. It may disappear from the web (unlikely) but until then it won't be deprecated. And even then localhost will always be allowed.

I opened this issue to have a deno flag to force https for resources on the internet. Not to break localhost.

[kitsonk]

IMO as long as browsers treat localhost as an exception to HTTPS, which they do, then so should Deno.

[mathiasrw]

I suggest having to set a permission flag to allow using other protocols than https.

[solson]

Maybe this should be closed in favour of the more recently active https://github.com/denoland/deno/issues/7004? Nevermind: it's about disabling all HTTP, not just imports.

Participants of this thread would likely be pleased to see https://github.com/denoland/deno/pull/5680, which solves 90% of the issue for me.

[solson]

With #5680 in mind, I think that all we want is an --no-http-imports flag to also treat the top-level file as if it was imported via HTTPS, so deno run --no-http-imports foo.ts would error if foo.ts contained an HTTP import, the same way it currently does if foo.ts is imported from an HTTPS URL.

I would personally prefer this be the default behaviour, instead requiring a flag for HTTP, but we could also pursue the options listed in https://github.com/denoland/deno/issues/3632#issuecomment-575331995.

[nayeemrmn]

I don't think we need to do anything for top-level remote imports because they're under the user's control. That's why https://github.com/denoland/deno/pull/5680 is sufficient.

[solson]

That's a good point, I didn't quite think it through. I just confirmed that a top-level deno run https://... (or deno cache or deno install) with a script that imports from http://... is blocked, so I agree. I think this issue could potentially be closed.

[brandonkal]

Fixed by #5680

[sholladay]

And the deprecation continues.

https://blog.mozilla.org/security/2020/11/17/firefox-83-introduces-https-only-mode/