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