This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: SSL support in socket module needs tests
Type: Stage:
Components: Extension Modules Versions:
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: facundobatista Nosy List: barry, facundobatista, lkcl, loewis, nobody, phr
Priority: normal Keywords:

Created on 2001-08-16 16:00 by barry, last changed 2022-04-10 16:04 by admin. This issue is now closed.

Messages (14)
msg5978 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2001-08-16 16:00
SSL support in the socket module should have a
regression test, either in test_socket.py or in a
separate test_ssl.py file.
msg5979 - (view) Author: Nobody/Anonymous (nobody) Date: 2001-08-28 05:58
Logged In: NO 

I may be able to help with this.  I'm fairly familiar with
SSL in general, though not about the socket module.
What's needed?
msg5980 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2001-08-28 13:53
Logged In: YES 
user_id=12800

There is currently an extremely minimal test in
test_socket_ssl.py, but it is fairly bogus because it
requires an outside network connection.  The only test there
just tries to hit https://sf.net.

Ideally, there would be a set of regression tests that only
required local resources.  I.e. it would set up a local SSL
server, then do connects to it to test the various SSL
features in socket module.

Take a look at test_socket_ssl.py in the 2.2 cvs and see if
you can improve matters.  From what I understand, the tricky
part is generating all the necessary certificates, etc.

Also, if you intend to work on this, please log in to SF to
continue this dialog so we know who we're talking to! :)
msg5981 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2001-09-03 15:12
Logged In: YES 
user_id=21627

I'd suggest an approach similar to the one in test_socket,
i.e. test only if can_fork. As for the certificates: I think
they should be generated in advance and included into the
test suite.
msg5982 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2001-10-11 18:32
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.
msg5983 - (view) Author: paul rubin (phr) Date: 2001-10-11 18:44
Logged In: YES 
user_id=72053

1) I think it's dangerous to run a prngd on an IP socket
instead of a Unix domain socket.  It creates the possibility
of (either accidentally or by ignorance) running OpenSSL
on a separate host from the prngd, making the random numbers
vulnerable to network sniffing.  That's bad--the numbers
are cryptographic secrets and should not be exposed.

2) It's simple to set up a local SSL server with the
command line openssl s_server option.  

3) I'm not crazy about the whole prngd concept.  I haven't
looked at the CHILL interface yet, but if it's possible
to abandon prngd and get random numbers through CHILL,
that might be best.  On Linux, /dev/urandom should be used.
msg5984 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2001-10-11 19:39
Logged In: YES 
user_id=21627

1) When prngd runs on a TCP socket, it still won't accept
connections from remote systems.
2) Sure, but would that simplify testing?
3) My comment was actually directed at bug #232460, which is
Solaris specific: Solaris does not have a /dev/[u]random, so
prngd is the only choice. I agree that using /dev/random is
better if available. Furthermore, OpenSSL will already make
this choice for you at installation time.
msg5985 - (view) Author: Luke Kenneth Casson Leighton (lkcl) Date: 2002-10-09 18:25
Logged In: YES 
user_id=80200

yes it definitely does because on solaris, which doesn't have a
/dev/random, urlretrieve fails to operate because openssl cannot
get enough entropy for the PRNG in order to make the SSL
connection.
msg5986 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2002-10-10 08:13
Logged In: YES 
user_id=21627

Things have changed a bit since: Solaris 9 has /dev/random.
msg5987 - (view) Author: Nobody/Anonymous (nobody) Date: 2002-10-10 08:39
Logged In: NO 

Using /dev/random for a user level application is
inappropriate.  Use /dev/urandom instead.
/dev/random actually tries to suck entropy out of the
entropy pool, and blocks if there's
not enough.  It's best to make sure there's sufficient
initial entropy in the pool, then use
/dev/urandom which uses the existing entropy to seed a
CPRNG.  Assuming the CPRNG
is properly designed, /dev/urandom should be fine for
OpenSSL, since if someone magically
breaks the cryptography in the CPRNG then they can probably
break OpenSSL's cryptography
the same way.  --phr
msg5988 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2002-10-10 08:51
Logged In: YES 
user_id=21627

I don't think this is relevant here: OpenSSL uses whatever
device it uses; we need not to concern ourselves with
OpenSSL's choice.
msg5989 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2006-04-12 08:01
Logged In: YES 
user_id=21627

I don't think I will do anything about this anytime soon, so
unassigning myself.
msg5990 - (view) Author: Facundo Batista (facundobatista) * (Python committer) Date: 2007-03-31 00:45
I'll try to test the socket to a (when available) local openssl server.
msg5991 - (view) Author: Facundo Batista (facundobatista) * (Python committer) Date: 2007-04-22 02:55
I implemented local tests in test_socket_ssl. If present, it starts openssl and then tests against it.

All the SSL methods are tested.

Feel free to add more complex SSL tests, all infrastructure is now in place.
History
Date User Action Args
2022-04-10 16:04:19adminsetgithub: 34979
2001-08-16 16:00:14barrycreate