Re: UpdateHostkeys now enabled by default

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

 



On Sun, 2020-10-04 at 14:02 +1100, Damien Miller wrote:
> This is strictly no worse than continuing to use the old key, so I
> don't
> consider it a problem.

Well but in reality it will lead to people never again replace their
key by proper means.


> How is this different to the status quo? If you don't clean up keys
> after
> a compromise then you have a problem. Anyone doing this already has
> to
> be prepared to deal with multiple keys being known for a host. The
> tooling
> support for doing this (ssh-keygen -R) works identically regardless
> of
> the number of keys.

Well the big difference is IMO:
AFIAU this feature distributes the newer server keys to clients right? 

So even if the compromise is detected on the server side (and properly
cleaned up) the may be countless of clients (which you can never reach
all) who still have the compromised keys and may subsequently be
vulnerable to MitM, since they'd still trust that the key authenticates
server foo.bar.

Same scenario obviously if the compromise is never detected but just
used to get keys for MitM servers to clients... and afterwards removing
any trace/backdoor from the server.


Cheers,
Chris.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev



[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux