Live data from Hacker News

Plaintext HTTP in a Modern World

jcs.org

21–30 of 78 posts

Re: Plaintext HTTP in a Modern World

#22
post #7

>While this push for security is good for protecting modern communication, there is a whole web full of information and services that don’t need to be secured It's not only about security. I wonder if it happens in other countries too - here in Russia ISPs used to inject advertisements directly into HTTP traffic which was very annoying and now they inject propaganda justifying the war. Fortunately very few sites use…

Comcast used to do this, Verizon too I think (as well as DNS hijacking).

Ugh DNS hijacking is the worst. One of the big residential ISPs for a time would trap NXDOMAIN and redirect to a damn search page with ads. So gross.

Re: Plaintext HTTP in a Modern World

#23
I was going to comment that they would probably enjoy learning about Gopher, the competitor to http, which is a simple enough protocol to browse without a client, but they beat me to it when they brought up Gemini at the end of the article. Gemini they describe as similar to Gopher but with Markdown, then berate it for requiring TLS. Perhaps they can fork it.

Re: Plaintext HTTP in a Modern World

#24

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 receiver verifies the signature.

Someone able to inspect your network traffic could, for example, tell that you've downloaded a genuine copy of "cowsay". Or they could detect that the server replied with a tampered copy (something that your client should reject as invalid).

[1] - https://wiki.debian.org/SourcesList#Example_sources.list

[2] - https://ubuntu.com/server/docs/package-management

Re: Plaintext HTTP in a Modern World

#25
> [Gemini’s] document markup language is based on Markdown so it’s very lightweight and simple to parse without complex HTML/CSS parsers.

I wouldn’t describe it in this way.

Markdown is in no way simple to parse; HTML is actually easier to parse than Markdown, because it’s defined in terms of an actual parser, whereas the best source for Markdown parsing is CommonMark, which uses a more traditional descriptive spec, meaning you have to think a lot more about it to implement it, and run a test suite over it to be fairly confident you’ve got it right. Sure, HTML is heavier, but it’s much easier to implement and more dependable. The HTML spec is sufficiently large that there are some dark corners I expect very few humans to get right based on their own mental models (e.g. script double escaped state), and if you want to omit open or close tags or commit parse errors it requires more knowledge, but by and large, if you’re sticking to what I could imagine being the subject of a hypothetical book “HTML: the good parts”, it’s very easy to predict with only a little special knowledge required (mostly around which elements are void). But Markdown is generally much harder to predict, and becomes awfully unpredictable as soon as you start interleaving much HTML at all.

Gemtext is a completely different beast that works in a completely different way, vastly simpler. Any resemblance to Markdown is superficial. Yes, it uses ``` as a preformatted code delimiter, * for list item lines, # for heading lines and > for blockquotes, but two of these are ancient conventions, and the other two (and slight variants) commonly found in other lightweight markup languages as well. As far as the semantics are concerned, Gemtext is radically different from Markdown, as it’s strictly line-based, and the first three characters are sufficient to determine a line’s type, and there’s no inline formatting. (There’s one more piece of syntax, => links, which is novel in syntax and semantics. And ``` has different semantics from CommonMark too, with alt text instead of an info string, though neither have particularly defined semantics for the use of that part.)

Gemtext is not based on Markdown. Some elements of its (meagre) syntax were most likely inspired by Markdown, but it’s not based on Markdown.

Re: Plaintext HTTP in a Modern World

#26

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.

Seems like a browser issue, not a website issue.

Re: Plaintext HTTP in a Modern World

#27
HTTPS is great, of course, but there's still a place for plain HTTP. It is essential that HTTP continues to be universally supported (even behind the ridiculous warnings that browsers put these days). There are several, independent reasons for that:

1. You can build a complete http server and client from scratch with a manageable number of lines of assembly code, as has been demonstrated many times. The innocent "s" in the protocol would be the largest part of that implementation if it was required. Let's allow simple harmless things to stay around.

2. For static http pages with permanent content, encryption is not really necessary. These pages are just like posters hanging on the wall. Of course third parties can "mitm" them and write over them, but it doesn't really matter. It's nice that we can still hang random posters around.

3. Setting-up an https server requires involving another party (the CA) that now holds some power over your content. Since the CA can now effectively shut down your site, they may succumb for pressure to do so. This has already happened. The widely used "let's encrypt" has been made to hold responsibility for the certificates that they issue to sites with problematic content, and they have removed certificates to these sites, which is tantamount to shutting them down. So far, this has just happened for neonazi content, which is alright to censor in my view; but I'm worried that other people will be alright with censoring content which I find reasonable.

Re: Plaintext HTTP in a Modern World

#28

Earlier quoted context omitted.

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.

Seems like a browser issue, not a website issue.

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

Re: Plaintext HTTP in a Modern World

#29

Earlier quoted context omitted.

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.

Seems like a browser issue, not a website issue.

> Seems like a browser issue, not a website issue.

That's why Mozilla and Google have been working on the transition to HTTPS for years.

Mozilla announced deprecating HTTP back in Apr/2015 [1], to allow plenty of time for everyone to upgrade.

1. https://blog.mozilla.org/security/2015/04/30/deprecating-non...

Re: Plaintext HTTP in a Modern World

#30
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.
Post reply on HN