Bugs item #451607, was opened at 2001-08-16 13:00 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=451607&group_id=5470
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barry A. Warsaw (bwarsaw) >Assigned to: Facundo Batista (facundobatista) Summary: SSL support in socket module needs tests Initial Comment: SSL support in the socket module should have a regression test, either in test_socket.py or in a separate test_ssl.py file. ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2007-03-30 21:45 Message: Logged In: YES user_id=752496 Originator: NO I'll try to test the socket to a (when available) local openssl server. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2006-04-12 05:01 Message: Logged In: YES user_id=21627 I don't think I will do anything about this anytime soon, so unassigning myself. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-10 05:51 Message: 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. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-10-10 05:39 Message: 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 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-10 05:13 Message: Logged In: YES user_id=21627 Things have changed a bit since: Solaris 9 has /dev/random. ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2002-10-09 15:25 Message: 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. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-11 16:39 Message: 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. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2001-10-11 15:44 Message: 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. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-11 15:32 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-09-03 12:12 Message: 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. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2001-08-28 10:53 Message: 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! :) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-08-28 02:58 Message: 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? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=451607&group_id=5470 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
