Firefox 83 introduces HTTPS-Only Mode • Hacker News Board

Re: Firefox 83 introduces HTTPS-Only Mode

#341

Post by bullen » Tue, Nov 17, 2020, 4:16 PM UTC

MayeulC wrote: post #266

bullen wrote: post #227

Earlier quoted context omitted.

Not OP but: HTTPS is not secure because it is centralized and it does not protect against MITM. HTTP is the foundation of our civilization, it will never go away how much certificate sellers try. But I would go one step further and point out that HTTP can be made secure manually selectively so that you only secure the things that need security! HTTPS wastes energy by encrypting cat pictures, and we don't have that mu…

To me, HTTP is the wrong target. It would be much more interesting to replace IP, like Yggdrasil does (and I think gnunet, cjdns, hyperboria & others). If you IP is a cryptographic identifier: * It cannot be forged * Anyone can generate a new one on-demand * Every packet is authenticated, every packet can be encrypted * TLS becomes redundant However, the DNS part remains a hard one. How to securely link to websites y…

IP is even harder to replace, it is completely fossilized by this point and that is a feature. The challenge is not to replace the pipes but to build something meaningful using the pipes we have without too much added complexity:

I built a realtime MMO stack using only HTTP/1.1 for network.

Re: Firefox 83 introduces HTTPS-Only Mode

#342

Post by tyingq » Tue, Nov 17, 2020, 4:16 PM UTC

I do worry about the sort of monoculture with Let's Encrypt. A second and third provider that do the same thing would reduce the blast radius for potential outages. Grateful for LE, but there's a lot riding on it. Similar for Cloudflare.

Re: Firefox 83 introduces HTTPS-Only Mode

#343

Post by shadowgovt » Tue, Nov 17, 2020, 4:16 PM UTC

palominoz wrote: post #144

I hope they aren't going to force users in https-only in the future. Software shouldn't cut off legacy content (old websites that aren't going to be upgraded with https) something just because in theory it is more secure. If someone is surfing the web as an adult he is responsible of himself. Other than this there are historical components (web firewalls) that aren't going to work anymore .. so security is a matter w…

Because browsers run code, they exist in that tricky space where some design decisions have to be made for the good of the commons.

If you visit an HTTP site and get MITM'd, it's not just that the attacker can put you at risk by spoofing a credential input box; it's that the attacker can put third parties at risk by having your browser XMLHttpRequest as fast as it can at at someone else's site to try and DDOS them.

At that point, the calculus shifts and we see a world where user-agent engineers have to make decisions like Microsoft did (to start forcing people to install security patches to the most popular OS on the planet, because we have enough evidence from human behavior to know that at some point, forcing-via-inconvenience becomes necessary).

HTTP is fundamentally broken in that it can be abused to damage the network itself, and even though it's a deeply entrenched protocol, it's one that people have to be backing towards the exits on for that reason.

Re: Firefox 83 introduces HTTPS-Only Mode

#344

Post by bullen » Tue, Nov 17, 2020, 4:17 PM UTC

josephcsible wrote: post #280

bullen wrote: post #246

Earlier quoted context omitted.

Only routing owners can modify the cat picture, do you think they can afford to when the browser does not "run" the cat picture?

Image decoders occasionally have RCE vulnerabilities.

I think the solution in this case is to not execute code in pictures rather than removing HTTP?

Also I'm starting to suspect the downvoting feature is used a sadistic tool, just keeping karma up so you can punish people.

Re: Firefox 83 introduces HTTPS-Only Mode

#345

Post by shawnz » Tue, Nov 17, 2020, 4:20 PM UTC

zrm wrote: post #327

tristor wrote: post #320

Earlier quoted context omitted.

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 t…

> 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. I still don't really understand this. Yes, it solves that problem, but how is it not also defeating the entire premise? If you had a DNS server from an adversarial network operator, they could just res…

The user can choose to ignore the canary in the app's settings (not the default though), or they could ignore it at an OS level. And it is indeed intended to be removed and replaced with a different mechanism eventually

Re: Firefox 83 introduces HTTPS-Only Mode

#346

Post by iso1631 » Tue, Nov 17, 2020, 4:23 PM UTC

josephcsible wrote: post #301

iso1631 wrote: post #87

Earlier quoted context omitted.

I want my OS to do DNS - including DOH, not my browser. I want a single source for my DNS I want my network to tell me a DNS server to use. As I own my computer I can override that, but much of the time I want to use the network provided DNS server.

What you want would make censorship and surveillance easier against the vast majority of people. Networks I'm on shouldn't be able to tell which CloudFlare-hosted site I'm visiting, or to block some of them without blocking them all. Letting the network give me a DNS resolver instead of using a known-good one would allow exactly those bad things.

So you are suggesting we further centralising the web to avoid censorship and surveilance?

Re: Firefox 83 introduces HTTPS-Only Mode

#347

Post by akerl_ » Tue, Nov 17, 2020, 4:24 PM UTC

zrm wrote: post #251

shawnz wrote: post #248

Earlier quoted context omitted.

Hardcoding the IP certainly has limitations but that is only the easiest example of bypassing DNS-based content blocking. A slightly less trivial solution where you grab the IP out of a file over HTTP instead could be easily implemented by any junior developer. > Also, if they use an IP address then they can't be using SNI to host it on the same IP address as several other domains Sure they can, just hardcode the "Ho…

> A slightly less trivial solution where you grab the IP out of a file over HTTP instead could be easily implemented by any junior developer. Over HTTP from what? You would need name resolution or a hard-coded IP address to make an HTTP request. And the thing this is preventing isn't just what the malware does after you're already infected, it's the path to receiving malware to begin with.

GitHub, PyPi, NPM, etc are all great options for hosting dynamic content from a fixed location which looks benign to scanning.

For non-tech companies, replace with any relatively popular wiki.

The goal is “make a connection over HTTPS or other normal-looking protocol, to a destination that is both justifiability relevant for normal user traffic and allows the attacker to seed the next-step”. And it turns out there are lots of sites that fit that bill.

Re: Firefox 83 introduces HTTPS-Only Mode

#348

Post by iso1631 » Tue, Nov 17, 2020, 4:29 PM UTC

ldjb wrote: post #264

iso1631 wrote: post #230

Earlier quoted context omitted.

If I specify http://whatever.com in the address bar, or if I follow a link to http://whatever.com , I'd expect it to attempt to connect to port 80 on whatever.com, and not redirect to https unless the page responds with a Location header If I type "whatever.com", I'm happy with it to try port 443 first I'm not sure if a http/80 page should be at least HEADed to see if there's a redirect to https/443 before throwing u…

I can understand your use case, but I know a lot of people (often those who use computers infrequently) type out the full URL all the time. They don't know what HTTP or HTTPS is, they don't realise you can omit that part. They just want to access the website. For those people, it makes sense that typing " http:// " would take them to the " https:// " site if available. Although they did specify HTTP, it isn't necessa…

Most people type the address into google.

If the server says that the thing on port 80 is better served from port 443, then it can issue a 302 permanently move (and a HSTS header to make it stick). If the server offers different content on port 80 and port 443 then the server can do so just fine.

The browser should not try to second guess my explicit instructions.

Re: Firefox 83 introduces HTTPS-Only Mode

#349

Post by makecheck » Tue, Nov 17, 2020, 4:30 PM UTC

Upon launch, Firefox 83 displays essentially a full-page ad for Pocket, with a tiny link at the bottom (have to scroll to it) to get the release notes for “what else” is new in Firefox.

So all kinds of significant enhancements in 83, including HTTPS mode, might essentially be missed by most users. (Heck, I only knew because of this HN post.)

Why do programs insist on “hijacking” things? Release notes seem particularly vulnerable to this, e.g. iPhone apps love to have “notes” that don’t actually tell you anything at all, just marketing-speak.

Re: Firefox 83 introduces HTTPS-Only Mode

#350

Post by shawnz » Tue, Nov 17, 2020, 4:31 PM UTC

ori_b wrote: post #338

shawnz wrote: post #330

Earlier quoted context omitted.

As a user, what is the increased admin burden for using DoH, assuming you don't want to implement network level content blocking? Basically none. What is the burden for using HTTPS assuming you DO want to be able to inspect and block HTTPS resources at a network level? Very extensive compared to plain HTTP.

Make the libc resolver do DoH, and drop it from firefox,half the problems go away. The other half of the problems are around defaulting to allowing cloudflare to inspect your traffic, instead of comcast. And the lack of integrity and encryption for the rest of the DNS infrastructure. And the expansion of the complex and difficult to secure x509 certificate regime which we should be moving away from. (Something like g…

I agree with you there, OS vendors should be implementing DoH. Thankfully they are finally getting around to it after pressure from browsers.

Regarding the rest of the DNS infrastructure, I agree there is more work to be done. But I see DoH/DoT/etc as a necessary step and not a "half-assed implementation" that needs to be "fixed".