[Security-sig] Unified TLS API for Python

[Christian Heimes]

On 2017-01-12 18:07, Wes Turner wrote:
> 
> 
> On Thursday, January 12, 2017, Cory Benfield <cory at lukasa.co.uk
> <mailto:cory at lukasa.co.uk>> wrote:
> 
> 
>>     On 11 Jan 2017, at 21:44, Wes Turner <wes.turner at gmail.com
>>     <javascript:_e(%7B%7D,'cvml','wes.turner at gmail.com');>> wrote:
>>
>>     This may be a bit of a different use case (and possibly worth
>>     having in the first version of a new tls module):
>>
>>     "Hitless TLS Certificate Rotation in Go"
>>     https://diogomonica.com/2017/01/11/hitless-tls-certificate-rotation-in-go/
>>     <https://diogomonica.com/2017/01/11/hitless-tls-certificate-rotation-in-go/>
>>
>>     - Can/could this be done with only set_sni_callback ?
> 
>     Yes, it can be. Twisted has an extension module, txsni, that uses
>     the SNI callback to choose which certificate to provide.
> 
> 
> https://github.com/glyph/txsni
>  
> 
>      This is basically identical to the Go GetCertificate callback function.
> 
> 
> There's more config than just the cert, though. There are really two
> reqs mentioned: SNI (Server Name Indication), and "hot" TLS config
> detection/selection:
> 
> """
> The idea is to allow an administrator to force the whole cluster to
> migrate away from an old root CA transparently, removing its existence
> from the trust stores of all the nodes participating in the Swarm. This
> means that we need control over the whole TLS config, instead of
> controlling only which certificate is currently being served.
> """
> '""
> We chose to create a MutableTLSCreds
> <https://github.com/docker/swarmkit/blob/master/ca/transport.go> struct,
> which implements this TransportCredentials
> <https://godoc.org/google.golang.org/grpc/credentials> interface and
> allows the caller to simply change the TLS Config by
> calling |LoadNewTLSConfig|.
> """
> 
> IIUC, we'd currently have to create a new context to change any config
> other than the cert?

Such advanced features are out-of-scope for the PEP. Please remember
that any additional features makes it way more complicated for
implementers. Personally I would rather remove half of the PEP than add
new things. For pip, requests, and similar libraries only a subset of
the features are really required:

* ClientContext.wrap_socket()
* a function like create_default_context() to create a client context
that either loads a CA file or the system's trust store
* TLSError
* TLSWrappedSocket with socket.socket API

Cory likes to define the API the additional features and server-side
TLS. I consider it useful, partly advanced and nice-to-have, but not
mandatory to solve the immediate issue we are facing now. [1]

Let's keep it simple. We can always define an enhanced superset of the
TLS ABC later. But we cannot remove features or change API in an
incompatible way later.

Christian

https://mail.python.org/pipermail/distutils-sig/2017-January/029970.html