Author ncoghlan
Recipients Lukasa, alex, christian.heimes, dstufft, giampaolo.rodola, haypo, janssen, martin.panter, ncoghlan, orsenthil
Date 2016-09-10.09:04:32
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1473498273.34.0.424496718231.issue28022@psf.upfronthosting.co.za>
In-reply-to
Content
+1 for a common note in all affected modules along the lines of "An appropriately configured SSLContext should be provided for any use cases that involve accepting self-signed certificates, privately signed certificates, or any other kind of certificate that won't validate against the default system certificate trust store.

It is expected that a future version of Python will switch to explicitly verifying SSL certificates for all SSL/TLS protected connections by default (due to the widespread use of self-signed and privately signed certificates for other protocols, full verification is currently the default only for HTTPS)."

Regarding ssl.wrap_socket(), would it be feasible to provide a migration path to a situation where that's just a thin wrapper around ssl.get_default_context().wrap_socket()?

Comparing the parameter lists:

>>> module_params - method_params
{'ciphers', 'keyfile', 'ca_certs', 'ssl_version', 'cert_reqs', 'certfile'}
>>> method_params - module_params
{'server_hostname'}

That means the real problems are the ciphers, keyfile, ca_certs, ssl_version, cert_reqs and certfile parameters and the internal use of SSLContext() rather than get_default_context(), rather than the essential idea of providing a shorthand spelling for "wrap a socket with the default SSL/TLS settings".
History
Date User Action Args
2016-09-10 09:04:33ncoghlansetrecipients: + ncoghlan, janssen, orsenthil, haypo, giampaolo.rodola, christian.heimes, alex, martin.panter, dstufft, Lukasa
2016-09-10 09:04:33ncoghlansetmessageid: <1473498273.34.0.424496718231.issue28022@psf.upfronthosting.co.za>
2016-09-10 09:04:33ncoghlanlinkissue28022 messages
2016-09-10 09:04:32ncoghlancreate