Author christian.heimes
Recipients christian.heimes, docs@python
Date 2016-09-13.10:34:00
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1473762840.76.0.666078412099.issue28124@psf.upfronthosting.co.za>
In-reply-to
Content
The documentation of the SSL module needs a rework. It's confusing and hard to understand even for experienced developers. The documentation should start with basic use cases and easy-to-reuse best practices.

* The module starts with move ssl.wrap_socket() but it's no longer best practice. The section should be moved down and favor of a quick introduction of SSLContext.

* ssl.create_default_context() is the best way to create a SSLContext. Mention that purpose flags and that Purpose.SERVER_AUTH is the correct setting on the client side. It means: "Create a context to authenticate the certs of a TLS server." (correct also for ftp, imap, ldap, smtp and so on).

* The protocol table is confusing and does not mention the meaning of PROTOCOL_SSLv23 (aka PROTOCOL_TLS). It's auto-negotiation of the highest TLS protocol version and takes OP_NO_* SSLContext.options into account. PROTOCOL_TLS_CLIENT and PROTOCOL_TLS_SERVER are the recommended options nowadays.

* Don't confront users with CERT_OPTIONAL in the first section. It's a super special mode for client cert authentication on the server side. On the client side, CERT_REQUIRED is the right mode with CERT_NONE as workaround. On the server side CERT_NONE (default) is usually the right setting.

* check_hostname is a client-side option that should be enabled all the time.

* Explain that users can load the public key of a  self-signed certificate like a CA cert to have cert validation even for self-signed certs.
History
Date User Action Args
2016-09-13 10:34:00christian.heimessetrecipients: + christian.heimes, docs@python
2016-09-13 10:34:00christian.heimessetmessageid: <1473762840.76.0.666078412099.issue28124@psf.upfronthosting.co.za>
2016-09-13 10:34:00christian.heimeslinkissue28124 messages
2016-09-13 10:34:00christian.heimescreate