Bugs item #232460, was opened at 2001-02-14 19:14
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232460&group_id=5470
Category: Extension Modules
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: David M. Beazley (beazley)
Assigned to: Jeremy Hylton (jhylton)
Summary: SSL Support (Apparently) Broken on Solaris
Initial Comment:
I have spent about 10 hours banging on this with no luck.
Python : Python-2.0
Platform : SPARC Solaris 2.8
Compiler : Sun Workshop Pro v5.0, gcc-2.95-2
OpenSSL : openssl-0.9.6 and 0.9.5.
Problem -
All attempts to open a SSL connection result in an "SSL_connect error".
I have tried various combinations of keys and certificates.
I have looked at the Python source code extensively and added debugging to try and get more information. I have run the system using the openssl s_client and s_server testing tools. I have recompiled everything in various configurations of versions and compilers. In all cases, the same error is generated.
That said, has *ANYBODY* gotten this to work on Solaris?
If so, do you have any details that can be shared?
Cheers,
Dave
P.S. I will submit a patch if I can ever get this to actually work.
----------------------------------------------------------------------
>Comment By: Jeremy Hylton (jhylton)
Date: 2001-10-16 09:28
Message:
Logged In: YES
user_id=31392
I think we'll add some RAND_xxx() methods to the Python API
to allow people to seed the prng themselves. I'd like to
have some mechanism in place to do the seeding autmatically,
but I don't think it makes a lot of sense for us to try and
maintain this in Python.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2001-10-11 12:34
Message:
Logged In: YES
user_id=21627
On PRNG problems, it seems we have two options:
- wait for, then require OpenSSL 0.9.7. It will look for a
prngd socket in default locations (/var/run/egd-pool,
/dev/egd-pool, /etc/egd-pool and /etc/entropy); then require
administrators to set up OpenSSL that it indeed finds a
prngd in these locations when needed.
- expose RAND_add. Exposing any other of the interfaces is
pointless; on our installation, prngd runs on localhost:708
instead of a Unix domain socket, and none of the other
interfaces could use such a configuration. On top of
RAND_add, we could communicate with prngd ourselves, e.g. by
using the RANDFILE environment variable.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2001-10-11 10:57
Message:
Logged In: YES
user_id=21627
Running httplib.py now crashes with
Traceback (most recent call last):
File "Lib/httplib.py", line 867, in ?
test()
File "Lib/httplib.py", line 853, in test
hs.connect(host)
File "Lib/httplib.py", line 698, in connect
self._conn.connect()
File "Lib/httplib.py", line 653, in connect
ssl = socket.ssl(realsock, self.key_file, self.cert_file)
socket.sslerror: (1, 'error:24064064:random number
generator:SSLEAY_RAND_BYTES:PRNG not seeded')
Not sure how this should be fixed, though. We use prngd
here. To configure OpenSSH, I had to give prngd parameters
to OpenSSH (i.e. that it should use prngd, and what the port
number is).
On testing certificates: It might be sufficient to generate
a self-signed one, and distribute that as part of the test
suite. Of course, you need to write server and client code
to use the appropriate files.
----------------------------------------------------------------------
Comment By: Jeremy Hylton (jhylton)
Date: 2001-10-11 10:34
Message:
Logged In: YES
user_id=31392
I've made some recent changes that affect SSL_connect(),
although the primary change is to improve the error
messages. Dave and Martin, can you check the current code
on Solaris? If it still fails, we'll at least get a clearer
error message.
BTW, does anyone have suggestions for how to test the code
with key and cert files?
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2001-07-28 10:39
Message:
Logged In: YES
user_id=21627
I still have the same problem, both on my own installation
(both with 2.1.1, and with the CVS), as well as on
cf.sf.net:/home/users/loewis/Python-2.1.1/python
(you need to set LD_LIBRARY_PATH=/usr/local/ssl/lib to use
this one).
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-14 20:30
Message:
Logged In: YES
user_id=6380
David, is this still broken?
On the SourceForge compile farm I can use SSL just fine.
Check out my directory
/home/users/gvanrossum/Python-2.1-solaris on
cf.sourceforge.net.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 11:55
Message:
Logged In: YES
user_id=6380
So, David, you still interested in this?
----------------------------------------------------------------------
Comment By: A.M. Kuchling (akuchling)
Date: 2001-03-20 07:58
Message:
Logged In: YES
user_id=11375
Moshe checked in patch #405101 to the CVS tree. David, can
you update and see if it fixed the problem for you?
----------------------------------------------------------------------
Comment By: Moshe Zadka (moshez)
Date: 2001-03-18 02:30
Message:
Logged In: YES
user_id=11645
I just want to me-too Neil, since I submitted the original
patch. I think it *did* fix problems on Solaris, as long
as the user is running EGD and set up RANDFILE env. variable
properly. Otherwise, you won't be getting connect errors,
but a warning from Python about using a non-secure way to
generate seed.
(For the record, the problem is that Solaris doesn't have a
/dev/urandom like Linux does)
----------------------------------------------------------------------
Comment By: Neil Schemenauer (nascheme)
Date: 2001-03-02 07:49
Message:
Logged In: YES
user_id=35752
It looks like patch "[ #405101 ] Add Random Seeding to
OpenSSL" might fix this. Assigning to Andrew since he
is assigned that patch too.
----------------------------------------------------------------------
Comment By: David M. Beazley (beazley)
Date: 2001-02-15 06:12
Message:
A followup on this bug.... It appears that Python is not properly
seeding the OpenSSL random number generator when it creates a secure
socket. This, in turn, causes the SSL_connect() function to fail due
to improper random number seeding (although the error wasn't
obvious--at least not to me). This is also due to an apparent
"feature" of Solaris not providing a usable /dev/random device.
A simple fix is to modify init_socket() in socketmodule.c to include
a call to RAND_seed() like this:
#ifdef USE_SSL
SSL_load_error_strings();
SSLeay_add_ssl_algorithms();
/* Sick hack for Solaris */
{
char bogus[64];
/* Fill in bogus with some random noise */
...
RAND_seed(bogus, 64);
}
...
#endif
Presumably one would need to think about the randomness actually
passed to RAND_seed() (I have done nothing above).
Here are related comments from the OpenSSL FAQ:
"Cryptographic software needs a source of unpredictable data to work
correctly. Many open source operating systems provide a "randomness
device" that serves this purpose. On other systems, applications have
to call the RAND_add() or RAND_seed() function with appropriate data
before generating keys or performing public key encryption.
Some broken applications do not do this. As of version
0.9.5, the OpenSSL functions that need randomness report an error if
the random number generator has not been seeded with at least 128 bits of
randomness. If this error occurs, please contact the author of the
application you are using. It is likely that it never worked
correctly. OpenSSL 0.9.5 and later make the error visible by refusing
to perform potentially insecure encryption."
Python-2.1a2 does not appear to include a fix, but I can't test it to
find out (since 2.1a2 doesn't compile on my machine).
Cheers,
Dave
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232460&group_id=5470
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4