Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Plaintext HTTP in a Modern World

jcs.org

Post reply on HN
Print view View original

41–50 of 78 posts

Re: Plaintext HTTP in a Modern World

#41

Post by throwaway290 »

shaicoleman wrote: post #18
oneplane wrote: post #13

This page doesn't seem to grasp the reasons behind using encrypted connections. It's not some 'security' blanket statement or 'have something to hide', it's tamper-prevention (including MITM malware injection), privacy, and a little bit of identity verification (not really something people do in the real world). https://www.troyhunt.com/heres-why-your-static-website-needs... If your problem is some ancient device tha…

Visiting a single unencrypted website allows anyone who controls the connection (your government/ISP/WiFi provider) to cause your browser to silently execute malicious code and download malicious content. Compromising the security of 99.9% of users for the benefit of the 0.1% isn't even remotely worth it. Those 0.1% also have a simple workaround of using a proxy if needed.

> to cause your browser to silently execute malicious code and download malicious content

You are making assumptions about my user agent.

If you use insecure JS-executing browsers and problematic ISPs (I know not everyone has a choice), consider VPN or an extension that forces HTTPS.

Re: Plaintext HTTP in a Modern World

#42

Post by chrismorgan »

superkuh wrote: post #2

Everything in this article rings true. But there's more. HTTPS only, combined with almost everyone only using LetsEncrypt (a great service), leads to massive concentration of value for any internal corruption at LE or external political (or other) pressures on LE. The more browsers refuse to show HTTP, the more people in LE, the greater prize it is for those that want to control what is seen. If you want the web to b…

Yes, there is a certain measure of trust going into parties like Let’s Encrypt, but I don’t think it’s as bad as you are saying.

• A CA can’t intercept anything based on your using them.

• A CA can refuse to issue a certificate for your site, but if this got out (which it would), it would significantly damage their reputation and I don’t think it will ever make sense for them to unless legally compelled. In that case, there are other providers, unless legal compulsion has removed them too, in which case the world wide web is dead anyway, so this is not worth worrying about.

• A CA can issue a false certificate for your site. There is, however, a non-trivial risk of them being detected in doing this (much smaller for small sites, but the system is set up in such a way that almost anyone can check and detect most instances, and I think you can be reasonably sure Let’s Encrypt specifically is being monitored for suspicious patterns by multiple parties that have vested interests in the system running smoothly), and if it did get detected, they would certainly be subjected to extreme scrutiny, so that any more instances would be very likely to be detected, and if a good explanation was not provided in short order (and even then it wouldn’t be too easy to recover), they would be dead, though it would certainly be a period of great pain for the web. In other words, not only does the potential upside of cheating go up, but also the downside.

I don’t think your conclusion that you should support HTTP is reasonable.

Re: Plaintext HTTP in a Modern World

#43

Post by dividuum »

jka wrote: post #24
oneplane wrote: post #13

This page doesn't seem to grasp the reasons behind using encrypted connections. It's not some 'security' blanket statement or 'have something to hide', it's tamper-prevention (including MITM malware injection), privacy, and a little bit of identity verification (not really something people do in the real world). https://www.troyhunt.com/heres-why-your-static-website-needs... If your problem is some ancient device tha…

It's generally not a model that has much supportive mindshare for the web currently, but it is possible to achieve tamper-prevention without requiring the content of communications to be encrypted. For example, most official Debian[1] and Ubuntu[2] package repositories currently use HTTP (not HTTPS) by default for content retrieval. That's reliable thanks to public-key encryption; the packages are signed, and the rec…

Adding to that: just slapping HTTPS on those connections still would prevent an observer from detecting you downloading cowsay. IIRC every package has a fairly unique size and unless you add padding that is enough metadata to figure out with reasonable certainty which package you requested. So it’s not like HTTPS would add any immediate benefit anyway.

Re: Plaintext HTTP in a Modern World

#44

Post by LunaSea »

marginalia_nu wrote: post #35
LunaSea wrote: post #28

Earlier quoted context omitted.

Browser's can't verify the integrity of website contents.

HTTPS can't verify that either, to be quite honest. It can ensure modest protection against a specific class of MITM attacks. If the traffic goes through a CDN like cloudflares it's decrypted, inspected, possibly manipulated and re-encrypted mid-flight. A well funded actor can also lean on the website owner, or just hack them.

TLS protects completely against network based MitM attacks.

CDNs are purposefully installed in MitM positions. That's a risk that the sites owner has to manage and it's an optional one at that.

A well funded actor would probably use different kind of vectors and not even bother with website MitM.

Re: Plaintext HTTP in a Modern World

#45

Post by 13security »

shakna wrote: post #12
jbotdev wrote: post #6

Not sure I understand the concern about access from “modern embedded devices”. Something like a Raspberry Pi, or really anything with a decent ARM processor, can easily handle TLS.

TLS can be handled by much, much small devices, too! Most of the cheap Xtensa line of things, like the ESP can handle decoding TLS [0]. [0] https://docs.espressif.com/projects/esp-idf/en/latest/esp32/...

The problem is in supplying the CA certificate(s) used to verify the web-of-trust. Web browsers are pre-loaded with a huge number of trusted CA certificates. Pre-loading and maintaining that list on an embedded microcontroller is non-trivial. Not to mention what happens when a CA root is compromised or goes rogue, you have to deal with the revocation process.

Your link mentions global_ca_store but provides no guidance on how to effectively populate it. That's the problem.

Interestingly, providing a non-Tivo-ized system, e.g. one that allows connection to an arbitrary cloud server, requires even more work than just hardcoding in "your" CA certificates.

None of this is insurmountable, but it leaves devs pining for a pre-HTTPS world where you can just do a DNS lookup and send "GET / HTTP/1.0" and not have to worry about all the attack vectors that HTTPS protects against, as well as the ones that HTTPS opens you up to.

Re: Plaintext HTTP in a Modern World

#46

Post by shaicoleman »

marginalia_nu wrote: post #37
shaicoleman wrote: post #34

Earlier quoted context omitted.

JavaScript code can be malicious, even while sandboxed (e.g. downloading a file). There are still dozens of browser security issues found and fixed every month. A simple HTTP redirect to download a PDF file can also lead compromising the user's computer.

How does HTTPS protect from any of that? PDFs can still compromise your computer, and JS is still sketchy. Anyone can encrypt their server, even the bad guys.

That only happens if you directly visit a malicious site, e.g. https://secure.mybaaankingsite.com

You can protect yourself by going directly to the URL and checking you're on the right domain.

If you don't enforce HTTPS everywhere, any website is potentially malicious, e.g. visiting http://cookierecipes.com can have the same consequences.

Re: Plaintext HTTP in a Modern World

#47

Post by marginalia_nu »

LunaSea wrote: post #44
marginalia_nu wrote: post #35

Earlier quoted context omitted.

HTTPS can't verify that either, to be quite honest. It can ensure modest protection against a specific class of MITM attacks. If the traffic goes through a CDN like cloudflares it's decrypted, inspected, possibly manipulated and re-encrypted mid-flight. A well funded actor can also lean on the website owner, or just hack them.

TLS protects completely against network based MitM attacks. CDNs are purposefully installed in MitM positions. That's a risk that the sites owner has to manage and it's an optional one at that. A well funded actor would probably use different kind of vectors and not even bother with website MitM.

So why does catmemes.lol need to be encrypted with such urgency?

Re: Plaintext HTTP in a Modern World

#48

Post by jagged-chisel »

aliraheem wrote: post #4
superkuh wrote: post #2

Everything in this article rings true. But there's more. HTTPS only, combined with almost everyone only using LetsEncrypt (a great service), leads to massive concentration of value for any internal corruption at LE or external political (or other) pressures on LE. The more browsers refuse to show HTTP, the more people in LE, the greater prize it is for those that want to control what is seen. If you want the web to b…

I may be wrong, but as I understand it HTTPS connections typically use an ephemeral key with the certificate used to authenticate the servers identity. So simply having the certificate does not mean one can read the traffic without conducting a man-in-the-middle attack. This means that anyone who could read traffic from a HTTPS connection could read it from a HTTP connection just as easy. The arguement seems to boil…

Just to be complete: it’s not that the key is ephemeral, it’s the way it’s agreed upon. The symmetric key is never in the communication stream.

Re: Plaintext HTTP in a Modern World

#49

Post by marginalia_nu »

shaicoleman wrote: post #46
marginalia_nu wrote: post #37

Earlier quoted context omitted.

How does HTTPS protect from any of that? PDFs can still compromise your computer, and JS is still sketchy. Anyone can encrypt their server, even the bad guys.

That only happens if you directly visit a malicious site, e.g. https://secure.mybaaankingsite.com You can protect yourself by going directly to the URL and checking you're on the right domain. If you don't enforce HTTPS everywhere, any website is potentially malicious, e.g. visiting http://cookierecipes.com can have the same consequences.

Right, but how do I know whether the URL pattern is legitimate? I don't work for the IT department at my bank. If the answer is to just eyeball it, that does seem like a far worse security problem than HTTP has ever been.

Re: Plaintext HTTP in a Modern World

#50

Post by couchand »

enriquto wrote: post #39
couchand wrote: post #32

Earlier quoted context omitted.

> Let's allow simple harmless things to stay around. On private networks only, please. Otherwise, they will not be harmless for long. > For static http pages with permanent content, encryption is not really necessary. Unless you actually care about receiving the true content. Which, if you intend to reach that site, you probably do. > now holds some power over your content. That's simply untrue. Complete FUD. > which…

> Unless you actually care about receiving the true content. Which, if you intend to reach that site, you probably do. Not always. My website is a sand castle in the beach. I take care of it and love it, but I don't mind if the wind takes it down, or if some kids destroy part of it, or if some idiot takes a photo of it and photoshops it in order to misrepresent my work. It is just a sand castle. However, I would feel…

If you're tending such a site as pure art project, fine. However, I suspect the site is there because you envision a community of potential users in this world.

You are not "forced to register". You are asked by your community to make mutual assurances. The easiest system out there relies on a third party, true. There are other third parties, and you could make your own (the most popular one, you might be surprised to hear, didn't exist a few years ago). And there are other ideas of ways to make this mutual assurance. None have taken off in a big way yet, but I'd encourage you to look to them or think of other ways we could do it!

Pretending that we don't need to make this mutual assurance to members of our community is not an option. If you don't like the easy way to do it, find another way.

Post reply on HN