On 13 January 2017 at 16:32, Wes Turner <wes.tur...@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 | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
Security-SIG mailing list
Security-SIG@python.org
https://mail.python.org/mailman/listinfo/security-sig
