@jennamagius interesting, but where do I read a simple, clear description of how TOFU is solved? I'm struggling a little to piece it togther
@lupine TOFU is solved by not doing TOFU. If the server isn't pre-existingly in possession of the public key presented by the client, the server will not talk to the client.
@lupine There's no trick, really, you just... don't.
The trick is, users will not do any extra work once they have a thing working. So you make it so they have no recourse to get it working insecurely.
@jennamagius I guess I meant the alternative, that allows clients to have confidence they are talking to the right server.
Found "This packet is built using a piece of data known as the "knock key". The knock key is a collection of random bytes that are pre-shared out-of-band between the server and all clients of the server." Is the main difference that this can't be disabled?
@lupine The kex happens symmetrically, and after the server accepts a long-term client key it presents a long-term server key, which proves the server identity like a host key does. The code as-it-is requires that the client already know that public key in advance also.
Someone building their own client could skip that step, but there's still the PSK that'd cause trouble for a man-in-the-middle.
@jennamagius awesome, thanks for explaining!
@lupine No, the property hold even if you were to skip the knock step: in the key exchange step, the client presents an asymmetric key (the long-term client key). The server has pre-existing knowledge of all valid long-term client keys and will not accept ones it does not already know about.
The server is the one who has the prerogative to "be sloppy" at that step, but that's also where the auth happens.
It's authorized_keys and known_hosts at the same time.