On Thursday, January 12, 2017, Christian Heimes <christian@cheimes.de> wrote:
On 2017-01-12 18:07, Wes Turner wrote:
>
>
> On Thursday, January 12, 2017, Cory Benfield <cory@lukasa.co.uk
> <mailto:cory@lukasa.co.uk>> wrote:
>
>
>> On 11 Jan 2017, at 21:44, Wes Turner <wes.turner@gmail.com
>> <javascript:_e(%7B%7D,'cvml','wes.turner@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.
I understand your scope concern.
In order to accomplish the aforementioned "hot" TLS config selection,
- Is there context-state to pass to TLSWrappedSocket.do_handshake(self, [context/configurator])?
- Or, would it be possible to specify injection so as to make subclassing unnecessary?
- Would it then be preferable to use a unified configuration object with AttributeErrors and ValueErrors for the context (and any potential connection-specific reconfigurations); instead of kwargs here and there?
Christian
https://mail.python.org/pipermail/distutils-sig/2017-January/029970.html