10 ms·

Certificates provide extra features, like revocation. However, if you do not need the extra features provided by certificates, using SSH-generated keys is stri

Certificates provide extra features, like revocation. However, if you do not need the extra features provided by certificates, using SSH-generated keys is strictly equivalent with using certificates and it requires less work. TOFU is neither necessary nor recommended, it is just a convenience feature, to be used when security may be lax. The secure way to use SSH is to never use TOFU but to pair the user and the server by copying the public keys between the 2 computers through a secure channel, e.g. either by using a USB memory or by sending the public keys through already existing authenticated encrypted links that pass through other computers. (Such a link may be a HTTPS download link.) When using certificates, a completely identical procedure must be used. After certificates are generated, like also after SSH keys are generated, the certificates must be copied to the client computer and the server computer through secure channels.

palata 7mo ago
> TOFU is neither necessary nor recommended Just to make it clear: this does not mean that it is fine to blindly accept the message on first use. The "secure way" implies copying the server's public key as well, which people generally don't do, right? Which is equivalent to verifying the fingerprint shown with the TOFU message, correct?
- adrian_b 7mo ago
  Like I have said the secure way requires the secure copying of both keys before the first connection attempt The server public key must be copied into "known_hosts" on the client, while the client public key must be copied into "authorized_keys" on the server. When this is the procedure that is always followed, any message shown by SSH about an unknown host means that the connection must be aborted, because the identity of the server is unknown. You cannot truly verify the "fingerprint" displayed by SSH, unless you simultaneously have access to another computer, where you have a copy of the fingerprint. What is usually meant by "verifying" is that you remember a few digits of the fingerprint, and those match. You could have copied the fingerprint from the server, to be able to truly verify it, but that does not make sense, because in that case you should have copied the entire key, not just the fingerprint, and you should have installed it in the client. When you use only authentication with digital signatures, it does not make sense to use any other procedure, because you must make at least one of the two copies anyway, so when copying the client key to the server you can take the server key, to carry it back to the client. The TOFU method is meant to be used together with password-based authentication, in less secure applications, where no physical access to the server is required for setting up SSH on the client. By "less secure" I mean for example applications equivalent to HTTPS, where the client is not really authenticated, e.g. when providing a public password allowing read-only access to an SSH server through Internet.
  - palata 7mo ago
    > Like I have said Sure, I just wanted to make sure that nobody would understand "TOFU is neither necessary nor recommended, just ignore that message and say "yes" when it appears". Both ends need to be sure of who is on the other end, and there are different ways to achieve that. The way SSH works is that if you haven't copied the server public key locally, it will explicitly ask you to verify it the first time. I am not sure that "SSH does TOFU". SSH asks you to verify. The human who YOLOs it and approves it without checking is the one doing TOFU, and this is not really secure.
akerl_ 7mo ago
> When using certificates, a completely identical procedure must be used. After certificates are generated, like also after SSH keys are generated, the certificates must be copied to the client computer and the server computer through secure channels. That is not the case, and is a major advantage of certificates.
- adrian_b 7mo ago
  What you say is extremely wrong and this misconception is very dangerous. When an authenticated connection between a client and a server (or any other 2 computers) is established, before the connection can be initiated both ends must already have a piece of information that has been copied to them through a secure channel, otherwise the authentication is impossible. The 2 pieces of information may allow direct reciprocal authentication, i.e. the client may have the server certificate and the server may have the client certificate. It is also possible to have indirect authentication, e.g. the server sends the server certificate to the client and the client sends the client certificate to the server during the initiation of the connection. However, for indirect authentication, both the client and the server must had been previously paired with a server hosting the certification authority. This means that the root certificate of the CA must have been transferred through secure channels to the client and to the server, and also that the client certificate and the server certificate must have been transferred through secure channels to the CA for signing and then back to the client and the server. So setting up the computers for indirect authentication through certificates requires significantly more transfers through secure channels than setting them up for direct authentication. The advantage of indirect authentication appears in an organization with a great number of computers, where indirect authentication reduces the number of secure pairings that must be done from N*(N-1)/2 to N. However this has nothing to do with certificates. Indirect authentication can be done without certificates, like in Kerberos, or like in SSH if you have a management computer that you pair by copying the public_keys with every computer in the network. Later, whenever you want to enable some client to connect to a SSH server you use the management computer to copy securely the corresponding public_keys between the server and the client. So no, there is no advantage of certificates related to reducing the number of transfers that must be done through secure side channels, like copying through a portable memory. Certificates provide other features, like temporary validity and revocation, which can be useful in an enterprise context.
Terr_ 7mo ago
> secure channel, e.g. either by using a USB memory Aside: We need a "safely dumb" storage plug standard. Right now the flexibility of USB is a double-edged sword, any USB device could potentially be malicious, waiting for the right moment to send keystrokes as a keyboard etc. Or use the same plug for everything, but support a "passive storage only" that can be enforced by a special adapter or cable.
- akerl_ 7mo ago
  Assuming you’re not just soliciting random thumb drives from strangers… this doesn’t feel like an actual risk. When you’re getting things from strangers, use any of the myriad ways to send files over a network, where HTTP / your browser are the safe dumb plug.
  - soupbowl 7mo ago
    The place you buy the thumb drive is also a stranger that can't be trusted.
    - akerl_ 7mo ago
      This kind of paranoia isn't productive.
      - Terr_ 7mo ago
        It was productive enough for the NSA and FBI when they were intercepting equipment deliveries and installing backdoors in them. A USB stick that can secretly remember any file that looks like a key file or certificate would be very easy.

palata 7mo ago

> TOFU is neither necessary nor recommended Just to make it clear: this does not mean that it is fine to blindly accept the message on first use. The "secure way" implies copying the server's public key as well, which people generally don't do, right? Which is equivalent to verifying the fingerprint shown with the TOFU message, correct?

adrian_b 7mo ago
Like I have said the secure way requires the secure copying of both keys before the first connection attempt The server public key must be copied into "known_hosts" on the client, while the client public key must be copied into "authorized_keys" on the server. When this is the procedure that is always followed, any message shown by SSH about an unknown host means that the connection must be aborted, because the identity of the server is unknown. You cannot truly verify the "fingerprint" displayed by SSH, unless you simultaneously have access to another computer, where you have a copy of the fingerprint. What is usually meant by "verifying" is that you remember a few digits of the fingerprint, and those match. You could have copied the fingerprint from the server, to be able to truly verify it, but that does not make sense, because in that case you should have copied the entire key, not just the fingerprint, and you should have installed it in the client. When you use only authentication with digital signatures, it does not make sense to use any other procedure, because you must make at least one of the two copies anyway, so when copying the client key to the server you can take the server key, to carry it back to the client. The TOFU method is meant to be used together with password-based authentication, in less secure applications, where no physical access to the server is required for setting up SSH on the client. By "less secure" I mean for example applications equivalent to HTTPS, where the client is not really authenticated, e.g. when providing a public password allowing read-only access to an SSH server through Internet.
- palata 7mo ago
  > Like I have said Sure, I just wanted to make sure that nobody would understand "TOFU is neither necessary nor recommended, just ignore that message and say "yes" when it appears". Both ends need to be sure of who is on the other end, and there are different ways to achieve that. The way SSH works is that if you haven't copied the server public key locally, it will explicitly ask you to verify it the first time. I am not sure that "SSH does TOFU". SSH asks you to verify. The human who YOLOs it and approves it without checking is the one doing TOFU, and this is not really secure.

akerl_ 7mo ago

> When using certificates, a completely identical procedure must be used. After certificates are generated, like also after SSH keys are generated, the certificates must be copied to the client computer and the server computer through secure channels. That is not the case, and is a major advantage of certificates.

adrian_b 7mo ago
What you say is extremely wrong and this misconception is very dangerous. When an authenticated connection between a client and a server (or any other 2 computers) is established, before the connection can be initiated both ends must already have a piece of information that has been copied to them through a secure channel, otherwise the authentication is impossible. The 2 pieces of information may allow direct reciprocal authentication, i.e. the client may have the server certificate and the server may have the client certificate. It is also possible to have indirect authentication, e.g. the server sends the server certificate to the client and the client sends the client certificate to the server during the initiation of the connection. However, for indirect authentication, both the client and the server must had been previously paired with a server hosting the certification authority. This means that the root certificate of the CA must have been transferred through secure channels to the client and to the server, and also that the client certificate and the server certificate must have been transferred through secure channels to the CA for signing and then back to the client and the server. So setting up the computers for indirect authentication through certificates requires significantly more transfers through secure channels than setting them up for direct authentication. The advantage of indirect authentication appears in an organization with a great number of computers, where indirect authentication reduces the number of secure pairings that must be done from N*(N-1)/2 to N. However this has nothing to do with certificates. Indirect authentication can be done without certificates, like in Kerberos, or like in SSH if you have a management computer that you pair by copying the public_keys with every computer in the network. Later, whenever you want to enable some client to connect to a SSH server you use the management computer to copy securely the corresponding public_keys between the server and the client. So no, there is no advantage of certificates related to reducing the number of transfers that must be done through secure side channels, like copying through a portable memory. Certificates provide other features, like temporary validity and revocation, which can be useful in an enterprise context.

Terr_ 7mo ago

> secure channel, e.g. either by using a USB memory Aside: We need a "safely dumb" storage plug standard. Right now the flexibility of USB is a double-edged sword, any USB device could potentially be malicious, waiting for the right moment to send keystrokes as a keyboard etc. Or use the same plug for everything, but support a "passive storage only" that can be enforced by a special adapter or cable.

akerl_ 7mo ago
Assuming you’re not just soliciting random thumb drives from strangers… this doesn’t feel like an actual risk. When you’re getting things from strangers, use any of the myriad ways to send files over a network, where HTTP / your browser are the safe dumb plug.
- soupbowl 7mo ago
  The place you buy the thumb drive is also a stranger that can't be trusted.
  - akerl_ 7mo ago
    This kind of paranoia isn't productive.
    - Terr_ 7mo ago
      It was productive enough for the NSA and FBI when they were intercepting equipment deliveries and installing backdoors in them. A USB stick that can secretly remember any file that looks like a key file or certificate would be very easy.