I recently saw this announcement from Mozilla:
https://blog.mozilla.org/security/2020/11/17/firefox-83-introduces-https-only-mode/
From TFA:
When you enable HTTPS-Only Mode:
Firefox attempts to establish fully secure connections to every
website, and Firefox asks for your permission before connecting to
a website that doesn't support secure connections.
To me this is mostly reasonable. It's reasonable for two reasons:
1. It has to be enabled. I see benefits in this being manageable via group policy or similar
2. It warns (but doesn't stop) you that content doesn't support HTTPS connections
Just because a connection is over HTTPS doesn't mean it's secure. Just because a connection is over HTTP doesn't mean it's insecure. The wording implies HTTP connections are insecure, but I understand that there's only so much space for a warning pop-up.
The part of Mozilla's piece that caught my interest was this:
The future of the web is HTTPS-Only
Once HTTPS becomes even more widely supported by websites than it is
today, we expect it will be possible for web browsers to deprecate
HTTP connections and require HTTPS for all websites. In summary,
HTTPS-Only Mode is the future of web browsing!
I posted a toot on Mastodon:
https://mastodon.social/@stevelord/105230641520893790
A few people didn't quite understand why Mozilla's desire to end HTTP support is wrong. So here's an explanation of why Mozilla's desire to remove HTTP support is a bad move and we should oppose rather than celebrate it.
There's been a strong push towards HTTPS over the past few years. It has it's trade-offs. On the one hand the push for HTTPS helps encrypt connections where encryption would be preferential. On the other hand Google penalizing HTTP only sites in search results is somewhat problematic when it comes to information better served over HTTP - e.g. for systems that don't generally support current HTTPS.
It also introduces a moving target for websites to be indexed and accessible.
HTTP is always HTTP. HTTPS will one day be an as-yet unreleased version of TLS over QUIC, and woe betide anyone who hasn't upgraded to whatever Google tells you is acceptable HTTPS.
And it will be Google telling you what's acceptable, not anyone else.
They own the search visibility and they own the web browser most people use. This is already happening. It was them driving HTTPS in the first place.
In the case of upgrading traffic to HTTPS this is good for most users in most situations. There are scenarios in which this is not good - e.g. where the HTTP and HTTPS sites don't match and a HSTS file stops HTTP from working, but thankfully such edge cases should be extremely rare.
We should acknowledge making the change introduces previously non-existent breaking edge cases. At the same time the trade-off is an overall net positive for situations where the connection could otherwise be insecure.
Before this push, HTTP was commonplace. Even when this push to HTTPS started there was a lag before HTTPS links became commonplace. Older articles on news sites like the BBC or Guardian will still link to HTTP URLs, that are then redirected to HTTPS by the destination server before being served. Removing support for HTTP breaks these links.
There are two ways that this can be resolved:
1. On encountering a HTTP link, use HTTPS first and fallback to HTTP with a warning if HTTPS is unavailable
2. Stop parsing HTTP at all and tell people to change their links to HTTPS
Mozilla are rolling out Option 1 with an opt-in. I'm sure over time, Firefox will try to make this opt-out.
Option 2 just isn't practical. That doesn't mean it won't be tried. It just won't succeed in a way that gets a user clicking on a link to the content they requested. At this point, the browser is working *against the user's direct request*. So I'm just going to say this once:
If you're going to go against the direct will of the user you're travelling in the wrong direction.
Mozilla might consider it a success if they never re-enable HTTP, but people will just use a different browser to access HTTP content.
There is an idea that somehow TLS is the only way to encrypt things and that TLS == Secure and everything else is not.
In reality things are more complicated. This is how DoH came to be championed by browser and web devs with a facile understanding of local networking, and villified by network protocol designers like Paul Vixie.
The reality is that security is riddled with trade-offs that need to be considered within a greater than binary secure-or-not context.
I don't run HTTPS exclusively on my home network. Why? Because my home network is sufficiently secured against MITM threats for my own threat model. If I need encrypted access to a service at home I can tunnel over SSH. TLS only adds overhead where a bearer network is already appropriately encrypted.
But what if someone breaks into your wifi network?
Then I have bigger problems than TLS, but I'll know when a new device joins my network. If they work harder to get in without me picking it up I'll know I have serious problems TLS will not address.
Where HTTP is insecure is when something messes with you between you and the target site. In the US, some ISPs routinely mess with customer networks. I resolved this problem by using an ISP that doesn't mess with my network. I appreciate that not everyone has that luxury. In places where I don't have control over possible ISP interference I use VPNs. I have my own VPNs for exit locations not covered by my Mullvad subscription.
I accept different people have different setups with different threat models, I'm just writing about mine here.
So when we say HTTP is insecure it's important to say against what. The most common thing injected into HTTP traffic in my experience of attacking wifi hotspots are login pages and ads. Sometimes these ads serve malware, which brings me on to my next point.
If you read and trust what Mozilla, Google and summer children may tell you, you might think HTTPS is secure and HTTP isn't, end of. Forgive me for saying this is naive and that years of security research has shown HTTPS security to be shall we say... complex?
TLS relies upon what's called a Web of Trust. This is a collection of certificates that are considered trusted by your browser. Most blindly accept all of these certificates. If you review those certificates you'll see that many of these certificate authorities operate in spaces you'll never visit. You don't know these people. You don't know under what circumstances they might screw you over.
You might look at the China Financial Certification Authority and think they're not the kind of organisation you want to allow to issue certificates that could be used to man-in-the-middle you.
But then you'd miss Digicert, who bought Symantec after they abused certificate issuing so much that Google threatened to remove them from Chrome if they didn't change their ways.
It's fair to say that an abused certificate by one issuer doesn't weaken HTTPS as a whole. But its perfectly possible to misconfigure HTTPS in ways that make interception or other attacks possible. Cipher and downgrade settings can leave sites and browsers wide open. TLS is an incredibly complicated protocol with complex parsers in complex libraries open to complex memory corruption and configuration bugs.
Historically you would go to a website, make a request to the website, get some HTML and then send separate requests to the same site for some graphics and maybe a Midi file.
Nowadays you make a request to the website and are redirected to the nearest Content Delivery Network (CDN) server. Your browser starts downloading HTML and is redirected to other servers for stylesheets, javascript, images.
The content you download often has some user-generated content on the page. Thinking about what is possible, if the objective is to steal or modify content, an attacker can target:
That is a *lot* to secure. I'm not saying HTTPS should be avoided. What I'm saying here is that HTTPS is one part of a much broader information assurance requirement. It is a tool in the box. It is not the box.
There are two common approaches to managing insecurity I'd like to highlight.
I'll refer to these as the Microsoft approach and the OpenBSD approach:
1. The Microsoft Approach: Mitigating exploit classes through increased complexity is a net good as it increases exploitation effort and cost
2. The OpenBSD Approach: Complexity increases attack surface.
There's a computing aphorism I feel is relevant here, Greenspun's Tenth Law:
Any sufficiently complicated C or Fortran program contains an ad hoc, > informally-specified, bug-ridden, slow implementation of half of > Common Lisp.
If you switch off browser scripting and use HTTP, an attacker's exploitable (for values of remote code execution) surface area drops through the floor compared to the same request over HTTPS with browser scripting enabled.
Gwern as usual has fascinating comments on accidentally Turing Complete systems:
https://www.gwern.net/Turing-complete
But short of a vulnerability in file formats or HTML parsing, with scripting turned off the impact of MITM changes substantially. The web was designed to display markup, not execute code. Now people who make a lot of money from executing code want to tell you what the web should and shouldn't do.
Security is a complicated and highly nuanced field and every decision we make has a security tradeoff. It's easy to get distracted and convince ourselves that we're doing good when we're doing harm. We can shout down legitimate concerns over the consequences of our actions in the name of security and progress theatre.
We could put effort into securing scripting languages and web extensions but instead are focusing on the crypto as a way to avoid tackling it.
As the web browser has slowly gained the ability to rewrite the OS in its own image, that *half of Common Lisp* is growing into a quarter of Smalltalk. Nobody asked for it, but Google won. Mozilla exists solely so Google can claim it doesn't have a browser monopoly, nothing more.
Cutting out HTTP means cutting out the web. The day that happens is the day I cut out Mozilla.
Drew DeVault wrote some thoughts I share on the web here:
https://drewdevault.com/2020/08/13/Web-browsers-need-to-stop.html
Drew's gemini presence is down right now, but when back up I think his piece will be here:
gemini://drewdevault.com/2020/08/13/Web-browsers-need-to-stop.gmi