On 13 January 2017 at 16:32, Wes Turner <wes.turner@gmail.com> wrote:
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)
Ah, I see what you mean you mean now - not "Is this a valid configuration for the current TLS implementation?", but rather "Does this TLS context, as configured, comply with a given security policy?" That also gets back to Christian's observation that: ========== We have to consider different kinds of min and max version: 1) min and max offical SSL/TLS standards 2) min and max supported standards for a TLS implementation 3) min and max version we consider as secure enough ========== Where points 1 & 2 are descriptive of the standards and particular implementations, point 3 is really about security policy recommendations and enforcement. I'd still be inclined to keep that concern separate from those of the core TLS context (which is about applying a given security context to sockets and buffers) though, and instead have the specific concept of a TLSPolicy that can be used to create TLS contexts that meet certain criteria: class TLSPolicy(abc.ABC): @abstractmethod def get_context(self, context_factory: Callable[[], TLSContext] = None) -> None: """Create a TLS context instance that complies with the policy""" ... @abstractmethod def validate_context(self, context: TLSContext) -> bool: """Returns True if the context complies with the policy, False otherwise""" ... The standard library could then provide a concrete implementation and default policy that was sufficient to enforce minimum TLS versions and the acceptable cipher suites, while still leaving room for more capable third party policy enforcement. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia