Live data from Hacker News

Firefox 83 introduces HTTPS-Only Mode

blog.mozilla.org

311–320 of 525 posts

Re: Firefox 83 introduces HTTPS-Only Mode

#311
post #183
post #170

Earlier quoted context omitted.

If only the OS could terminate TLS and allow to filter decrypted traffic locally.

This is prevented by certificate pinning.

Only on a handful of domains. Most site admins are fearful of HPKP. The mitm proxy I am using to post this message only has to exclude a small handful of domains from mitm decrypting. A bunch of google domains, eff.org, paypal, a few mozilla domain names, dropbox and android. To my surprise, no traditional banks, no money management or stock trading sites, no "secure" portals used by law firms to share sensitive files. The sites I would expect to use pinning are the ones that do not.

On a side note, I would love to see a system that adds out-of-band validation of an entity. e.g. My bank should have a QR code behind glass on the wall that I can scan, import a key and further validate their site at the application layer, above and beyond HTTPS and CA certs.

Re: Firefox 83 introduces HTTPS-Only Mode

#313
post #188

Earlier quoted context omitted.

The main problem with keeping sites http is that someone in the middle can modify the content and inject arbitrary code, be it ads, crypto mining or just a redirect to a worse website. Therefore I believe it should be a social duty to make everything https so as to ensure that we don’t create something that can be used to harm others. I didn’t use to think like this until I actually tried it out by going to a mall an…

> The main problem with keeping sites http is that someone in the middle can modify the content and inject arbitrary code I keep hearing this as a plausible excuse, yet I've never seen any proof of such. non-https does make it possible but has anyone got any source where someone has been victim of such attacks?

A cursory search returns many examples, for instance : https://www.privateinternetaccess.com/blog/comcast-still-use...

Re: Firefox 83 introduces HTTPS-Only Mode

#314
post #306
post #263

Earlier quoted context omitted.

I think if the user wants that, they should choose to apply it. Not the network operator. Same as how I wouldn't want my network operator inspecting my HTTPS traffic for malware.

I'm the user and the network operator. Can you give me a comprehensive list of places I need to configure, and notify me when another place software can go around my configuration is added?

I never said there wouldn't be an increased configuration burden for that kind of setup. There was also an increased configuration burden when we moved to widespread HTTPS, but the benefits outweighed the costs.

Re: Firefox 83 introduces HTTPS-Only Mode

#315
post #188

Earlier quoted context omitted.

The main problem with keeping sites http is that someone in the middle can modify the content and inject arbitrary code, be it ads, crypto mining or just a redirect to a worse website. Therefore I believe it should be a social duty to make everything https so as to ensure that we don’t create something that can be used to harm others. I didn’t use to think like this until I actually tried it out by going to a mall an…

Therefore I believe it should be a social duty to make everything https so as to ensure that we don’t create something that can be used to harm others. Those who give up freedom for security deserve neither.

What freedom do I give up by adding HTTPS to my website?

Re: Firefox 83 introduces HTTPS-Only Mode

#316
post #202

Earlier quoted context omitted.

So between the user and the network operator, who should have the final say? It seems like you're saying, "it should be the user when I'm the user and it should be the network operator when I'm the network operator". But I don't think we can have it both ways.

Generally the policy should be 1) The ISP says what should be used 2) the lan either accepts that, or the operator puts their own values 3) the device either accepts that, or the operator puts their own values Same as object inheritence. An ISP says "use this DNS server it's nearer", the network operator says "no thanks, I'll run my own with an upstream of google as I don't like your NXDOMAIN injects", the user says…

I think there will be some contention over 1 and 2 because we're at the point where both of these entities might be trusted (at home and work) but are inherently untrustworthy.

And so browsers are saying that the path should be.

1) The browser developers say what should be used.

2) The user either accepts that or puts their own values.

Ideally I think it should actually be something like

1) The OS vendor say what should be used.

2) The user either accepts that or puts their own values.

2.1) Lan operators can offer DNS servers which the user can (always) accept or (always) reject with reject being the default.

But this whole mess with browser DoH is because OS vendors are slow to move on this. Google Android does it kinda, Windows has it in beta, Linux works but it's a little DIY.

Re: Firefox 83 introduces HTTPS-Only Mode

#317
post #208

Earlier quoted context omitted.

Isn't this SSL offloading and done by companies to introspect the traffic?

That only works as long as the CA trusted by the user's computer is controlled by the box trying to do this.

Which shouldn't be a problem since it's the box itself doing the decryption. No need to MiTM since it's the endpoint.

Re: Firefox 83 introduces HTTPS-Only Mode

#318
post #310
post #199

Earlier quoted context omitted.

Right. It is ridiculous to say that DoH enables malware because it has always been trivial to bypass DNS-based access control with or without technologies like DoH. In fact, if anything, using DoH would be a particularly cumbersome way of doing it when there are many simpler solutions. Like for example, just putting an IP in a text file on a REST endpoint.

I think the best case I can make is that it's not about the ability to tunnel DNS, it's that there's now many fast highly-available public DoH resolvers that bypass DNS filtering for free. A hypothetical malware author just needs to use any of them rather than set up their own tunnel.

True, this aspect of the situation could make malware use cases a bit simpler to operate/maintain.

Re: Firefox 83 introduces HTTPS-Only Mode

#319

Earlier quoted context omitted.

Honest question. How is this feature enabling increased corporate/government control?

Because now almost every Firefox user will be sending their DNS straight to one centralized provider, a large corporation, which makes them more vulnerable to various kinds of government interference.

There is nothing about DNS over HTTPS that requires you to use one centralized provider, and unencrypted DNS has always been easier for large corporations, ISPs, and the government to sniff.

I think people are just totally off-base on this. The instances of government/corporation reactions to DOH that we have seen suggest that untrustworthy organizations and governments largely oppose the change. They would not oppose the change if it was in their best interest.

Worth noting that anyone can set up a DOH server. You can even set up your own server in your own house and use it the same way that you would a Pi-hole. To the extent that malware providers or IoT providers will use this to circumvent blocks, they already had the ability to do that -- and IoT services like Chromecasts have already experimented in the past with setting their own DNS providers and ignoring network settings.

We do not need to open up our networks to MiTM attacks to avoid centralization. Unencrypted DNS is a bad idea, it isn't complicated.

Re: Firefox 83 introduces HTTPS-Only Mode

#320
post #263
post #261

Earlier quoted context omitted.

The issue is with Firefox overriding the system DNS with its own by default, when the system DNS may have content blocking applied and the Firefox default may not.

I think if the user wants that, they should choose to apply it. Not the network operator. Same as how I wouldn't want my network operator inspecting my HTTPS traffic for malware.

I'm not sure why HN won't allow me to reply to ori_b's question below you, however DoH in Firefox (and in Chrome) have clearly spelled out ways to disable it at the network level for those folks who are network operators and want to restrict it due to interference in filtering or split-horizon DNS.

https://support.mozilla.org/en-US/kb/configuring-networks-di...

Someone previously mentioned Pi-Hole. Pi-Hole provides the DoH canary domain in it's default configuration, therefore if you run an up to date Pi-Hole on your network you will have DoH disabled. It is recommended (and there are good instructions on the Pi-Hole website) to set up cloudflared or a similar DNS resolver which implements DoH as the backend to Pi-Hole, allowing it to use DoH when leaving your network but still act as the local network's authoritative name server.

If you choose to be a network operator, there are some additional complexities you must think about. For those (majority of) users that choose not to be network operators, DoH is nearly transparent for them and provides significantly improved security and privacy by preventing local cache poisoning, DNS injection, and DNS snooping attacks on their browsing.

Additionally, while the default in Firefox is a non-filtering endpoint currently, you can manually configure the use of a filtering DoH endpoint like those provided by CloudFlare 1.1.1.1 for Families if you wanted to do so. Nothing prevents this, and it can be configured via policies network-wide in Firefox using the enterprise policy mechanisms.

Post reply on HN