On 13 January 2017 at 23:56, Cory Benfield wrote:

While we’re here, I should point out that this does not replace the abstract contexts entirely, because we still need the wrap_* methods. These would now just be fed a Configuration object (I’m more comfortable with the name Configuration than Policy for this usage) in their constructor, and then could use the wrap_* methods as needed.

Having a relatively passive configuration object sounds OK to me, and I agree it's distinct from a Policy object (which would store constraints on what an acceptable configuration looks like, rather than a specific configuration).

How does that idea sound to the rest of the list?

It would definitely address my concern about making it easy for people to re-use the standard library's default TLS configuration settings, and it would also make it easier to have different defaults for different purposes. 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. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On 14 January 2017 at 01:58, Cory Benfield wrote:

...

On 13 Jan 2017, at 15:45, Nick Coghlan 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 | ncoghlan@gmail.com | Brisbane, Australia

On 13 Jan 2017, at 16:35, Christian Heimes wrote:

How would this work for OpenSSL? In OpenSSL the SNI callback replaces the SSL_CTX of a SSL socket pointer with another SSL_CTX. The new SSL_CTX takes care of cipher negotiation, certs and other handshake details. The SSL_CTX should be reused in order to benefit from cached certs, HSM stuff and cached sessions. OpenSSL binds sessions to SSL_CTX instances.

A callback looks more like this:

contexts = { 'www.example.org': SSLContext(cert1, key1), 'internal.example.com': SSLContext(cert2, key2), }

def sni_callback(sock, hostname): sock.context = contexts[hostname]

If the goal is to keep those contexts static, the best thing to do is to cache the context based on the configuration. Because configurations should be static they should be hashable, which would mean that the ServerContext can keep an internal dictionary of {configuration: SSLContext}. When the new configuration is returned, it can simply pull the context out of the cache as needed. Cory

On 2017-01-13 16:45, Nick Coghlan wrote:

On 13 January 2017 at 23:56, Cory Benfield wrote:

...

While we’re here, I should point out that this does not replace the abstract contexts entirely, because we still need the wrap_* methods. These would now just be fed a Configuration object (I’m more comfortable with the name Configuration than Policy for this usage) in their constructor, and then could use the wrap_* methods as needed.

Having a relatively passive configuration object sounds OK to me, and I agree it's distinct from a Policy object (which would store constraints on what an acceptable configuration looks like, rather than a specific configuration).

...

How does that idea sound to the rest of the list?

It would definitely address my concern about making it easy for people to re-use the standard library's default TLS configuration settings, and it would also make it easier to have different defaults for different purposes.

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.

There aren't many settings that are truly implementation independent. Even ciphers depend on the implementation and version of the TLS provider. Some implementations do support more or less ciphers. Some allow ordering or black listing of algorithms, some do not. Apparently it's even hard to not use the system trust store in some implementations (SecureTransport). How should we deal with e.g. when a TLS implementation does not accept or now about a cipher? I would rather invest time to make TLSConfiguration optional for 99% of all users. Unless you need to connect to a crappy legacy device, a user or developer should not need to mess with TLS settings to get secure options. Some TLS libraries already set sane defaults. OpenSSL is getting there, too. Browsers get it right as well. Even for OpenSSL 1.0.2 (first 1.0.2 release) it is possible to set a secure and future proof cipher list: [openssl/1.0.2]$ bin/openssl ciphers 'DEFAULT:!3DES:!EXPORT:!RC4:!DES:!MD5:!SRP:!PSK:!IDEA:!SEED' | sed 's/:/\n/g' ECDHE-RSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-SHA384 ECDHE-ECDSA-AES256-SHA384 ECDHE-RSA-AES256-SHA ECDHE-ECDSA-AES256-SHA DH-DSS-AES256-GCM-SHA384 DHE-DSS-AES256-GCM-SHA384 DH-RSA-AES256-GCM-SHA384 DHE-RSA-AES256-GCM-SHA384 DHE-RSA-AES256-SHA256 DHE-DSS-AES256-SHA256 DH-RSA-AES256-SHA256 DH-DSS-AES256-SHA256 DHE-RSA-AES256-SHA DHE-DSS-AES256-SHA DH-RSA-AES256-SHA DH-DSS-AES256-SHA DHE-RSA-CAMELLIA256-SHA DHE-DSS-CAMELLIA256-SHA DH-RSA-CAMELLIA256-SHA DH-DSS-CAMELLIA256-SHA ECDH-RSA-AES256-GCM-SHA384 ECDH-ECDSA-AES256-GCM-SHA384 ECDH-RSA-AES256-SHA384 ECDH-ECDSA-AES256-SHA384 ECDH-RSA-AES256-SHA ECDH-ECDSA-AES256-SHA AES256-GCM-SHA384 AES256-SHA256 AES256-SHA CAMELLIA256-SHA ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-ECDSA-AES128-SHA256 ECDHE-RSA-AES128-SHA ECDHE-ECDSA-AES128-SHA DH-DSS-AES128-GCM-SHA256 DHE-DSS-AES128-GCM-SHA256 DH-RSA-AES128-GCM-SHA256 DHE-RSA-AES128-GCM-SHA256 DHE-RSA-AES128-SHA256 DHE-DSS-AES128-SHA256 DH-RSA-AES128-SHA256 DH-DSS-AES128-SHA256 DHE-RSA-AES128-SHA DHE-DSS-AES128-SHA DH-RSA-AES128-SHA DH-DSS-AES128-SHA DHE-RSA-CAMELLIA128-SHA DHE-DSS-CAMELLIA128-SHA DH-RSA-CAMELLIA128-SHA DH-DSS-CAMELLIA128-SHA ECDH-RSA-AES128-GCM-SHA256 ECDH-ECDSA-AES128-GCM-SHA256 ECDH-RSA-AES128-SHA256 ECDH-ECDSA-AES128-SHA256 ECDH-RSA-AES128-SHA ECDH-ECDSA-AES128-SHA AES128-GCM-SHA256 AES128-SHA256 AES128-SHA CAMELLIA128-SHA