Hacker News Reader

HTTPS is hardly required for websites. Web applications may restrict sensitive actions to HTTPS, but websites over HTTP still work fine.

I try to avoid them because they allow sketchy ISPs to inject ads and other weirdness into my browser, but normal browsers will still accept HTTP by default.

If you don't want people to know you're visiting EmbarrassingFetish.com, EmbarrassingFetish.com also needs to implement ECH (eSNI's replacement) and your browser must have it enabled, otherwise anyone can on the line can still sniff out what domain you're connecting to.

I don't think site authentication is practical, though. For some use cases it works (i.e. validating the origin before firing off a request to a U2F/FIDO2 authenticator), but for normal users, mybank.com and securemybank.com may as well be equivalent (and some shitty important services actually use fake sounding domains like that, like PayPal for instance). Unless you remember the country and state and town your bank is registered in, even EV certificates can't help you because there can be multiple companies with the name Apple Inc. that all deserve a certificate for their website.

Hey, I only read EmbarrassingFetish.com for the recipes section (I recommend their carrot cake.) I'm not into the rest of the stuff there and you can't prove it thanks to HTTPS.

More seriously, you are not wrong. Site Authentication is still a problem and actually the weakest part of HTTPS but it is also more of a people problem than a technical one. Nothing stops somebody from registering MyB4nk.com but at least HTTPS stops crooks spoofing MyBank.com exactly.

> but websites over HTTP still work fine

The best attack surfaces always do. If I'm a smart attacker, why would I impair your experience (at least, until I get what I want)? It's better to give you a false sense of security. There are, of course, dumber attacks that will show obvious signs. While many people do fall prey to such attacks from lapses in, or impairment to, their judgment, the smarter attacks hide themselves better.

The classical model of web security based around "important" sites and "sensitive" actions has been insufficient for decades. It was certainly wrong by the time the first coffee shop/airport/hotel wifi was created; by the time the first colocation provider/public cloud was created; by the time every visitor/student/employee of any library/university/company was given open Internet access; etc.

I think this is the classical explanation and set of examples, which only really explain why HTTPS should be used on "important" websites. But HTTPS should be used on every website and you need a different explanation/example for justifying that.

To connect to a website on the Internet, you must traverse a series of networks that neither you nor the website control. If the traffic is not tamper-proof, no matter how "unimportant" it may seem, it presents the opportunity for manipulation. All it takes is one of the nodes in the path to be compromised.

Scripts can be injected--even where none already exist; images can be modified--you see a harmless cat picture, the JPEG library gets a zero-day exploit; links can be added and manipulated--taking you to other, worse sites with more to gain by fooling you.

None of this is targeted at you or the website per se. It's targeted at the network traffic. You're just the victim.

> If the traffic is not tamper-proof, no matter how "unimportant" it may seem, it presents the opportunity for manipulation. All it takes is one of the nodes in the path to be compromised.

It also ignores one really important fact that these pipes are not perfect, they do introduce errors into the stream. To ensure integrity we would still need to checksum everything and in a way that no eager router "fixes".

We want our bank statements to be bit-perfect, our family pictures not to be corrupted, so on and on.

So even if someone handwaves away all the reasons why we need encryption everywhere (which is insane), we would still need something very similar to TLS and CAs being used. Previous TLS versions have even had "eNULL" ciphersuites.

It would have been nice to have been able to keep eNULL around, but a) it was basically never used in practice and b) the way it worked practically guaranteed it was impossible for the average sysadmin to get right. There's never really a situation in which you might want to negotiate eNULL instead of a specific encryption algorithm. Either the site/page is encrypted or it isn't. Encryption-or-not is on a completely different axis from the type of encryption to use. And configuring older versions of SSL/TLS involved traversing a minefield of confusing, arcane, and trap-laden knobs whose documentation was written for the wrong audience.

> There's never a situation in which a website might want to negotiate eNULL instead of an encrypted option.

Precisely, without some magic handwaving there aren't any reasons.

eNULL was/would also kinda useful if one wanted to debug something without turning off TLS completely. But that's not worth the complexity keeping it around.

> which protects your readers' privacy. You don't want people to know what pages you read on BigBank.com or EmbarassingFetish.com

DNS requests leak this information.

> Tamper Proofing > Site Authentication

There are _many_ sites where this is not important. I want HTTPS for my bank, but I couldn't care less if someone wants to spend the time and effort to intercept and change pages from a blog I read.

> I couldn't care less if someone wants to spend the time and effort to intercept and change pages from a blog I read.

I do not understand why so many people think having, say, zero-day exploits served to them is not a problem.

The blog is not the target; the unsecured connection is.

Approximately nobody is taking the time to hand craft a specific modification of some random blog. They develop and use tools that manipulate any packet streams which allow tampering, without the slightest concern for how (un-)important the source of those packets is.