Re:Signing .jars is not worth the effort
by MaxBarraclough on Sunday July 26, 2020 @06:46PM
(#23960746)
> It is, if you screw up with TOFU.
If you simply forget to check the fingerprint, you've got a problem, yes, and this is a risk if it's expected to be done manually. Most users simply can't be bothered, despite that their SSH security depends on it.
As I said though, if you screw up the TOFU check, it's game-over either way: you've failed to verify the identity of the server. If you perform the TOFU check properly, then you have verified the identity of the server. Again, this is regardless of whether you use a password or a public key to authenticate the user.
> This has different ramifications depending on how you authenticate.
Right. With public key authentication, the server is never sent the user's secret (their private key), unlike with password authentication, where the server is entrusted with the user's secret (their password).
This could of course be significant if the attacker is able to capture the user's password, perhaps for the purposes of setting up a man-in-the-middle attack, but I think it's reasonable to treat it as game-over if an attacker has tricked a user into connecting to a machine under the attacker's control. HTTPS works this way; we should apply the same thinking to SSH.
If you simply forget to check the fingerprint, you've got a problem, yes, and this is a risk if it's expected to be done manually. Most users simply can't be bothered, despite that their SSH security depends on it.
As I said though, if you screw up the TOFU check, it's game-over either way: you've failed to verify the identity of the server. If you perform the TOFU check properly, then you have verified the identity of the server. Again, this is regardless of whether you use a password or a public key to authenticate the user.
> This has different ramifications depending on how you authenticate.
Right. With public key authentication, the server is never sent the user's secret (their private key), unlike with password authentication, where the server is entrusted with the user's secret (their password).
This could of course be significant if the attacker is able to capture the user's password, perhaps for the purposes of setting up a man-in-the-middle attack, but I think it's reasonable to treat it as game-over if an attacker has tricked a user into connecting to a machine under the attacker's control. HTTPS works this way; we should apply the same thinking to SSH.