Greetings, I would like to be able to set the cipher list when creating an SSL connection. It appears that the current SSL module doesn't provide this functionality. The attached patch (against trunk) adds this ability to SSLSocket. Thank you, --Chris PS: Please reply directly to me, as I'm not subscribed to this list. Index: Python-2.7/Lib/ssl.py =================================================================== --- Python-2.7/Lib/ssl.py (revision 74703) +++ Python-2.7/Lib/ssl.py (working copy) @@ -88,7 +88,7 @@ server_side=False, cert_reqs=CERT_NONE, ssl_version=PROTOCOL_SSLv23, ca_certs=None, do_handshake_on_connect=True, - suppress_ragged_eofs=True): + suppress_ragged_eofs=True, cipher_list=None): socket.__init__(self, _sock=sock._sock) # the initializer for socket trashes the methods (tsk, tsk), so... self.send = lambda data, flags=0: SSLSocket.send(self, data, flags) @@ -110,7 +110,8 @@ # yes, create the SSL object self._sslobj = _ssl.sslwrap(self._sock, server_side, keyfile, certfile, - cert_reqs, ssl_version, ca_certs) + cert_reqs, ssl_version, + ca_certs, cipher_list) if do_handshake_on_connect: timeout = self.gettimeout() try: Index: Python-2.7/Modules/_ssl.c =================================================================== --- Python-2.7/Modules/_ssl.c (revision 74703) +++ Python-2.7/Modules/_ssl.c (working copy) @@ -261,7 +261,8 @@ enum py_ssl_server_or_client socket_type, enum py_ssl_cert_requirements certreq, enum py_ssl_version proto_version, - char *cacerts_file) + char *cacerts_file, + char *cipher_list) { PySSLObject *self; char *errstr = NULL; @@ -366,6 +367,9 @@ SSL_CTX_set_verify(self->ctx, verification_mode, NULL); /* set verify lvl */ + if (cipher_list) + SSL_CTX_set_cipher_list(self->ctx, cipher_list); + PySSL_BEGIN_ALLOW_THREADS self->ssl = SSL_new(self->ctx); /* New ssl struct */ PySSL_END_ALLOW_THREADS @@ -407,14 +411,17 @@ char *key_file = NULL; char *cert_file = NULL; char *cacerts_file = NULL; + char *cipher_list = NULL; - if (!PyArg_ParseTuple(args, "O!i|zziiz:sslwrap", + + if (!PyArg_ParseTuple(args, "O!i|zziizz:sslwrap", PySocketModule.Sock_Type, &Sock, &server_side, &key_file, &cert_file, &verification_mode, &protocol, - &cacerts_file)) + &cacerts_file, + &cipher_list)) return NULL; /* @@ -427,12 +434,12 @@ return (PyObject *) newPySSLObject(Sock, key_file, cert_file, server_side, verification_mode, - protocol, cacerts_file); + protocol, cacerts_file, cipher_list); } PyDoc_STRVAR(ssl_doc, "sslwrap(socket, server_side, [keyfile, certfile, certs_mode, protocol,\n" -" cacertsfile]) -> sslobject"); +" cacertsfile, cipherlist]) -> sslobject"); /* SSL object methods */
Hello Chris, Can you post your patch to the Python bug tracker please - http://bugs.python.org Patches posted to this list tend to get lost... Thanks Michael Chris Frantz wrote:
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog
Done. Attached to Issue 3597, which is a similar request to mine. Best Regards, --Chris
Bill, I agree that it's usually better to let the SSL implementation pick the ciphers. I have a certain device that I'd like to talk to that is running on an underpowered embedded CPU. When I let OpenSSL pick the ciphers, it chooses something like EDH-RSA-AES-SHA and takes about 3.5 seconds to finish the handshake. If I can restrict the cipher list to RSA-RC4-SHA I can reduce the handshake time to less than a second and improve the throughput of any bulk data transfer over the connection. --Chris On Thu, Sep 10, 2009 at 12:09 PM, Bill Janssen<janssen@parc.com> wrote:
Chris, OK, seems reasonable. Thanks. In the near term, can you do this with M2Crypto or PyOpenSSL? When I started this update in 2007, we were trying to keep the API simple to avoid confusing people and avoid competition with the two full-fledged toolkits out there. But I don't see any real reason not to extend the API a bit. Bill Chris Frantz <frantzcj@gmail.com> wrote:
Bill Janssen wrote:
Speaking as the M2Crypto maintainer, I don't mind the stdlib competing with M2Crypto/getting better at SSL. In fact, I would actually like to see the stdlib SSL implementation getting good enough so that people would not need M2Crypto for SSL (except maybe in special circumstances). There is much M2Crypto does besides SSL so this wouldn't even obsolete it. One of the main things IMO missing from stdlib SSL implementation is hostname checking by default (with override option), but I know you and I have different opinions on this. I would be happy to provide patches against the stdlib SSL implementation for some things M2Crypto does that the stdlib SSL module is missing if we could agree on the features/design first. Simple is good, but I'd like the defaults to be secure and commonly overridden things to be overrideable. -- Heikki Toivonen
Heikki, I'm OK with this, too. would you like to propose an extended API for the SSL module? That would give us a starting point to talk about. This should probably be a PEP, just for the sake of writing things down. As you say, the hostname checking feature seems to me possibly appropriate for some application protocols, though it's made the use of HTTPS as a transport-level protocol unnecessarily confusing and buggy. I don't see putting that into the SSL module as a default, but perhaps a utility function in that module, to check a server-side cert against a hostname, is a good idea. Bill Heikki Toivonen <htoivonen@spikesource.com> wrote:
Yes, my patch implements hostname checking in httplib (although I haven't had time to do much testing). I also made the documentation changes, but have not yet created any test cases since there really aren't any HTTPS test cases in the test_httplib.py file (which is probably another issue that needs attention). We had talked a month or two back about including hostname checking in the ssl module, but the consensus seemed to be that it doesn't belong there. Personally, I would like to see it make it into the ssl module, as that would mean all the modules that use the ssl module (httplib, etc.) wouldn't have to write their own (and it isn't very straightforward... lots of different RFCs involved). Just my 2 cents. -Devin On Thu, Sep 10, 2009 at 3:17 PM, Jesse Noller <jnoller@gmail.com> wrote:
Hello Chris, Can you post your patch to the Python bug tracker please - http://bugs.python.org Patches posted to this list tend to get lost... Thanks Michael Chris Frantz wrote:
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog
Done. Attached to Issue 3597, which is a similar request to mine. Best Regards, --Chris
Bill, I agree that it's usually better to let the SSL implementation pick the ciphers. I have a certain device that I'd like to talk to that is running on an underpowered embedded CPU. When I let OpenSSL pick the ciphers, it chooses something like EDH-RSA-AES-SHA and takes about 3.5 seconds to finish the handshake. If I can restrict the cipher list to RSA-RC4-SHA I can reduce the handshake time to less than a second and improve the throughput of any bulk data transfer over the connection. --Chris On Thu, Sep 10, 2009 at 12:09 PM, Bill Janssen<janssen@parc.com> wrote:
Chris, OK, seems reasonable. Thanks. In the near term, can you do this with M2Crypto or PyOpenSSL? When I started this update in 2007, we were trying to keep the API simple to avoid confusing people and avoid competition with the two full-fledged toolkits out there. But I don't see any real reason not to extend the API a bit. Bill Chris Frantz <frantzcj@gmail.com> wrote:
Bill Janssen wrote:
Speaking as the M2Crypto maintainer, I don't mind the stdlib competing with M2Crypto/getting better at SSL. In fact, I would actually like to see the stdlib SSL implementation getting good enough so that people would not need M2Crypto for SSL (except maybe in special circumstances). There is much M2Crypto does besides SSL so this wouldn't even obsolete it. One of the main things IMO missing from stdlib SSL implementation is hostname checking by default (with override option), but I know you and I have different opinions on this. I would be happy to provide patches against the stdlib SSL implementation for some things M2Crypto does that the stdlib SSL module is missing if we could agree on the features/design first. Simple is good, but I'd like the defaults to be secure and commonly overridden things to be overrideable. -- Heikki Toivonen
Heikki, I'm OK with this, too. would you like to propose an extended API for the SSL module? That would give us a starting point to talk about. This should probably be a PEP, just for the sake of writing things down. As you say, the hostname checking feature seems to me possibly appropriate for some application protocols, though it's made the use of HTTPS as a transport-level protocol unnecessarily confusing and buggy. I don't see putting that into the SSL module as a default, but perhaps a utility function in that module, to check a server-side cert against a hostname, is a good idea. Bill Heikki Toivonen <htoivonen@spikesource.com> wrote:
Yes, my patch implements hostname checking in httplib (although I haven't had time to do much testing). I also made the documentation changes, but have not yet created any test cases since there really aren't any HTTPS test cases in the test_httplib.py file (which is probably another issue that needs attention). We had talked a month or two back about including hostname checking in the ssl module, but the consensus seemed to be that it doesn't belong there. Personally, I would like to see it make it into the ssl module, as that would mean all the modules that use the ssl module (httplib, etc.) wouldn't have to write their own (and it isn't very straightforward... lots of different RFCs involved). Just my 2 cents. -Devin On Thu, Sep 10, 2009 at 3:17 PM, Jesse Noller <jnoller@gmail.com> wrote:
participants (6)
-
Bill Janssen -
Chris Frantz -
Devin Cook -
Heikki Toivonen -
Jesse Noller -
Michael Foord