If state level actors wanted to MITM all SSH connections to make you accept the wrong key, they could. But it has a high chance of being caught as generally, yo

If state level actors wanted to MITM all SSH connections to make you accept the wrong key, they could. But it has a high chance of being caught as generally, you'll pay attention when the key changes. Plus you can reasonably verify the key out of band. (And one could imagine an extension to add a bit of CA-style key verification, like, "was this key generated by my account or my VPS provider, allowing you to manually verify one key and then being set for the rest.) Whereas if you do this on HTTP, a: you're constantly having a lot more "first time" connections. B: you've got no real way to know when the key changed legitimately. Users would quickly grow accustomed to key change warnings and ignore them. Or you'd see banners on sites like "ignore the key warning; I reinstalled my blog and the key changed". Attacks could even inject such a banner. If you want to manually verify every cert, you can already do that today: just go and add certs to your browser! Unauthed HTTPS-by-default just adds complexity and a false sense of security and isn't worth pushing out on the public.