HTTPS Everywhere to Be Deprecated | Hacker News Reader

HTTPS Everywhere to Be Deprecated

eff.org

57 pointsluke2m25 comments

One thing I have recently tried out is to prevent all outbound traffic headed towards a port 80. This doesn't necessarily block all HTTP traffic but it blocks any standard http setup.

My expectation was that this would break a lot of the web and a lot of peripheral desktop applications, which I thought would phone home via port 80 to ask for updates and so on. In fact, almost nothing broke at all! So I've kept that turned on. Can recommend doing this if anyone wants peace of mind.

It's very easy to set up with the Windows firewall. Not so sure about other firewalls. (Note the difference between "block outbound traffic on port 80" and "block all traffic destined to port 80 on the remote machine" - I did the latter)

I find it astounding you found nothing broken at all completely blocking port 80 when simply setting "always switch" HTTP->HTTPS instead of "when likely supported" has resulted in me noticing daily breakages of misconfigured sites including those linked from HN and that's a step up from simply blocking it.

Outside the browser a quick Wireshark capture show even common apps you'd think are HTTPS only like Steam are using HTTP for functionality such as IPv6 connectivity checks and such.

Nothing visibly broke - in particular, Steam seems to chug along just fine in the absence of its own checks.

Does this mean we can finally go back to HTTP for connections that don't NEED to be secure without being attacked for it by security Nazis?

Seriously, though, the far bigger problem is the need for better handling of certificates (often permanent) for embedded servers such as IoT devices. Cert management is still a huge and pretty much unfixable problem for real world deployments once you get outside the realm of propellerheads like us, and recognize that in the real world, "servers" often lack not just professional, competent administrators (which are required even by all current HTTPS solutions), but administrators, period.

Or, you know, just don't use the optional browser extension?

These are two different topics. If you have ever dealt with back-end certificates you may better recognize the perspective to which you are responding.

The original post that I replied to only contained the first line regarding 'security Nazis'.

The remainder was edited in after my comment. So, it was impossible for me to recognize the parent posters perspective. Thanks though.

We've been over this. It's not about the content of HTTP websites. It's the fact that every HTTP connection is a network-level vulnerability.

It's like building a fortified castle and leaving a side door wide open for the maid. It's just a maid! Why does she need to have a bolted gate!?

What is a "network-level vulnerability"?

I’ll provided an example: When the great firewall rewrites http reqs to inject malicious JavaScript to take down GitHub.

See “great cannon incident”. Http is a network level vuln, it allows clients to be hijacked by a mitm. It is totally unacceptable.

Cisco osi model levels/layers 1 to 7: physical, data link, network, transport, session, presentation, application.

Port numbering is a transport layer feature, so it's technically a transport level / layer 4 vulnerability, not network.

It's trivial to do public certs with acme.sh, caddy, or certbot so you might as well. For most private networks I think it's fine to use plain HTTP.

I think HTTPS has been oversold. We've had a very myopic focus on men in the middle, which, for sure are a problem, but they aren't the only problem, the first problem, or the last problem in digital security.

HTTPS helps against some attack vectors, but makes you incredibly vulnerable to others. It essentially forces you to blindly trust your software, since you can no longer inspect what is entering and leaving your network. Especially as it's becoming ever more common that our software dials home with opaque "telemetry" that for all we know could contain anything.

HTTPS protects you against the neighbor's 17 year old son with his pringles cantenna and laptop full of scripts, but makes you much more vulnerable from large scale attacks, which become much more viable for those who have the capital to back them.

It's pretty dang weird that EFF has been leading this charge, especially in the wake of Snowden.

So, to summarize:

- We shouldn't have focused on using secure http because it makes you more vulnerable to large scale attacks, such as state-sponsored attacks

- We should have left traffic unencrypted so that "We can inspect what is entering and leaving my network", especially because devices are now sending more telemetry

The first is utter nonsense. You are not more vulnerable to sophisticated actors, we've just upped the stakes so that only very sophisticated and motivated actors can read your traffic. Unencrypted, anyone could. This is an improvement.

The second is utter nonsense. Not pushing for HTTPS everywhere doesn't mean all communications are now plain text and inspect-able.

We are absolutely more vulnerable to sophisticated attackers. A government could simply order say a browser manufacturer to gather data, slap a gag order on the company and threaten them with sanctions if they speak and nobody would be the wiser. Or plant an engineer that does it. Anything can be a target of this type of attack. OS kernel, graphics drivers, a beloved purple desktop gorilla, a docker image, a popular library. The entire supply chain is exposed. Why are you connecting to that server, we ask. It's just telemetry. Or a crash report with a core dump. Or checking for updates. This only works if we are forced to blindly trust the traffic leaving our computers. And we are, helplessly so.

The second absolutely helps. If the norm is to only encrypt secret data, encrypted data spontaneously leaving your computer is a major red flag.

On your network/device, you may decrypt connections if you'd like.

As far as the government forcing browsers to connect information, they can do that even if the browser defaults to HTTP.

You can only decrypt connections if you have the key.

If the browser sends details over plain HTTP, it is very easy to inspect. You know, by putting yourself as a man in the middle. If , in that scenario, the browser spontaneously starts sending encrypted data, you should have many questions.

That the link is HTTP in no way prevents all or part of the payload from being indecipherable to an entities attempts at inspection.

> Not pushing for HTTPS everywhere doesn't mean all communications are now plain text and inspect-able.

The vast, vast majority of communications actually are - or are at least possible to reverse-engeneer with some effort. However, the inverse is true: Pushing for HTTPS means that no communication is inspectable because this is the whole idea behind HTTPS.

And yes, I don't want my ISP or my government or the cafe down the street inspecting my packets either, but I'd like someone not affiliated with the developers of the software I'm using be able to do so - because otherwise, the encryption is protecting the developers and their business, not me.

Then instrument the endpoints. Surely a developer has code level access and can inject a debugger, logs session keys for later decryption, or intercept the crypto api calls to inspect preencrypted values.

Https does nothing to prevent, help nor hinder the visibility to the developer. It merely provides confidentiality of communications between two endpoints, which is a highly desirable property in secure systems.

If you control the device and binaries then you will always be one step above everyone else. If someone was dumb enough to use HTTP and just switched to HTTPS, I'm 99.9999% sure they won't check what certificate is being used and you can just use something like Telerik Fiddler to do HTTPS MITM with a custom generated root CA, you'll be surprised how easy it is to get those installed even in phones.

It is why software needs support to (optionally, if configured by the user) do such things as non-tunneling proxies for HTTPS. (There are other problems too, which can be solved by other changes to the software. Not all of them have to do with HTTPS, though.)

Neither HTTPS or other protocols prevent whatever service you are using from using it badly, or from malware in the client or server side. Just because it is HTTPS does not necessarily mean that it is desirable.

I currently do not have any TLS server in my computer, although I intend that I may later add it as an option (but without redirecting; if it is implemented, both the TLS and non-TLS will remain available). However, some of my projects are mirrored on the Chisel fossil hosting which allows both TLS and non-TLS to connect.

(And, in the case of obscured data, even if the protocol isn't encrypted the program might make its own encryption, and disabling TLS (even if you have the opportunity to do so) won't help.)

You can inspect or easily get the decryption keys traffic on devices you control such as your PC or your Web Browser. If you control the OS but not the applications you choose to run set up an explicit proxy and inspect there. On devices you don't control the OS or applications of (of which includes other people's devices anyways) the choice of HTTP or HTTPS doesn't change anything as the device/application always has the ability to make payloads opaque they just won't be authenticated at the protocol layer in the case of HTTP. Not using HTTPS for the traffic you do control does not impact traffic you don't control it just leaks more information about you and opens more attack vectors.

The most common cases of MitM are actually service providers, both with HTTP and DNS, typically to serve ads or sell telemetry. Individually targeted attacks are important but lower on the list in terms of real world impact at the moment.

Outside of the falsehood that you need HTTPS to conceal exfiltration of information for apps you don't control how is HTTPS enabling you to become incredibly vulnerable to other attack vectors?

This is true, however the current push to enforce HTTPS everywhere normalizes encrypted traffic. If encrypted or obfuscated connections were rare, you could make a filter that only lets through inspectable connections and deploy it without much breakage. If all connections are encrypted, you cannot distinguish between safe and suspicious traffic at all.

Together with eSNI, DoH and QUIC, the goal is pretty explicitly to treat the network as an adversary. That's a good thing if you really don't trust the network but a bad thing if you lose control over your own network.

Again, you can inspect or easily get the decryption keys traffic on devices you control such as your PC or your Web Browser. If you control the OS but not the applications you choose to run set up an explicit proxy and inspect there. If the app doesn't follow explicit system proxies add your transparent proxy key to the root store. If the app ignores that then congratulations, you're at "you could make a filter that only lets through inspectable connections and deploy it without much breakage" without getting rid of the benefits of Encryption to do so.

Encryption is not what makes the app communication opaque, inability to control the device does. The external network IS an adversary when it comes to your data. If you truly controlled your data at the start then you can specify where the external network begins. By default that is when it leaves your PC but it does not always have to be that point.

Reply on news.ycombinator.com