Re: Thanks to Debian OpenSSL developers

[CaT]

On Fri, May 16, 2008 at 07:47:31AM +0200, Yves-Alexis Perez wrote:
> On jeu, 2008-05-15 at 23:38 +0200, Steffen Schulz wrote:
> > or what its worth...I see 3.5 problems that accumulated into this
> > mess:
> > 
> > - OpenSSL is complex and critical but the code is little documented.
> >   Code pieces like the ones in question should have warning-labels
> >   printed all over them and a distinguished place and interface.
> 
> There was a #ifndef PURIFY just before the instruction commented by #if
> 0.

/* Uninitialised memory used intentionally to add entropy */

That, I believe, speaks volumes.

#ifndef PURIFY says very little.

Most, if not all languages provide the ability to enter in comments for
a reason.

-- 
  "Police noticed some rustling sounds from Linn's bottom area
  and on closer inspection a roll of cash was found protruding
  from Linn's anus, the full amount of cash taken in the robbery."
- 
http://www.smh.com.au/news/world/robber-hides-loot-up-his-booty/2008/05/09/1210131248617.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Thanks to Debian OpenSSL developers

[Yves-Alexis Perez]

On jeu, 2008-05-15 at 23:38 +0200, Steffen Schulz wrote:
> or what its worth...I see 3.5 problems that accumulated into this
> mess:
> 
> - OpenSSL is complex and critical but the code is little documented.
>   Code pieces like the ones in question should have warning-labels
>   printed all over them and a distinguished place and interface.

There was a #ifndef PURIFY just before the instruction commented by #if
0.

> - There are published algorithms for good PRNGs, no need to help
>   yourself with adding unintialized memory and praying the OS does a
>   good job already.

You talk about the first instruction which doesn't add entropy in every
case, but doesn't hurt (except the lintian warning).
The problem was with the second one, which added the entropy pool the
content of a now initialized buffer.

> - I don't know how much of an effort was made, to get the fix into
>   upstream, but it seems it wasn't enough. Not enough to get a
>   sufficient level of peer review. Instead it was decided to manage
> yet
>   another debian-specific patch.

There wasn't any fix, that's why.  The “#ifdef PURIFY” was there for a
reason.

This issue is complex, not much people understand it 100% correctly (I'm
not in those people), but please don't repeat wrong stuff seen here and
there.

Cheers,
-- 
Yves-Alexis


signature.asc
Description: This is a digitally signed message part

Re: ssh-vulnkey and authorized_keys

[Alex Samad]

On Thu, May 15, 2008 at 07:43:13PM -0400, Chris Adams wrote:
>
> On May 15, 2008, at 6:25 PM, Alex Samad wrote:
>> is there away to check x509 certs with these tools ?
>
> Yes - the wiki has one (http://wiki.debian.org/SSLkeys) but you might  
> prefer the openssl-blacklist package which Ubuntu prepared:
>
> https://launchpad.net/ubuntu/+source/openssl-blacklist/
>
> It runs out of the box on Debian and if you edit debian/control to  
> change the openssl dependency from the Ubuntu version  
> (0.9.8g-4ubuntu3.1) to the Debian version (0.9.8c-4etch3) you can dpkg- 
> buildpackage it and deploy it to multiple systems. I used it like this  
> to flush out Apache keys:
>
> sudo find /etc/ -xdev -type f -name \*.key -exec openssl-vulnkey {} \;

I have done this and check some .key files, but they show up as not
blacklisted, when I know they have been created in the last 12 months. I
thought I read some where the keys are different depending on weather it
was generated on a 32b or 64b system.

You might want to update the blacklist with the 64b generated keys

>
> Chris



-- 
Jack-and-Jill Party:
A Squire tradition; baby showers to which both men and
women friends are invited as opposed to only women.  Doubled
purchasing power of bisexual attendance brings gift values up to
Eisenhower-era standards.
-- Douglas Coupland, "Generation X: Tales for an Accelerated
   Culture"


signature.asc
Description: Digital signature

Re: [SECURITY] [DSA 1571-1] vulnerability of past SSH/SSL sessions

[Kevin Buhr]

Simon Valiquette <[EMAIL PROTECTED]> writes:
>
>   It seems that people are insisting quite a lot on the bad keys, but
> what worry me a lot more is that, apparently and very logically, past
> ssh connections and any SSL session keys are to be considered
> compromised.

After hastily reviewing the OpenSSH and OpenSSL code, my read is that
past SSH sessions *should* be considered compromised.  This would
appear to be true if *either* side was using a bad OpenSSL library at
time of connection, *regardless* of whether or not the RSA/DSA keys
involved were weak.

Obviously, independent verification of this state of affairs would be
helpful.  Any volunteers?



My assessment is detailed here:

The SSH session is secured entirely by a key generated through a
Diffie-Hellman key exchange independent of either side's RSA/DSA key.
(The server RSA/DSA key plays only a peripheral role in the exchange
and does not contribute to the level of security.)  During the D-H
exchange, the client:

C1. Generates a secret random number "x".
C2. Sends e = g^x mod p (where g and p are public) to the server.

The server:

S1. Generates a secret random number "y".
S2. Sends f = g^y mod p to the client, among other things.

Then, the client and server secure the session using the key: K = f^x
mod p = e^y mod p, as calculated by the client and server
respectively.

An attacker has "e" and "f" available in plaintext in the captured
exchange.  If *either* "e" or "f" was generated using a weak random
number ("x" or "y" respectively), the attacker can determine its value
and calculate the session key K (i.e., using "x" and "f" or using "y"
and "e", whichever pair is available).

Looking at the OpenSSH code, the random numbers "x" and "y" are
generated by dh_gen_key(), which uses the OpenSSL random number
function BN_rand() frequently seeded with RAND_add().  Ultimately,
these call ssleay_rand_bytes() and ssleay_rand_add() respectively, and
the latter is the buggy function that was failing to add anything
useful to the entropy pool.

> 3. If only one of the computer involved have a flawed openssl, but
> none have a vulnerable host key, is It still practical to break the
> session key?  If yes, about how long could It takes?

I think it requires precomputing only 65,536 numbers: g^x mod p for
each of the possible values of the bad random number "x".  After that,
an attacker can calculate "x" from "e" without further computation for
any captured exchange and determine the session key immediately from
"x" and "f".

-- 
Kevin Buhr <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Plans to deploy openssl-blacklist in Debian? (was: Re: ssh-vulnkey and authorized_keys)

[Felipe Augusto van de Wiel (faw)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 15-05-2008 20:43, Chris Adams wrote:
> 
> On May 15, 2008, at 6:25 PM, Alex Samad wrote:
>> is there away to check x509 certs with these tools ?
> 
> Yes - the wiki has one (http://wiki.debian.org/SSLkeys) but you might
> prefer the openssl-blacklist package which Ubuntu prepared:
> 
> https://launchpad.net/ubuntu/+source/openssl-blacklist/
> 
> It runs out of the box on Debian and if you edit debian/control to
> change the openssl dependency from the Ubuntu version
> (0.9.8g-4ubuntu3.1) to the Debian version (0.9.8c-4etch3) you can
> dpkg-buildpackage it and deploy it to multiple systems. I used it like
> this to flush out Apache keys:
> 
> sudo find /etc/ -xdev -type f -name \*.key -exec openssl-vulnkey {} \;

Speaking about that, are there plans to deploy
openssl-blacklist in Debian as an official package?

Kind regards,
- --
Felipe Augusto van de Wiel (faw)
"Debian. Freedom to code. Code to freedom!"
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFILNXdCjAO0JDlykYRCMq8AKDOaci6iTFlozcZDC3mH6cUjra6nQCeMNyx
9MMqc7tVaHshsSPDfT0WhzY=
=6MyD
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ssh-vulnkey and authorized_keys

[Chris Adams]

On May 15, 2008, at 6:25 PM, Alex Samad wrote:

is there away to check x509 certs with these tools ?


Yes - the wiki has one (http://wiki.debian.org/SSLkeys) but you might  
prefer the openssl-blacklist package which Ubuntu prepared:


https://launchpad.net/ubuntu/+source/openssl-blacklist/

It runs out of the box on Debian and if you edit debian/control to  
change the openssl dependency from the Ubuntu version  
(0.9.8g-4ubuntu3.1) to the Debian version (0.9.8c-4etch3) you can dpkg- 
buildpackage it and deploy it to multiple systems. I used it like this  
to flush out Apache keys:


sudo find /etc/ -xdev -type f -name \*.key -exec openssl-vulnkey {} \;

Chris

smime.p7s
Description: S/MIME cryptographic signature

Re: ssh-vulnkey and authorized_keys

[Alex Samad]

On Thu, May 15, 2008 at 09:52:10AM +0200, Vladislav Kurz wrote:
> Hello all,
> 
> thanks for the quick response to the SSL bug and for providing ssh-vulnkey 
> and 
> dokuwd.pl. SSH-VULNKEY produces funny output when processing authorized_keys 
> with additional options like from="host", command="something to do", 
> no-agent-forwarding, etc...

is there away to check x509 certs with these tools ?

> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 
> 

-- 
"I don't want to win? If that were the case, why the heck am I on the bus 
sixteen hours a day, shaking thousands of hands, giving hundreds of speeches, 
getting pillared in the press and cartoons and still staying on message to win?"

- George W. Bush
02/28/2000
as quoted in Newsweek


signature.asc
Description: Digital signature

Re: Thanks to Debian OpenSSL developers

[Steffen Schulz]

On 080515 at 22:20, Guido Hennecke wrote:
> I want to say: Thank you!

Me too, but mostly for how quick+open the situation was and is handled.

I especially like that sshd doesn't accept weak keys anymore. I think
similar efforts should be made to check for weak keys in other
locations and at least notify root, better yet move them to .broken

> Why? The Debian developers seems the only developers, who investigated
> the openssl code and not just used it. They found a strange thing in
> the OpenSSL Code, asked the OpenSSL people and after all, they removed
> the potentielly dangerous code peace.


For what its worth...I see 3.5 problems that accumulated into this mess:

- OpenSSL is complex and critical but the code is little documented.
  Code pieces like the ones in question should have warning-labels
  printed all over them and a distinguished place and interface.
- There are published algorithms for good PRNGs, no need to help
  yourself with adding unintialized memory and praying the OS does a
  good job already.
- I don't know how much of an effort was made, to get the fix into
  upstream, but it seems it wasn't enough. Not enough to get a
  sufficient level of peer review. Instead it was decided to manage yet
  another debian-specific patch.
- (In theory, for critical software, a testcase should have been
  written to verify the problem and its solution. Difficult to test
  randomness if you don't know what to search for, though. But maybe it
  would have been noticed this way that the function in question
  actually has a different interface.)


Anyways, thanks for the good incident response..


/Steffen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Thanks to Debian OpenSSL developers

[Guido Hennecke]

Hi list,

I want to say: Thank you!

Why? The Debian developers seems the only developers, who investigated
the openssl code and not just used it. They found a strange thing in
the OpenSSL Code, asked the OpenSSL people and after all, they removed
the potentielly dangerous code peace.

OK, this time, it was a mistake, but who but them have not just used he
code for theire packages?

In Germany we say: "Wer nichts macht, macht auch nichts verkehrt".

The bug is hard, in particular hard to fix the problems in big
enviroments. But the Debian developers have done the job, unfortunately
this time, it was a mistake.

Anyway, thanks to the Debian openssl developers, to think about things
and not just copy them!

Heads up!

Regards, Guido


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

pr1

[Felipe Tornvall N.]

-- 
[EMAIL PROTECTED]
http://www.linuxiso.cl


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: blacklist.RSA-1024 missing?

[Jan Tomasek]

Guido Hennecke wrote:

At 15.05.2008, Vineet Kumar wrote

I was able to find blacklist.RSA-1024 in Ubuntu's openssl-blacklist
package, and (fortunately) found that my 1024-bit RSA keys are in fact
not blacklisted.


On what hardware platform your keys were generated?

A friend tested to generate a key with PID 100 on x86-32bit and one on
x86-64bit and the keys differ. So I think, there are much more
blacklists needed than just one for 1024 bit and one for 2048.

You need one blacklist for every keytype and lenght and for every
hardware platform.


Yes amd64 produces different results than x86.

It also seams that amd64 produces two possible results for one PID. 
There is big disproportion in frequency between 1st and 2nd possible key 
but they both has to be considered as compromised. For example:


PIDhash  count
32765: 50743ddfce8d36705b3118e9efc29d4f: 2
32765: c3bb06a1b91e91b164c8aad38b173f9d: 208
32766: b436e0c7c42b604774d3579290efeb3d: 4
32766: bc30db19565011302374fc0dbe3645bb: 203
32767: 04c2eb648cdcf9969e1cdec2e05f9ec6: 200
32767: e98d38a7640f8e6b7d9ba1436c1ba4a6: 8

I tested about 10e6 keys on amd64 platform and got about 51e3 unique keys.

--
---
Jan Tomasek aka Semik
http://www.tomasek.cz/



signature.asc
Description: OpenPGP digital signature

Re: DSA-1571 and GSSAPI

[Micah Anderson]

* Joey Hess <[EMAIL PROTECTED]> [2008-05-15 09:57-0400]:
> Juha Jäykkä wrote:
> > Just count how many times you've used GPG over one of 
> > the weak links...
> 
> Zero!
> 
> Zero gpg invocations over network links!

 This is Just to Say

I have invoked
gpg
over the
network links

and which
was probably not
secure
in the least

Forgive me
it was convenient
so sweet
and so easy

micah

--- 
with apologies to william carlos williams


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: blacklist.RSA-1024 missing?

[Guido Hennecke]

Hallo Vineet,

At 15.05.2008, Vineet Kumar wrote
> I was able to find blacklist.RSA-1024 in Ubuntu's openssl-blacklist
> package, and (fortunately) found that my 1024-bit RSA keys are in fact
> not blacklisted.

On what hardware platform your keys were generated?

A friend tested to generate a key with PID 100 on x86-32bit and one on
x86-64bit and the keys differ. So I think, there are much more
blacklists needed than just one for 1024 bit and one for 2048.

You need one blacklist for every keytype and lenght and for every
hardware platform.

Regards, Guido


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: blacklist.RSA-1024 missing?

[Vineet Kumar]

* Vineet Kumar ([EMAIL PROTECTED]) [080515 10:39]:
> I was able to find blacklist.RSA-1024 in Ubuntu's openssl-blacklist
> package, and (fortunately) found that my 1024-bit RSA keys are in fact
> not blacklisted.

I guess this is probably because those keys were generated before
openssl 0.9.8c-1.  So in the usual case of people always going with the
default key length, I suppose 1024-bit RSA keys are generally not
vulnerable.  Still, someone could have generated a 1024-bit RSA key with
a vulnerable openssl, and so IMHO the blacklist file ought to be
included and used anyway.

good times,
Vineet
-- 
http://www.doorstop.net/
-- 
"Great spirits have always found violent opposition from mediocre minds. The
latter cannot understand it when a man does not thoughtlessly submit to
hereditary prejudices but honestly and courageously uses his intelligence."
-- Albert Einstein


signature.asc
Description: Digital signature

blacklist.RSA-1024 missing?

[Vineet Kumar]

I'm a bit concerned about the many 1024-bit RSA keys I have on my
system.  To be on the safe side, I'm removing them and replacing them
with newly-generated 2048-bit keys.

I wonder though, why there's no blacklist.RSA-1024 in the
openssh-blacklist package?  Running ssh-vulnkey tells me "Unknown (no
blacklist information)" for all of the 1024-bit RSA keys on my system.
This includes my host keys, meaning they weren't automatically replaced
by the new openssh-server's postinst.  (Perhaps the ssh-vulnkey -q test
should be strengthened to at least warn the user about "unknown" status
keys, rather than quietly allowing them?)

Vineet

-- 
http://www.doorstop.net/


signature.asc
Description: Digital signature

Re: blacklist.RSA-1024 missing?

[Vineet Kumar]

I was able to find blacklist.RSA-1024 in Ubuntu's openssl-blacklist
package, and (fortunately) found that my 1024-bit RSA keys are in fact
not blacklisted.

-- 
http://www.doorstop.net/


signature.asc
Description: Digital signature

Re: DSA-1571 and GSSAPI

[Joey Hess]

Juha Jäykkä wrote:
> Just count how many times you've used GPG over one of 
> the weak links...

Zero!

Zero gpg invocations over network links!

-- 
see shy jo, with apologies to countmail


signature.asc
Description: Digital signature

openssh: working exploit on bugtraq

[Christoph A.]

http://www.securityfocus.com/archive/1/492112/30/0/threaded


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DSA-1571 and GSSAPI

[Russ Allbery]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Keys based on user passwords should be fine.

However, I was just reminded that Kerberos password changes with Heimdal
similarly use OpenSSL to generate the session key, and therefore password
change sessions are subject to the same possible attack by brute-forcing
the random session key.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DSA-1571 and GSSAPI

[Russ Allbery]

Juha Jäykkä <[EMAIL PROTECTED]> writes:

> However, ever since we started using Heimdal, we have used GSSAPI
> authentication by default, which, to my understanding, does not rely on
> SSH host or user keys, but bases all its crypto on Kerberos. Does this
> mean data transmitted over GSSAPI-authenticated links is still secure?
> (Not that it matters much - there is no way of making sure the default
> (GSSAPI) was *always* used when transmitting sensitive data.

If you were using MIT Kerberos, you would be fine so far as I can tell
since MIT Kerberos has its own crypto layer and its own randomness
functions.  However, Heimdal uses OpenSSL as its crypto layer.  I have not
yet confirmed whether that includes using it for the generation of random
session keys, but that would be the conservative assumption.  Given that,
it may well be possible to brute-force the session key of any captured
GSSAPI-encrypted traffic and decrypt it retroactively.

If you're using Heimdal, you should also change all long-term random keys
(such as any key in generated keytab files) that were generated using the
vulnerable version of OpenSSL.  Keys based on user passwords should be
fine.

-- 
Russ Allbery ([EMAIL PROTECTED])   


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

DSA-1571 and GSSAPI

[Juha Jäykkä]

Hi all!

I was wondering how bad this actually is and it looks extremely horrible. In 
practice, all data transmitter over the wire for the last two years and be 
snooped upon (if someone has captured it - and the paranoid must assume 
someone has).

Trusting on the security of ssh, we have, for example, used ssh to transmit 
data from server to server, including such sensitive information as Heimdal 
database master key... Am I correct in assuming this key has been 
compromised? And along with it all the Heimdal passwords... 

However, ever since we started using Heimdal, we have used GSSAPI 
authentication by default, which, to my understanding, does not rely on SSH 
host or user keys, but bases all its crypto on Kerberos. Does this mean data 
transmitted over GSSAPI-authenticated links is still secure? (Not that it 
matters much - there is no way of making sure the default (GSSAPI) was 
*always* used when transmitting sensitive data.

By the way, if (since?) all the data ever transmitted over any ssh link 
secured by a weak key is compromised, it means that every single GPG 
passphrase (or any other password) ever transmitted over any of these links 
is also compromised. Just count how many times you've used GPG over one of 
the weak links...

Cheers (looks like a cheerful weekend to come indeed)...
Juha


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ssh-vulnkey and authorized_keys

[Noah Meyerhans]

On Thu, May 15, 2008 at 11:08:58AM +0300, Mikko Rapeli wrote:
> > It would be also helpful to print the line as dokuwd.pl does.
> > Is there any repository with newer versions of ssh-vulnkey or dokuwd.pl ?
> 
> Try the Ubuntu version which contains a fixed ssh-vulnkey (
> http://www.ubuntu.com/usn/usn-612-5 ):
> 
> "Matt Zimmerman discovered that entries in ~/.ssh/authorized_keys with
> options (such as "no-port-forwarding" or forced commands) were ignored
> by the new ssh-vulnkey tool introduced in OpenSSH (see USN-612-2). This
> could cause some compromised keys not to be listed in ssh-vulnkey's
> output."
> 
> I think, and hope, Debian openssh packages will be updated too.

Yes, expect it within hours.

noah



signature.asc
Description: Digital signature

Re: ssh-vulnkey and authorized_keys

[Mikko Rapeli]

On Thu, May 15, 2008 at 09:52:10AM +0200, Vladislav Kurz wrote:
> It would be also helpful to print the line as dokuwd.pl does.
> Is there any repository with newer versions of ssh-vulnkey or dokuwd.pl ?

Try the Ubuntu version which contains a fixed ssh-vulnkey (
http://www.ubuntu.com/usn/usn-612-5 ):

"Matt Zimmerman discovered that entries in ~/.ssh/authorized_keys with
options (such as "no-port-forwarding" or forced commands) were ignored
by the new ssh-vulnkey tool introduced in OpenSSH (see USN-612-2). This
could cause some compromised keys not to be listed in ssh-vulnkey's
output."

I think, and hope, Debian openssh packages will be updated too.

-Mikko


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

ssh-vulnkey and authorized_keys

[Vladislav Kurz]

Hello all,

thanks for the quick response to the SSL bug and for providing ssh-vulnkey and 
dokuwd.pl. SSH-VULNKEY produces funny output when processing authorized_keys 
with additional options like from="host", command="something to do", 
no-agent-forwarding, etc...

Instead of the file name it prints these extra options. It is hard to find 
such files then, especialy if they are not in regular user homes but used for 
special purposes (backups, monitoring) and located on unusual places.

It would be also helpful to print the line as dokuwd.pl does.
Is there any repository with newer versions of ssh-vulnkey or dokuwd.pl ?

-- 
Regards
Vladislav Kurz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DSA/DSS keys and DSA 1576-1/CVE-2008-0166.

[Mario 'BitKoenig' Holbe]

On Thu, May 15, 2008 at 10:37:37AM +1000, Andrew McGlashan wrote:
> Okay, if we updated (on stable):
> openssl_0.9.8c-4etch3_i386.deb
> libssl0.9.8_0.9.8c-4etch3_i386.deb
> Then re-generated all keys and certificates.

Then you are fine.

> Later we get these updates:
> openssh-server_1%3a4.3p2-9etch1_i386.deb
> openssh-client_1%3a4.3p2-9etch1_i386.deb
> So, do we need to re-generate keys and certs again now or will they be fine?

You don't need to re-generate keys again. The problem was in the libssl
package and was solved with libssl0.9.8_0.9.8c-4etch3_i386.deb. So, the
keys you generated after the libssl0.9.8 update are fine.

All the updated openssh-packages do regarding to this issue is trying to
ensure you don't use weak keys in the future (i.e. harden dependencies,
regenerate known-weak host keys and refuse known-weak keys for
authentication).

The way you have chosen was absolutely correct.


regards
   Mario
-- 
Computer games don't affect kids; I mean if Pac-Man affected us as kids,
we'd all be running around in darkened rooms, munching magic pills and
listening to repetitive electronic music.
  -- Kristian Wilson, Nintendo Inc, 1989


signature.asc
Description: Digital signature