| My comments: > When connecting to the internet required calling the ISP with a modem, it was
possible to encrypt the whole call Assuming this is talking about MPPE for PPP, it's completely broken[1]. > if the server also has (and it probably will have) a trusted connection to the public internet and the route of the packages between the server and the user's ISP is known. Trustworthy connections to the public internet don't really exist. Routes can be changed via BGP hijacks at any time[2]. > Often the route of the packages is also completely known (for example in intranets) Intranets are almost always vulnerable to MitM via ARP spoofing[3]. > Are we encrypting a wrong protocol? This point argues that it is wasteful to wrap end-to-end encrypted messages with HTTPS/TLS. Given how regularly people botch implementing things like that, HTTPS/TLS provides a useful safety net - and the overhead is negligible. > there is nothing wrong with self-signed certificates as long as the browser actually shows the relevant information (the public key etc.) so that the user can make sure that the other end of the connection really is what it claims to be. The vast majority of users cannot do the "making sure" bit suggested here. Of those who can, the vast majority (including myself here) don't. > Allow using the site with retro hardware. This can be solved with a proxy. > some [...] cannot afford a newer, more modern device. Continually imposing new technical requirements for accessing the site may be discriminating against these people. I expect that the vast majority of devices less than 10 (even 15) years old can run software which can handle modern protocols just fine. > Let the user decide. [...] Web browsers, and in many cases also servers, should respect the user's choice. The vast majority of users are incapable of meaningfully consenting to unencrypted connections. 1. https://www.computerworld.com/article/2505117/tools-released... 2. https://www.theverge.com/2018/4/24/17275982/myetherwallet-ha... 3. https://en.wikipedia.org/wiki/ARP_spoofing |
Crucially, the browser is showing you historical information. This was the certificate for a transaction which already happened. Because this is about the past not the future you can't make decisions here, only have regrets.
Whereas for certificate name verification and all the other stuff your browser does, that is done by the browser in real time during the connection setup.
When you type the destination bank account, and amount to send, into a bank's "send money" form, and then decide to "check the certificate" the browser is not showing you a certificate for the HTTPS transaction you're about to perform, it can't. It's showing you the certificate associated with the form page, when you click "Submit" or "Send" or whatever, there may be a totally different certificate for the HTTP POST operation, it may result in a 30x redirect, which can result in yet another different certificate, you aren't shown these certificates before your form data is sent, the browser does all its checks because they're instant, but your dithering would be too slow.