On 14 January 2017 at 01:58, Cory Benfield <c...@lukasa.co.uk> wrote: > >> On 13 Jan 2017, at 15:45, Nick Coghlan <ncogh...@gmail.com> wrote: >> >> So the essential stack would look like: >> >> TLSConfig[uration?]: implementation independent, settings only >> TLSClientContext: ABC to combine settings with a specific TLS implementation >> TLSServerContext: ABC to combine settings with a specific TLS implementation >> TLSSocket: ABC to combine a context with a network socket >> TLSBuffer: ABC to combine a context with a pair of data buffers >> >> And then TLSPolicy would be a potential future implementation >> independent addition that could be used to constrain acceptable TLS >> configurations. > > If we were going this way, I’d want to add one extra caveat: I think I’d want > the Contexts to become immutable. > > The logic for the SNI callback would then become: you are called with the > Context that created the socket/buffer, and you return a Configuration object > that contains any changes you want to make, and the Context applies them if > it can (or errors out if it cannot). A new Context is created. This relegates > Context to the role of “socket/buffer factory”. The advantage of this is that > we have vastly reduced the moving parts: a Context can ensure that, once > initiated, the Policy that belongs to it will not change under its feet. It > also allows the Context to refuse to change settings that a given concrete > implementation cannot change in the SNI callback.
Having immutable-by-default config with explicitly managed state changes in particular well-defined scenarios sounds like a big win to me. > This would almost certainly make Context implementation easier, as there is > no longer a requirement to monitor your configuration and support > live-updates. It also drastically reduces the test matrix required, as eliminating any potential dependence on the order in which settings are applied, means you only need to test interesting *combinations* of settings, and not different configuration *sequences*. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Security-SIG mailing list Security-SIG@python.org https://mail.python.org/mailman/listinfo/security-sig
