On Thursday, January 12, 2017, Christian Heimes <christ...@cheimes.de> wrote:
> On 2017-01-12 18:07, Wes Turner wrote: > > > > > > On Thursday, January 12, 2017, Cory Benfield <c...@lukasa.co.uk > <javascript:;> > > <mailto:c...@lukasa.co.uk <javascript:;>>> wrote: > > > > > >> On 11 Jan 2017, at 21:44, Wes Turner <wes.tur...@gmail.com > <javascript:;> > >> <javascript:_e(%7B%7D,'cvml','wes.tur...@gmail.com <javascript:;>');>> > 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 >
_______________________________________________ Security-SIG mailing list Security-SIG@python.org https://mail.python.org/mailman/listinfo/security-sig
