Well, ok, but what about the websites that don't have ads or logins or other personal information?
And privacy of information going from your browser to the internet is only half of the equation. What about privacy about what you are viewing?
I don't want every single router between my computer and the server knowing the full contents of the pages I'm choosing to view, or building advertising profiles on my habits, or even knowing what device type, browser, OS, and more I'm using.
So don’t use a shitty ISP that tries to MITM you.
Problem solved. How is that even controversial?
Rather than the hospital supplying any kind of proper authentication, they MITM the first connection to their WiFi, and logged your IP address as your user. They also required you refresh that connection every half hour or so.
There are a lot of people doing things in really bad ways.
We can't fix all of them, and often we don't have a choice about interacting with them.
Would a self-signed (I'm not sure this is the right terminology) cert be sufficient for this?
That way if someone MITM'd you, you would see that the cert changed, right?
But I guess if the path you use to the website is always the same, then if they MITM'd you the first time you accessed it, you wouldn't be able to tell?
Hmm, I guess that probably isn't enough then.
Is there really no good way to serve public information from a website that doesn't require periodically updating one's cert, and without risking MITM'ers changing the content?
I guess if the client already has the hash of the content, but that isn't very convenient.
Huh.
I guess example.com needs https then?
They don't use HSTS to force it, because example.com isn't meant to anything but an example.
Yes, but browsers make that MUCH more scary than surfing insecure (not https) sites.
I can publish my personal CA certificate and ask you to trust it. This is hardly different than how I prove myself to Lets Encrypt.
These days Let's Encrypt uses a "multiple view" approach in which more than one physical location in the world hosts Let's Encrypt systems (although only their US West Coast location contains the actual CA) and so they can check that things appear the same from more than one angle, you can't just take over the ISP they're getting service from in California and leverage that to get anything you want. If the views don't agree (e.g. you pass a Let's Encrypt validation from Paris but not from San Francisco) then your application is denied automatically.
Now, the next layer above is also interesting. Who checks Let's Encrypt and other public CAs are doing their job? Fortunately Mozilla are on the case again, all major Trust stores say they enforce the Baseline Requirements which explain how a CA should do its job, but all except one make decisions entirely in private. Or maybe they just bin all the complaints if the CA pays them a bribe? Who knows. Mozilla acts openly in public, you can (and indeed your insight might be valuable, so please do) help oversee the Web PKI in their m.d.s.policy group.
Problem is that browser warnings are sometimes false. Self signed certificates are not unsecure, the underlying encryption is still the same. The "unsecure" only applies to the CA, but that is not clear in the warning.
Browser warnings aren't false, you're reading of them is false. Read around on badssl.com [0]. The self-signed warnings in chrome say:
>Attackers might be trying to steal your information from self-signed.badssl.com (for example, passwords, messages, or credit cards).
And when you click advanced chrome says:
>This server could not prove that it is self-signed.badssl.com; its security certificate is not trusted by your computer's operating system. This may be caused by a misconfiguration or an attacker intercepting your connection.
It says nothing about the encryption being bad, I don't know where you got that from. What it does say is that Chrome has no way to validate that the site you are going to is actually the site in the address bar. Encryption is pointless if anyone and everyone knows the password (oversimplified, but you get the point). Encryption without Authentication is as secure as normal HTTP.
No it is not wrong, even your confusingly worded sentence there is still fully correct.
Security (or encryption, or any other synonym you can come up with here) is made up of 3 (well technically 4) parts:
* confidentiality
* integrity
* authenticity
* (and technically non-repudiation, but that doesn't really apply here)
self-signed HTTPS certificates only provides 2 of the 3 (confidentiality and integrity) and it's that last one that is most important (authenticity), because without it you don't know who you are talking to. It could be your website, or it could be some asshole down the street pretending to be your website, you have literally no idea.
You say it's misleading, but it is you that is misreading and misunderstanding the concepts. Encryption without authentication is like encryption without a password. Utterly pointless.
Just like my analogy, AES encryption with a password of nothing is "unsecure", and no matter how much you try to argue that it's still perfectly secure, you are wrong..
Just like this, the AES is pointless when ANYONE can set the password (or in more correct terms, when anyone can create one with the user in a DHKE). If you can't tell that the server you are talking to is actually the server you meant, then AES does fuckall, because the man-in-the-middle is the one that is setting the password!
You are doing the equivalent of telling me how secure your new house door lock is, while wiring it up to always unlock when someone rings the doorbell... All the security in the world won't help you when you give everyone a way to bypass it instantly.
Luckily browsers will show you the warning saying that page is insecure, and give you the option of going there anyway after you have validated that the cert is the same.