> TOFU is less prone to having your connection MITM'd
Not if you wait for the first SSH connection. Or a key is rotated. Or a new server with new host keys is added. Or the user disables their own strict host key checking. MITM is trivial in these cases. There's tools for it that any script kiddie can use.
They've already connected once? That's fine. Drop their connections and force them to try a connection to a new host, new IP, or from a new machine or client. In any case it'll be a new "TOFU" use case, the user will accept the new host keys, and never verify the signature. Or just try MITM at any time and see if the user has already disabled strict host key checking, as many online guides instruct, or if the user thinks their remote host just has new host keys that need to be replaced.
HTTPS does not have these vulnerabilities, by design, because PKI. Your connection is always authenticated against a trusted key store, you don't ever need to validate a signature by hand, and it's not common for people to turn off validation. In addition (if Git actually implemented this, and I'm not sure why it doesn't) it could use HPKP and HSTS to ensure that a specific key for a specific site was always validated, which would eliminate the different vulnerability that you mention for trusted CA certs.
So for default connections where SSH does not use Certificates (basically all SSH use cases) HTTPS is more secure by default, and supports more ways to prevent MITM.
Because it's a fact?
> TOFU is less prone to having your connection MITM'd
Not if you wait for the first SSH connection. Or a key is rotated. Or a new server with new host keys is added. Or the user disables their own strict host key checking. MITM is trivial in these cases. There's tools for it that any script kiddie can use.
They've already connected once? That's fine. Drop their connections and force them to try a connection to a new host, new IP, or from a new machine or client. In any case it'll be a new "TOFU" use case, the user will accept the new host keys, and never verify the signature. Or just try MITM at any time and see if the user has already disabled strict host key checking, as many online guides instruct, or if the user thinks their remote host just has new host keys that need to be replaced.
HTTPS does not have these vulnerabilities, by design, because PKI. Your connection is always authenticated against a trusted key store, you don't ever need to validate a signature by hand, and it's not common for people to turn off validation. In addition (if Git actually implemented this, and I'm not sure why it doesn't) it could use HPKP and HSTS to ensure that a specific key for a specific site was always validated, which would eliminate the different vulnerability that you mention for trusted CA certs.
So for default connections where SSH does not use Certificates (basically all SSH use cases) HTTPS is more secure by default, and supports more ways to prevent MITM.