Mailinglist Archive: opensuse-bugs (7528 mails)

< Previous Next >
[Bug 393186] Detecting weak keys following the Debian OpenSSL desaster
  • From: bugzilla_noreply@xxxxxxxxxx
  • Date: Fri, 1 Aug 2008 06:32:59 -0600 (MDT)
  • Message-id: <20080801123259.CCC25245391@xxxxxxxxxxxxxxxxxxxxxx>

User meissner@xxxxxxxxxx added comment

--- Comment #42 from Marcus Meissner <meissner@xxxxxxxxxx> 2008-08-01 06:32:59
MDT ---
Date: Wed, 04 Jun 2008 11:14:12 -0400
From: Nathanael Hoyle <nhoyle@xxxxxxxxxxxxx>
To: oss-security@xxxxxxxxxxxxxxxxxx
Subject: Re: [oss-security] OpenSSH key blacklisting

Tim Brown wrote:
Answering comments in line as applicable...
Alright, doing same...


On Wednesday 28 May 2008 15:43:39 Nathanael Hoyle wrote:

My first thought here has to do with the issues involved in key
management. I'm not sure that a certifying/key-issuing central ($$$)
authority with the ability to do revocations is the right model for most
OSS users. Think SSL certificates and Verisign... I believe many OSS
projects would not wish to incur this expense. Then you have
self-signed certificates (and/or self-generated key pairs) and
PGP/GPG-style web of trust things... all quite complicated and somewhat

The idea of CAs as a revenue generating model is IMO, something akin to snake

To clarify, do you mean that the business model of commercial CAs is
that of snake oil vendors, or that my statement, which implies that CAs
necessarily be commercial is snake oil? I realize that not all CAs are
commercial, but there are very few non-commercial ones which are
well-recognized and whom could reasonably (IMO) be expected to have no
interest/bias beyond ensuring that their key issuance product was solid.

Certaily non-profit and private CAs exist and still provide value in
certifying individuals and hosts. Why for example, could some way not be
found to make it easier for host keys generated by a particular
version/package of ssh-keygen to be revoked rather than employing the
blacklist solution currently on the table. Moreover, why couldn't such a
solution allow for alternative revocation source.

A typical public key looks something like:

id-rsa really-long-string-of-base64-encoded-key-here hostname

Note that there is not a 'signature' from the version of ssh-keygen
which created this key. I do not see any method of determining this
information client-side when presented with a key upon connection. In
the absence of this meta-information being available to the remote
client, it cannot be used as the basis for revocation or acceptance.

This is the sort of thing which could be addressed through an extension
to the current RFC to mandate a comment or header field in both the
keyfile and the client negotiation protocol which indicated the specific
package and revision which generated the key. Obviously, in order for
this to be useful, the RFC would have to mandate a standardized format
for version strings so that they could be readily compared (i.e.
versions <= X are known to be vulnerable). The concern introduced by
such a mechanism is information disclosure. If I were acting the role
of the script kiddie, a host becomes MUCH more interesting if it's
client negotiation reveals that it's key-pair was generated using a
known-vulnerable package revision. This could clue me in to the fact
that a host had the reduced-keyspace issue like the recent debian one,
or a similar one which would allow me to concentrate and focus my
attack. That's bad news. It is probably sufficiently bad news as to
bar adoption of such a mechanism. Note that putting a revision stamp in
a keyfile could still allow an administrator to check hosts on his/her
network to look for potentially compromised keys, without disclosing the
information via the network protocol. Of course that means it is
useless to the client.

As to the second half of your question, about revocation source, I
believe it makes good sense for the party which issued the ssh package
and digitally signed it to be able to 'revoke' the package as insecure.
For any other party to be authorized to do this, returns to the issue
of a central CA.

In such a circumstance,
the ssh client could be configured (at both a host and user level) to support
both warning and/or preventing connections to hosts with revoked keys.


The specific case is somewhat unusual, because it is not an instance
where a single host/site needed to revoke a previously valid key because
of compromise (although that case is not properly addressed, currently),
but one where many hosts, including those to which one has never before
connected, might have keys which fall within the predictable space, and
therefore be effectively compromised.

Exactly, and the blacklist solution fails to adequately address these use

In the general case, certainly. In the specific case, revoking each of
the possibly generated keys from the reduced seed space does address the
case-in-point issue.

It is interesting to note that a typical 'web-of-trust' implementation
would not properly handle this type of situation in a reliable manner,
highlighting the need for a central key authority. The question then
becomes, who in the OSS community would be considered a universally
trusted entity to perform key registration and revocation for SSH key
pairs, and how is such an entity funded?

Surely, the owner of the system and the owner of the client should both be
able to make such choices by the configurations they apply to their systems.

I wish that I could agree completely with you here, but I don't. In an
'ideal' world, absolutely. Probably those who are actively interested
in auditing and maintaining the security of their systems could do so
readily. That fact may be sufficient to drive the implementation of
such an 'optional' extension. However, the reason debian got into the
mess they did in the first place with this was specifically because they
were trying to remove responsibility from the can't-be-bothered users
for configuration. At one point, nearly all ssh key generation systems
required the user the type keys 'at random' on the keyboard, and/or to
move the mouse to generate an entropy pool for a seed value for key
generation. Because debian performs key-generation on first boot in
most cases, that early in the startup there might not be sufficient
entropy in the network traffic for utility. I guess they found that
users were either incapable of or disinclined to participate in the key
generation process. These same users would not participate in
configuring trusted certifying/revoking authorities for keypairs either.
Thus the question becomes one of sufficiently acceptable default values
for a distro vendor to pre-set. I am hard pressed to think of external
non-commercial entities which could be entrusted with this task reliably
enough that I would want to make them the default in a distro I
packaged. I would welcome thoughts on that.

Also, how does on resolve the
apparent privacy concerns over querying such a central repository with a
public key signature to check for revocation prior to usage? For my
own purposes, I would not want to pass the key in question along...
which means that perhaps an rsync-style source which could be
synchronized to a local revoked key list is the proper implementation,
avoiding disclosing which keys you were specifically interested in to
the central key authority.

As I say, the owner of the system and the owner of the client should both be
able to configure their own components. Therefore they would be in a
position to make their own judgements on the trustworthiness or otherwise of
a particular CA. Much as already happens with for example DNS blackholes for

The DNS blackholes for email is a very interesting case for comparison
purposes. I find such to be indispensable for managing/controlling spam
on an email network. As an implementation, this makes good sense. As
per my above comments however, I fear that the benefits of such an
implementation could be limited to the users who knew/cared and that
this would not readily be pre-packageable for the masses.

It's definitely a question worth pursuing, but I don't think it will be
particularly trivial to solve across the community.

I don't doubt it, but if noone poses the question, we'll never find out if
there is anyone smart enough to solve it. As such, I leave it for the reader
to figure out if the problem has a solution.




Configure bugmail:
------- You are receiving this mail because: -------
You are on the CC list for the bug.

< Previous Next >