Major cloud providers are still shaking issues out of HTTP/2 like "Rapid Reset" 2 months ago, the nesting and layers open gaps and new edge cases as naive implementations were clearly not yet battle hardened even against old attack families like amplification/resource exhaustion.
https://news.ycombinator.com/item?id=37830987 The novel HTTP/2 'Rapid Reset' DDoS attack
https://news.ycombinator.com/item?id=37837043 HAProxy is not affected by the HTTP/2 Rapid Reset Attack
In my opinion its short sighted, because if we care about security, then we should care about user security and privacy as well. Because if the security admin has the ability to packet inspect stuff, so does a potential malicious app.
SSH3 is a complete revisit of the SSH protocol, mapping its semantics on top of the HTTP mechanisms. In a nutshell, SSH3 uses QUIC+TLS1.3 for secure channel establishment and the HTTP Authorization mechanisms for user authentication.
So, it has nothing to do with SSH2; more about HTTP/3-QUIC security theater: hostname is still being sent over TLS/1.3 negotiation.
But I don't see how this is worse than SSHv2. In both cases retrieving the hostname / IP is obviously trivial since you just instrument DNS for the hostname and, of course, the IP is cleartext.
Malicious apps and attackers should not.
Is there a 5-10 year future where you just can’t do this as a middlebox?
It seems that at the time these features were dropped, most middleboxes have ignored features like exporting keys or configuring static RSA keys and went for CA-MitM attacks instead. You should expect these tools to break if they're actively trying to subvert protocols to do things they're not designed to support.
I don't really see what changed, though. I guess static keys were dropped to provide forward secrecy, but other than that running your own rogue CA is as possible as it was 20 years ago. Middleboxes lagging behind in support for features like HTTP/3 is probably annoying, but that's because of a lack of implementation more than anything.
You can still use your domain tools/MDM configuration/settings to configure an HTTPS proxy and firewall off the normal ports if you want to MitM your network reliably. If yiur prozy doesnt support http/3, it will happily downgrade your connection to HTTP/1.1 for you. Android's insistence on not actually applying user-installed certificates is a pain for many apps, but other operating systems will happily and silently drop security measures like certificate transparency when they encounter a user-operated MitM CA.
The lack of MitMability comes down to Android being fussy, IoT devices you had no chance of ever controlling needing workarounds, and devices you don't have permissions to manage not being manageable. I really do wish Android would let MDM solutions inject certificates into the system store (though I can see why they don't with the wide range of stalkerware in the wild).
It is the "others".
SSL is a very well studied standard, but it is clearly a committee product with lots of features built on enterprise standards like X.509, and SSH is made by a few protocol engineers with a razor sharp use case.
It is easy to see why someone who audits parsers for a living would be much more comfortable with SSH as compared to a something over HTTP/SSL/QUIC.
Disclaimer: I write network packet parsers for XNS/IPS/IDS for a living, to look for "bad things".