| msg151927 - (view) |
Author: Nathanael Noblet (Nathanael.Noblet) |
Date: 2012-01-24 23:02 |
| If I wanted to create a HTTPS connection to a xmlrpc server *and* validate its certificate, I need to override the HTTPSConnection and SafeTransport objects. However it seems like they could easily support both methods. At least it seems to work both ways for me |
|
|
| msg152266 - (view) |
Author: Senthil Kumaran (orsenthil) *  |
Date: 2012-01-29 22:16 |
| Thanks for submitting the patch. Couple of comments. 1. This is a new feature, so the patch should be addressed against 3.x. 2. The patch lacks tests and documentation and hence it is not complete. You could take a look at http/client.py or ssl.py (with test_ssl.py) for for passing the key and cert from the client. Antoine - I fail to recollect, but is there any reason for the clients in the stdlib are not carrying a ca_file and doing a certificate validation of the server connection? Is it required (or a good idea) ? |
|
|
| msg152269 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2012-01-29 22:30 |
| > Antoine - I fail to recollect, but is there any reason for the clients > in the stdlib are not carrying a ca_file and doing a certificate > validation of the server connection? Well, if you are a security expert you can volunteer to maintain a trusted certificates' file in the Python repository :) I think nobody else amongst us is qualified. |
|
|
| msg152274 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2012-01-29 22:48 |
| For 3.x, xmlrpc.client should just pass-through the SSL context. Since the code to do so will be quite different from the current patch, I'm tempted to close this issue as rejected, unless Nathanael indicates that he would like to redo the patch for 3.x; this issue could then be recycled for that. orsenthil: I don't fully understand your question (what kind of "carrying" should the clients do); the standard library most certainly supports validation of the server certificate. |
|
|
| msg152289 - (view) |
Author: Senthil Kumaran (orsenthil) * |
Date: 2012-01-29 23:39 |
| On Sun, Jan 29, 2012 at 10:48:35PM +0000, Martin v. Löwis wrote: > orsenthil: I don't fully understand your question (what kind of "carrying" should the clients do); By that I mean, sending the ca_file and cert_reqs from the client, which I believe would be required if you want to verify the server certificate from the client end [1]. The other clients send only the cert_file and the key_file. [1]: http://code.activestate.com/recipes/577548-https-httplib-client-connection-with-certificate-v/ |
|
|
| msg152292 - (view) |
Author: Senthil Kumaran (orsenthil) * |
Date: 2012-01-29 23:55 |
| On Sun, Jan 29, 2012 at 10:30:45PM +0000, Antoine Pitrou wrote: > > Well, if you are a security expert you can volunteer to maintain a > trusted certificates' file in the Python repository :) I think > nobody else amongst us is qualified. :-) haha. Neither am I (and I didn't figure out immediately that, that's the requirement to go forward, so definitely not the person.) But given that curl [1] has adopted the approach the user will know where the CA cert will be and let's the user specify the details, I wondered if the just having the provision to give ca_cert details is a good thing. Yeah, I recollect a discussion that there is not a standard file-system path where OS store the certs and relying on them is not a good idea. [1] http://curl.haxx.se/docs/sslcerts.html |
|
|
| msg152296 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2012-01-30 00:45 |
| > By that I mean, sending the ca_file and cert_reqs from the client, > which I believe would be required if you want to verify the server > certificate from the client end [1]. The other clients send only > the cert_file and the key_file. Ah, you are probably referring to the "server name indication", which is a fairly recent TLS feature. Python does support it, in the server_hostname context field. You never ever send the CA certificate to the server in TLS, AFAIK (except as part of a chain including your own client certificate). |
|
|
| msg152302 - (view) |
Author: Senthil Kumaran (orsenthil) * |
Date: 2012-01-30 02:08 |
| I think, I was using wrong terminology, by 'sending' I meant, 'using' the ca_file in the client to verify Server's certificates. |
|
|
| msg152313 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2012-01-30 08:09 |
| > I think, I was using wrong terminology, by 'sending' I meant, 'using' the ca_file in the client to verify Server's certificates. Then I still don't understand your remarks. You said "is there any reason for the clients in the stdlib are not carrying a ca_file", but this isn't actually true: clients in the stdlib *do* carry the CA file and *do* perform verification, see ftplib, nntplib, imaplib, http.client, etc. It's just that it was forgotten in xmlrpc.client. |
|
|
| msg152460 - (view) |
Author: Senthil Kumaran (orsenthil) * |
Date: 2012-02-02 15:53 |
| I am sorry. I see that with context object in 3.x, verification is being done. The CA certs can be pointed to using load_verify_locations. As the author had in this patc tothe pass on addition ca_certs and ca_reqs to wrap_socket in ssl from httplib2. I thought, it was a new requirement. In 2.7, those args are not present. For this issue, modifying the xmlrpc.client to support ssl context and making a HTTPConnection with context object is present may be way to go. |
|
|
| msg152463 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2012-02-02 16:08 |
| > For this issue, modifying the xmlrpc.client to support ssl context and > making a HTTPConnection with context object is present may be way to > go. xmlrpc is higher level than http.client, so you might also adopt the urllib approach of passing ca_file and ca_path. As you (or Martin) prefer :-) |
|
|
| msg275201 - (view) |
Author: Christian Heimes (christian.heimes) * |
Date: 2016-09-08 22:51 |
| xmlrpc.client.SafeTransport() accepts a context object. You can pass a SSLContext in to perform cert validation and even client cert auth. |
|
|