Dangerous Web Security Features

Most employers are always looking for opportunities to cut costs, and so the $$ product that is superficially similar gets chosen not the $$$ product that will "log everything".

The $$$ solution is to literally MITM every TLS session. Build two session, one in which you pretend to be the server, one in which you pretend to be the client, and log everything as you copy it from one to the other. You need a fair amount of horsepower (CPU or specialist ASIC) and somewhere to keep all those logs, neither is cheap.

The $$ solution may have the option to resort to that, but it will lack the horsepower to do it at line rate, (e.g. you may have an appliance on a 100Mbps network that can't do this faster than 5Mbps) or the storage to log at line rate (at 100Mbps that's about 1TB per day) so unless you're being tracked specifically it's probably only doing this:

1. When you makes a new TLS session it stalls you, to see who the far end is, until TLS 1.2 they'll present their certificate in plain text, so the middlebox can read it without needing to actually MITM you. Unless the target is blocked you're allowed through, and probably not logged to save storage.

2. When a session resumption happens, the middlebox has no idea who you're talking to, but it presumes that you must be talking to someone it previously allowed, so, it makes sense to just allow this and not inspect it beyond maybe noting which IP you connected to and when.

There are a lot of ways to screw this up that destroy security, but that's the nature of cheap security appliances, you pay money, you feel better, you probably don't get any actual security.

This all gets even more amusing for TLS 1.3, notice how in bullet point 2 these boxes let through all resumptions? TLS 1.3 deliberately looks exactly like a TLS 1.2 session resumption except with a "Ssh! This is actually TLS 1.3" marker so that a TLS 1.3 server knows what's really going on. For plenty of people TLS 1.3 "just worked" because their "security" appliance doesn't actually deliver any security.

As for your third paragraph—I would agree that banks should act more like APIs and less like their own countries. But that is independent from the use of a protocol. Arguing between TLS (HTTPS) and SSH borders on bikeshedding.

The reality is more than a billion people are successfully using HTTPS to safely and securely manage their money, and HSTS is improving the guarantees around that security. I'm sure you've solved every security and trust risk with this hypothetical bank-over-IRC-over-SSH protocol with non-mandatory security... but I'm not yet convinced.