9 ms·
HTTPS Everywhere to Be Deprecated
- dublin 5y agoDoes 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.
- ziddoap 5y agoOr, you know, just don't use the optional browser extension?
- the_optimist 5y agoThese are two different topics. If you have ever dealt with back-end certificates you may better recognize the perspective to which you are responding.
- ziddoap 5y agoThe 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.
- pornel 5y agoWe'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!?
- xg15 5y agoWhat is a "network-level vulnerability"?
- randomhodler84 5y agoI’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.
- robbedpeter 5y agoCisco 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.
- alephu5 5y agoIt'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.
- johnday 5y agoOne 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)
- zamadatix 5y agoI 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.
- johnday 5y agoNothing visibly broke - in particular, Steam seems to chug along just fine in the absence of its own checks.
- marginalia_nu 5y agoI 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.
- jvanderbot 5y agoSo, 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.
- marginalia_nu 5y agoWe 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.