Here's the error I get while trying to connect:

[17/Sep/2003:09:30:42][17509.5126][-conn2-] Error: nsopenssl: error -1/1 during SSL handshake

I'm on Debian stable:

# apt-cache showpkg openssl
0.9.6c-2.woody.3(/var/lib/apt/lists/security.debian.org_dists_stable_updates_main_binary-i386_Packages)(/var/lib/dpkg/status)
0.9.6c-2(/var/lib/apt/lists/debian.orst.edu_debian_dists_stable_main_binary-i386_Packages)(/var/lib/apt/lists/linux.csua.berkeley.edu_debian_dists_stable_main_binary-i386_Packages)

nsopenssl 2.1

Any suggestions? I hope this isn't related to the recent OpenSSH vulnerability...

I hope to get this up soon... my company is understandibly vexed. :(

According to scottg, the new openssl libs have changed the way they report if they are compiled with threads or not. Removing the ifdefs that check for threads is a temporary workaround. (Thanks to CR Oldham for this info.)

I'm trying to recompile nsopenssl now and hope that fixes the problem.

I need to double check that again but they are telling me they haven't done it and at least for sure not within a few month of the time when we started to get these errors.

So perhaps it's that some folks are upgrading OpenSSL at the same time they upgraded OpenSSH, and then breaking OpenSSL thread-safety due to silly header file and build changes in OpenSSL?

So I'm damned if I do and damned if I don't?

I have to compile it from source. That's easy, but it sucks because I lose the easy Debian-style upgrades..

I'm running RH8. When I tried to upgrade openssh, it required a newer version of openssl. So if RPM's are used in the upgrade, openssl will be upgraded to get the new openssh. Otherwise, you can get the patch for openssh and recompile that. Here is the openssh patch.

Considering how many packages depend on openssl, this is probably the easiest way to upgrade.

The openssl-0.9.7b CHANGES file has this to say:

Changes between 0.9.7a and 0.9.7b  [10 Apr 2003]   

 *) Turn on RSA blinding by default in the default implementation 
    to avoid a timing attack. Applications that don't want it can call 
    RSA_blinding_off() or use the new flag RSA_FLAG_NO_BLINDING. 
    They would be ill-advised to do so in most cases. 
    [Ben Laurie, Steve Henson, Geoff Thorpe, Bodo Moeller] 

 *) Change RSA blinding code so that it works when the PRNG is not 
    seeded (in this case, the secret RSA exponent is abused as 
    an unpredictable seed -- if it is not unpredictable, there 
    is no point in blinding anyway).  Make RSA blinding thread-safe 
    by remembering the creator's thread ID in rsa->blinding and 
    having all other threads use local one-time blinding factors 
    (this requires more computation than sharing rsa->blinding, but 
    avoids excessive locking; and if an RSA object is not shared 
    between threads, blinding will still be very fast). 
    [Bodo Moeller]

If that's true, and it works, then no one should be seeing any thread safety problems. Thoughts?

I've had a nsopenssl 2.1a dynamically linked against openssl-0.9.7b and running on a Dev server with no problems for a week or so now, but it hardly gets any load at all so that doesn't prove much.

Bruno didn't say exactly what version he was using, but the Red Hat link he gave seems to show that the latest updated packages for all consumer Red Hat distributions prior to Red Hat 9.0 are using an OpenSSL older than 0.9.7x. Which is suspicious, as it's possible that RH backported the RSA blinding security patch but not the thread-safety fix.

So the fix should be simple, just upgrade to 0.9.7b. Note that Scott Goodwin says that nsopenssl 2.1a requires OpenSSL 0.9.7x or later anyway.

But in this case, the Right Way would be to build your own OpenSSL 0.9.7b binary package for Debian Stable. Probably using the same source package that's in testing now, you just need to rebuild with the older Stable tool chain.

Personally, I haven't gotten around to actually doing that sort of thing yet, but my understanding is it's not bad. At least, several people here do that sort of thing, and I've read (on the Beowulf mailing list, other places) that it's not unusual for admins of large clusters to choose to rebuild most of their binary packages from source packages as a matter of course.

For Debian though, I bet someone has already done it, and if you like can just add a line to your /etc/apt/sources.list and download their binary package.