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

71–78 of 78 posts

Re: Plaintext HTTP in a Modern World

#71

Post by TingPing »

marginalia_nu wrote: post #68
TingPing wrote: post #67

Earlier quoted context omitted.

This is just a deeply unhelpful way to think. Firstly it punishes those in the worst situations. Those in countries with abusive political systems, those who have no legal representation, etc. I don't even believe the idea is right in practice "serves to preserve the status quo" is just wrong in this case. HTTPS completely breaks most terrible things ISPs can do. It completely dismantles the system.

> Firstly it punishes those in the worst situations. Those in countries with abusive political systems, those who have no legal representation, etc. HTTPS offers virtually no defense against a state actor. > I don't even believe the idea is right in practice "serves to preserve the status quo" is just wrong in this case. HTTPS completely breaks most terrible things ISPs can do. It completely dismantles the system. HT…

They get an IP but an IP does not always equal a hostname.

Re: Plaintext HTTP in a Modern World

#72

Post by oneplane »

leonth wrote: post #60
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…

I thought the whole reason for encrypted connections is to deny information as much as possible from intermediaries (ISPs), so those who control servers can hoard all the information to their own benefit?

Initially, the main reasons were:

- Identification (bi-directional)

- Privacy (or secrecy)

A side-effect of those are tamper resistance. As the internet got older, more tamper-based abuse was happening and the benefit of tamper resistance became practically more important than the identification part. To be realistic: most people don't actually know how to identify what website they are on, and they also don't know what the identity should be. This is also why EV (extended validation) is completely worthless and mostly purged from webbrowsers.

Re: Plaintext HTTP in a Modern World

#73

Post by oneplane »

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…

Systems that are older than general SSL and TLS usage do indeed have those features, but they are mostly unsuitable for the majority of internet users.

Sadly, it could have been better with varying options of choices in connection, stream and content encryption methods, but that simply isn't feasible with the users and scale we're currently working with.

For niches (and operating systems and software packages are niches, even if an end user is somewhere under the hood using it) it can still be pretty good, especially considering the mirror system where you distribute files to mirrors which might themselves use TLS but you'd still want the distribution authority to be the only one signing those files.

Re: Plaintext HTTP in a Modern World

#74

Post by marginalia_nu »

TingPing wrote: post #71
marginalia_nu wrote: post #68

Earlier quoted context omitted.

> Firstly it punishes those in the worst situations. Those in countries with abusive political systems, those who have no legal representation, etc. HTTPS offers virtually no defense against a state actor. > I don't even believe the idea is right in practice "serves to preserve the status quo" is just wrong in this case. HTTPS completely breaks most terrible things ISPs can do. It completely dismantles the system. HT…

They get an IP but an IP does not always equal a hostname.

It's just one data point though. The real juice comes when you have a hundred thousand traffic logs to compare, then you can start inferring similarities even from vague and incomplete data points.

Re: Plaintext HTTP in a Modern World

#75

Post by tptacek »

Anunayj wrote: post #30
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…

Even better, maybe add TLSA records too! TLSA when combined with DNSSEC can replace the need for Certificate authorities. If you want to show independence from CAs, that's one way to do it.

TLSA replaces certificate authorities like LetsEncrypt with DNS registrars, and, in the process, gives up certificate transparency and the rest of WebPKI surveillance; WebPKI surveillance has resulted in the termination of some of the largest certificate authorities, for misissuance; meanwhile, your browser can't terminate the TLD operators. It's not a good tradeoff.

Re: Plaintext HTTP in a Modern World

#76

Post by yencabulator »

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…

> For example, most official Debian[1] and Ubuntu[2] package repositories currently use HTTP (not HTTPS) by default for content retrieval.

But then you've bootstrapped the trust somehow. If you were to download an ISO from that not-HTTPS website, you'd be at risk.

Re: Plaintext HTTP in a Modern World

#77

Post by mholt »

zhfliz wrote: post #52
Macha wrote: post #15

Earlier quoted context omitted.

I believe there's three or four well accepted ACME providers now, which is why a lot of tools now support or even default to alternative vendors, partly to mitigate this concern. e.g. acme.sh will try ZeroSSL first, Caddy will rotate between ZeroSSL and Let's Encrypt.

acme.sh moving to ZeroSSL has nothing to do with increasing variety. acme.sh moved to ZeroSSL as default due to being sponsored by them. my primary reason for avoiding ZeroSSL is the requirement of providing an email address to them that can be abused.

Caddy doesn't require an email address for ZeroSSL (but we still strongly recommend that for troubleshooting sake).

Re: Plaintext HTTP in a Modern World

#78

Post by Handytinge »

couchand wrote: post #50
enriquto wrote: post #39

Earlier quoted context omitted.

> 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 t…

> 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).

Am I reading this right? Are you suggesting that because LetsEncrypt exists noe, the user should roll their own CA, and have it entrusted by all major browsers?

That's obvious absurd and unachievable. Especially compared to the _existing and functional_ solution of HTTP.

Post reply on HN