[Security-sig] Unified TLS API for Python

Wes Turner wes.turner at gmail.com
Fri Jan 13 01:32:26 EST 2017


On Fri, Jan 13, 2017 at 12:09 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 13 January 2017 at 07:05, Wes Turner <wes.turner at gmail.com> wrote:
> > +1 for start simple and iterate;
> > but expecting a config object is not easy to add later.
>
> Yes, it is - all that is necessary is to add a "make_ssl_context"
> helper function that translates from the declarative configuration
> format (however defined) to the programmatic API and returns a
> configured context of the requested type.
>
> The appropriate time to define that lowest-common-denominator
> configuration format is *after* there is a working programmatic API
> that covers at least the 3 major implementations of interest (OpenSSL,
> SecureTransport, SChannel), and hopefully a few other implementations
> as well (e.g. NSS, BoringSSL).
>

So, rather than scattered throughout each implementation,
I think it would be wise to provide guidance regarding configuration
validation.

Enumerating the parameters into a common schema certainly will require
actual implementations to define a superset of common dict keys; which I
believe would be easier with a standard SSLConfig object.

Another reason I believe there should be a configuration object with a
.validate() method for centralized SSL configuration:

- Having one .validate() method (with as many necessary subvalidators)
provides a hook for security-conscious organizations to do SSL/TLS
configuration validation in one place. (Otherwise, this type of
configuration-validation must be frequently-re-implemented in an ad-hoc
way; which inopportunely admits errors)

   - Examples of SSL/TLS configuration validation criteria:
     -
https://en.wikipedia.org/wiki/FIPS_140-2#Cryptographic_Module_Validation_Program
     - https://mozilla.github.io/server-side-tls/ssl-config-generator/

   - "CIS Critical Security Controls"
https://www.cisecurity.org/critical-controls.cfm
     - CSC 3.[*]
     - Least-privilege dictates that this type of config is separate from
the code.py files

   - "CWE-327: Use of a Broken or Risky Cryptographic Algorithm" (2011 Top
25 #19)
      https://cwe.mitre.org/top25/#CWE-327
      https://cwe.mitre.org/data/definitions/327.html

      - ... "improper configuration" is basically this issue; so,
validation should be encouraged where possible.

Again, I think we should encourage validation of SSL/TLS configuration
settings;
and pointing to SSLConfig.validate() as the method to subclass makes that
very easy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/security-sig/attachments/20170113/268bed7e/attachment.html>


More information about the Security-SIG mailing list