Hi Ian,
I've been developing web applications since the mid 90's (yes, the very beginning). I think there are a number of problems with your argument which basically come from a lack of experience with this stuff. This is a complex topic, and I will only give simple answers below, if you want to develop a web site, it is your responsibility to learn this in depth (or employ someone that has) - and honestly most people get it wrong at least a few times. The developer must work with the tools the browsers supply to ensure security.
Internet security is built on a number of layers, TLS (the encryption behind HTTPS) is only one on them, the browser implements many layers of defence in depth that I think you should go and read about. Basically it is all layers of trust, starting at the user deciding to visit your site and trusting you, the developer/owner, that you are doing things properly. And yes, this means that it is easy to have untrustworthy sites - protect yourself with knowledge; but without this web of trust, the Internet wouldn't exist, period.
TLS / HTTPS has exactly 2 jobs. Authentication of the Server to the Client browser (it is possible to also authenticate the client to the server, but this is almost never done), and ensuring the data over the wire is secure and tamper proof. That's it. nothing more.
Yes, older cipher suites are now considered insecure and are deprecated in any good browser. This is normal and was built into the negotiation process from the beginning. Also look at certificate pinning where it is possible to detect that a certificate has been substituted (this can be done in a corporate environment for instance where a new root authority can be created).
I believe you are miss-understanding the same-origin-policy.
This is enforced very rigorously by the browser at the DOCUMENT level - that is a HTML document that you load. The supposed MITM attach you demonstrate is invalid - you, as the site developer - have SPECIFICALLY GRANTED TRUST to your supposed evil site by including it into the document. This is EXACTLY how the web is supposed to work, it is a very useful and powerful thing. But as you demonstrated - if you aren't careful (as a site developer), you will get pwned, often..
If you don't trust a site, you MUST NOT include any resources from it, especially scripts because once you do that script is considered part of your document because you have explicitly trusted it (by writing the script tag).
If you DON'T trust the site, but you still want to use the "content" they offer (eg Ads) you must IFRAME it into your site. This creates a brand new document / security scope with the same-origin-policy set up for their domain. Your document tells the browser where to place that document, and that is it. There is no way that iframe document (excluding browser bugs, and some very carefully designed message passing schemes that require cooperation between both ends) can access information in your document.
To address issues you raised on your article about HTTPS "failing" to protect a password at the ends - yes, correct it doesn't. Given its role, it makes absolutely no sense to assume that it would.
Protecting passwords is your job as a developer. Hint - NEVER EVER EVER store passwords or simple hashes of passwords anywhere. The incoming password should immediately be securely hashed (
https://crackstation.net/hashing-security.htm) and securely erased from memory before using this hash to verify identity and issuing a session level identity token. Read about OAuth for instance. If done at scale the "normal" web site doesn't handle passwords at all, only tokens, a separate very carefully audited and protected site manages the user authentication process. Basically these tokens are stored as cookies with various settings to ensure they are only ever sent over encrypted connections to a specific host (or domain related to the host) - the site works with the tools the browser supplies to ensure this token which represents your identity can't be compromised.
I should also point out to those reading this, that you shouldn't trust ANY web site too much. Get a secure password manager (I use KeePass, but there are others) and have a different large randomly generated password for each web site. Protect this with a long, strong password in your password manager - a long phrase or sentence is a good start. This way when the inevitable security breach occurs (because developers are people and make mistakes) it is just that one site that is compromised.
For instance, I've dealt with local service company that is clearly storing plain text passwords, and even better presenting these passwords to their support people - I've been on the phone to one and the lady commented "oh, wow, that's a weird password" when she opened my profile.. (it was a large random string) WTF.. that is why I use password managers.
Hope that help clarify the issues, not start a flame war.
I'm happy to discuss the specifics, but it probably doesn't belong on EEVBlog..
Actually, if anyone here develops embedded stuff with web sites maybe it does.. These are often insecure (wifi routers, I'm looking at you)
Ash.