(original) (raw)

On 8 Nov 2013 04:18, "Christian Heimes" <christian@python.org> wrote:
\>
\> Hi,
\>
\> I'd like to simplify, unify and tighten SSL handling and verification
\> code in Python 3.5\. Therefore I propose to deprecate some features for
\> Python 3.4\. SSLContext objects are going to be the central instance for
\> configuration.
\>
\> In order to archive the goal I propose to
\>
\> - deprecate the key\_file, cert\_file and check\_hostname arguments in
\> � various in favor of context. Python 3.5 will no longer have these
\> � arguments in http.client, smtplib etc.
\>
\> - deprecate implicit verify\_mode=CERT\_NONE. Python 3.5 will default
\> � to CERT\_REQUIRED.
\>
\> - enforce hostname matching in CERT\_OPTIONAL or CERT\_REQUIRED mode
\> � by default in Python 3.5.
\>
\> - add ssl.get\_default\_context() to acquire a default SSLContext object
\> � if the context argument is None. (Python 3.4)

Change this to create\_default\_context() (to make it clearer there is no global context object) and I'm generally +1.

> - add check\_cert option to SSLContext and a check\_cert() function to
\> � SSLSocket in order to unify certificate validation and hostname
\> � matching. (Python 3.4)
\>
\>
\> The SSLContext's check\_cert option will support four values:

I suggest just making this a "verifier" argument that's always a callable.

> None (default)
\> � use match\_hostname() if verify\_mode is CERT\_OPTIONAL or
\> � CERT\_REQUIRED
\> True
\> � always use match\_hostname()
\> False
\> � never use match\_hostname()
\> callable function:
\> � call func(sslsock, hostname, initiator, \*\*kwargs)

This overlaps confusingly with "verify\_mode". Perhaps just offer a module level "verify\_hostname" API that adapts between the verifier signature and match\_hostname, say that is the default verifier, and that the verifier is always called.

Also, how does the verifier know the verify\_mode? Even if that info is set on the wrapped socket, it may be better to make it an optional argument to verifiers as well, to make it clearer that a verify mode of CERT\_NONE may mean verification doesn't actually check anything.

For the new method API (name suggestion: verify\_cert), I believe that should default to CERT\_REQUIRED, regardless of the mode configured on the wrapped socket.

> � The initiator argument is the object that has initiated the
\> � SSL connection, e.g. http.client.HTTPSConnection object.
\> � sslsock.context points to its SSLContext object
\>
\>
\> A connect method may look like this:
\>
\> � def connect(self):
\> � � � hostname = self.hostname
\> � � � s = socket.create\_connection((hostname, self.port))
\> � � � sock = self.context.wrap\_socket(sock,
\> � � � � � � � � � � � � � � � � � � � server\_hostname=hostname)
\> � � � sock.check\_cert(hostname, initiator=self)
\> � � � return sock
\>
\>
\> The check\_cert option for SSLContext makes it easy to customize cert
\> handling. Application developers just need to configure a SSLContext
\> object in order to customize SSL cert verification and matching. In
\> Python 3.4 it will be possible to get the full peer chain, cert
\> information in CERT\_NONE verification mode and SPKI data for SSL
\> pinning. A custom check\_cert callback can be used to validate
\> self-signed certs or test for pinned certificates.
\>
\>
\> The proposal does NOT address the CA certificates difficulty. It's a
\> different story that needs to be addressed for all platforms separately.
\> Most Linux distributions, (Net|Free|Open) BSD and Mac Ports come with
\> SSL certs anyway, although some do not correctly handle the certs'
\> purposes. I have working code for Windows' cert system store that will
\> land in 3.4\. Native Mac OS X hasn't been addressed yet. AIX, HP-UX,
\> Solaris etc. don't come with CA certs.
\>
\> Christian
\>
\> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\> Python-Dev mailing list
\> Python-Dev@python.org
\> https://mail.python.org/mailman/listinfo/python-dev
\> Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com