3 ms·
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 attack
by jvanderbot 5y ago
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.
- 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.
- BenjiWiebe 5y agoOn 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.
- marginalia_nu 5y agoYou 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.
- IIsi50MHz 5y agoThat the link is HTTP in no way prevents all or part of the payload from being indecipherable to an entities attempts at inspection.
- xg15 5y ago> 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.
- randomhodler84 5y agoThen 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.
- Hamcha 5y agoIf 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.