4 ms·

> 3) SSH without certificates is more vulnerable to MITM than HTTPS (with certificates) Why would you claim that? As long as any CA with its root certificate i

by c0l0 5y ago

> 3) SSH without certificates is more vulnerable to MITM than HTTPS (with certificates) Why would you claim that? As long as any CA with its root certificate in your trust store can vouch for any identity, I would argue that TOFU (where you verify the remote resource's key is in control of the identity you intend to connect with) is less prone to having your connection MITM'd, since the attacker would have to either break the underlying cryptography, or exfiltrate the remote's private key. With the CA system in place, you "just" need to get another CA to sign for the identity you would like to spoof. Not saying it's easy, but for the proverbial "nation state"-level attacker (maybe with their own CA root already in your trust store :)), it's certainly easier to do that than to break RSA or EC.

lmm 5y ago
> Why would you claim that? As long as any CA with its root certificate in your trust store can vouch for any identity, I would argue that TOFU (where you verify the remote resource's key is in control of the identity you intend to connect with) is less prone to having your connection MITM'd, since the attacker would have to either break the underlying cryptography, or exfiltrate the remote's private key. There are about 170 root CAs, and not all of them are trusted for every domain. There's also things like certificate transparency that make the kind of attack you're talking about much harder. TOFU protects you against a one-off MITM but not against an ongoing attack (and the fact that host keys routinely change for non-attack reasons means many users don't treat a host key mismatch as especially serious).
0xbadcafebee 5y ago
> Why would you claim that? 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.

by c0l0 5y ago

lmm 5y ago

> Why would you claim that? As long as any CA with its root certificate in your trust store can vouch for any identity, I would argue that TOFU (where you verify the remote resource's key is in control of the identity you intend to connect with) is less prone to having your connection MITM'd, since the attacker would have to either break the underlying cryptography, or exfiltrate the remote's private key. There are about 170 root CAs, and not all of them are trusted for every domain. There's also things like certificate transparency that make the kind of attack you're talking about much harder. TOFU protects you against a one-off MITM but not against an ongoing attack (and the fact that host keys routinely change for non-attack reasons means many users don't treat a host key mismatch as especially serious).

0xbadcafebee 5y ago

> Why would you claim that? 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.