>Since Chrome v80 they forced <video> <img> content to switch to HTTPS, if the page itself is served https. Is it really a good idea? So for Intranet URLs with customize TLDs, you have exactly three choices

If the intranet isn't set up to be able to serve over HTTPS, then wouldn't the intranet page be served over HTTP too and not make this an issue? Is it really common to have intranet sites where you have some of the endpoints covered by HTTPS and some not, and further, the HTTPS intranet page embedding content from intranet HTTP sites?

> then wouldn't the intranet page be served over HTTP too and not make this an issue?

The page itself is served in both HTTP and HTTPS, can be visited in and outside the LAN.

The <img> and <video> content fail in HTTPS without explanation in Chrome v81+

> The page itself is served in both HTTP and HTTPS, can be visited in and outside the LAN.

So why can't you use one of these options:

1. Redirect all users to HTTPS, since you apparently already have a globally valid certificate.

2. Rewrite the tags to use HTTPS only when the page is loaded over HTTPS.

3. Set upgrade-insecure-requests only when the page is loaded over HTTPS.

Because the <img> <video> content is served on a LAN machine with custom TLD. HTTPS don't work with that.

However I can use reverse of your methods to redirect every HTTPS to HTTP.

When you say "the page itself" can be visited outside the LAN, does that include the images and videos? If it doesn't, what's the use case?

Inside the LAN, when you visit the page over HTTPS the URL bar has a globally valid domain, right? So why do you even want the LAN machine to have a custom TLD, if that's going to be invisible to the user?

> does that include the images and videos? If it doesn't, what's the use case?

Certain pages of have media content that can only be viewed in LAN. However since the the HTTPS page is used in and outside lan, users tend to keep visiting the site with HTTPS enabled. After Chrome upgraded to v81, the images and videos failed to load. And there is little site admin can do to quickly restore the access.

Can you not simply use a normal domain or subdomain and get a regular TLS certificate for it? The domain can still only be resolvable inside your Intranet using your internal DNS. You won’t need a special root CA in all browsers then.

By definition, ICANN TLDs are considered special, because the whole www PKI infrastructure only works for those. Browsers cater to those TLDs, and CAs have guidelines for those.

I understand the need for hiding your TLD though. I don't see a nice solution here, sadly.

In regards to point number 2: the Name Constraints extension[1] appears to be getting more support, at least in Chrome and Firefox on non-OSX devices[2], which could help mitigate the very serious vulnerability presented by installing root certificates, by limiting the CAs scope to just the company domain, for example.

[1] https://tools.ietf.org/html/rfc5280#section-4.2.1.10

[2] https://nameconstraints.bettertls.com/

The point is, with a customized TLD, we don't need HTTPS traffic of videos in a LAN. Serving whatever content we embed in a HTTPS page should be a constitutional right.

A custom tld is only custom until it's not (see .dev, .corp), and using them for intranet purposes is widely regarded as bad practice.

If you're already serving regular content over HTTPS internally, then I don't see the big issue in serving video and images the same way, but I'm not familiar with your particular use case so you may of course have a point here that I'm ignorant of.

> them for intranet purposes is widely regarded as bad practice

We are talking about the Open Web here. I think TOR wouldn't be as popular if we do not allow custom TLDs.

And I politely disagree with ICANN's new gTLDs expansion. domains like blog.google is wrong.

Can’t you just use a Let’s Encrypt cert? The domain needs to be publicly resolvable, but it doesn’t have to resolve to the same IP returned by your internal DNS, and you can use wildcard certificates if you don’t want your internal subdomains to be publicly resolvable at all.

> The domain needs to be publicly resolvable

The company TLD was purposely built to hide behind the LAN. Been publicly resolvable is a huge a security risk. Public recursive resolvers will log where and when a user visits an internal site.

Why not have the public resolver resolve everything to a “Your DNS is misconfigured; contact IT” static page?

Not if you use an internal resolver.

Now your internal infrastructure depends on let’s encrypt as well as an external DNS registrar.

Didn't you notice that monitoring all internal traffic is desirable in most companies, and sometimes is a compliance requirement? Didn't you notice that company-wide root certs were being pushed by corporate OS / browser policies for years, if not decades?

I really fail to see a point here. Can you please mention a compelling case?

> Didn't you notice that monitoring all internal traffic is desirable in most companies

No I did not. Sorry. Just because it's popular does not mean it should be implemented.

Also isn't HTTP content makes the whole monitoring crap easier? Sigh.

There are many BYOD companies, it's uncivil to monitor other people system wide.

Lastly, encrypt with TLS then MITM decrypt is not carbon friendly. It's such a retarded waste of energy. Might just allow a directive in CSP to force downgrade everything to http. Problem solved.

In every company in the US where I ever worked, my contract explicitly stated that all communications from company-provided devices belong to the company. I very much see the point. For private communication, use your own device and a guest network, a setup also seen everywhere. I haven't seen a BYOD setup that would allow whatever you please on the corp network. Did you? What industry it was? Genuinely curious; I believe a lot of things exist that I'm not aware of.

> isn't HTTP content makes the whole monitoring crap easier?

Not really. HTTPS remains encrypted where servers reject a downgrade, but an intruder can potentially force a downgrade in something misconfigured and snoop something important without having the root key.

> not carbon friendly

I suspect that switching off some of the endless lights in offices when sunlight more than suffices would have a seriously larger energy-saving impact.

> I haven't seen a BYOD setup that would allow whatever you please on the corp network.

You are right, there are rules, like the custom TLD is for authorized LAN users only. A public resolvable address is risky be cause the domain has a traceable ownership and identity, it relies on unnecessary external authorities.

For the migration I am considering deploy a company wide cert. But also I am frustrated because browsers shouldn't dictate the kind of Intranet structure we use.

If we still believe the Web should remain open, let the browsers behave more neutral.

Most (if not all) companies that push a system wide root certificate do not allow you to BYOD for the same reason they install that root certificate.

> companies that push a system wide root certificate

I wish those companies good luck, and I wish an open Web moves away from those companies as far as possible. If browser vendors wants to kiss corporate ass then I vote by uninstall them.