Re: blacklisting the bad ssh keys?
Ahh the irony, apparently Debian has implement just such a feature, but as patch to ssh within their distro: http://www.mail-archive.com/[EMAIL PROTECTED]/msg214853.html On Thu, May 22, 2008 at 11:19:05AM -0700, Abe Singer wrote: On Wed, May 14, 2008 at 07:52:58PM -0400, Steven M. Bellovin wrote: Given the published list of bad ssh keys due to the Debian mistake (see http://metasploit.com/users/hdm/tools/debian-openssl/), should sshd be updated to contain a blacklist of those keys? I suspect that a Bloom filter would be quite compact and efficient. As someone who is dealing with this operationally, we (SDSC) had already identified what Steve suggests as the desireable long-term solution. I would reword the requirement slightly to say that the capability of sshd should be to block use of any key specified by the adminstrator, not necessarily just the published blacklist. I think that's what Steve may have actually meant, but clarity is helpful. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: blacklisting the bad ssh keys?
At Wed, 14 May 2008 19:52:58 -0400, Steven M. Bellovin wrote: Given the published list of bad ssh keys due to the Debian mistake (see http://metasploit.com/users/hdm/tools/debian-openssl/), should sshd be updated to contain a blacklist of those keys? I suspect that a Bloom filter would be quite compact and efficient. I've been having a similar thought. This also probably applies to SSL keys, given the rather lack attitude that most clients have about checking CRLS. -Ekr - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: blacklisting the bad ssh keys?
On Wed, May 14, 2008 at 07:52:58PM -0400, Steven M. Bellovin wrote: Given the published list of bad ssh keys due to the Debian mistake (see http://metasploit.com/users/hdm/tools/debian-openssl/), should sshd be updated to contain a blacklist of those keys? I suspect that a Bloom filter would be quite compact and efficient. As someone who is dealing with this operationally, we (SDSC) had already identified what Steve suggests as the desireable long-term solution. I would reword the requirement slightly to say that the capability of sshd should be to block use of any key specified by the adminstrator, not necessarily just the published blacklist. I think that's what Steve may have actually meant, but clarity is helpful. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: blacklisting the bad ssh keys?
On Wed, May 14, 2008 at 7:52 PM, Steven M. Bellovin [EMAIL PROTECTED] wrote: Given the published list of bad ssh keys due to the Debian mistake (see http://metasploit.com/users/hdm/tools/debian-openssl/), should sshd be updated to contain a blacklist of those keys? I suspect that a Bloom filter would be quite compact and efficient. Debian has two packages, one call openssh-blacklist (1024 DSA and 2048 bit keys RSA keys) ~4MB, and an unstable package openssh-blacklist-extra for non-default key sizes sizes that are simple lists of blacklisted keys. current source: http://ftp.debian.org/debian/pool/main/o/openssh-blacklist/openssh-blacklist_0.3.tar.gz from the README: - The blacklists are separate by architecture, type, and bit size. The contents are ordered by process pid, starting at PID 1 and ending at PID 32767. While generating entries, each possible process ID must be used. To help automate this, LD_PRELOAD is used to override the getpid() libc function. See generate-blacklist.sh for details. Note that the list is architecture-specific. - -Michael - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
