Re: Fixing exchange of host keys in the SSH key exchange
"denis bider \(Bitvise\)" <[email protected]>
| Newsgroups | gmane.ietf.secsh |
|---|---|
| Message-ID | <AF94B953EDE7493782D80E299F0B24E2@Khan> |
Peter: > https://www.usenix.org/system/files/login/articles/ > 105484-Gutmann.pdf This article is actually a strong argument in favor of Expect-Key, or something like it. What you found is NOT that people use TOFU (Trust On First Use). They use TWAT - Trust Whatever, Any Time: > I asked the IT support staff how many users had called > or emailed to verify the SSH server key whenever it had > changed in the past several years. They were unable to > recall a single case, or locate any records, of any user > ever verifying any SSH server key out-of-band This is highly problematic because it means that, while SSH is supposed to defend against MITM in theory, it does not defend in practice. OpenSSH already addresses this in their client, I believe, by making it really quite hard to verify a changed key. Many users further configure the OpenSSH client to require a key to be set up for the first connection, to begin with. Expect-Key just extends that - which I think is a good practice - to all clients, in general, enforceable as a server-side policy. It defeats TWAT. > Conversely, it means the vast majority won't use it. Users will use what administrators set up for them. If admins don't want to set up Expect-Key, fine. But this gives them a tool. denis ----- Original Message ----- From: Peter Gutmann Sent: Sunday, March 26, 2017 02:53 To: Mouse ; [email protected] Subject: Re: Fixing exchange of host keys in the SSH key exchange Mouse <[email protected]> writes: >As far as I can see, this affects the user only in that "pick up the host >key >on first connect" no longer works. It breaks TOFU. Since this is how the vast majority of all users use SSH (ref: https://www.usenix.org/system/files/login/articles/105484-Gutmann.pdf), it means it would break SSH for them. Conversely, it means the vast majority won't use it. >Then this suggestion has the additional feature that it will smoke out such >bugs! Trying to smoke out non-standards-compliant implementations at this point, about twenty-odd after SSH2 started getting deployed, is probably a bit late in the game. Also, does this mean any implemenation that doesn't correctly implement a MUST or MUST NOT can regarded as broken and discarded? Peter.