[Security-sig] Unified TLS API for Python

[Cory Benfield]

> On 11 Jan 2017, at 19:36, Christian Heimes <christian at cheimes.de> wrote:
> 
> Since this function is only required for TLS servers and TLS client cert
> authentication, I'd rather mark this function provisional or not define
> it in the first version.

Is that the best option? Will there be any TLS implementation that cannot meet a stripped down version of this function’s requirements? If we can achieve a minimum viable approach whereby 80% of the use-case (unencrypted/encrypted certs on disk) can be met, I’d like to be able to meet it.

>>        @abstractmethod
>>        def set_ciphers(self, ciphers: List[Ciphers]) -> None:
>>            """
>>            Set the available ciphers for TLS connections created with this
>>            context. ``ciphers`` should be a list of ciphers from the
>>            ``Cipher`` registry. If none of the ``ciphers`` provided to this
>>            object are supported or available, a ``TLSError`` will be raised.
>>            """
> 
> Implementors should initial context with sensible default settings,
> preferable system-wide settings. For example Fedora is currently
> implementing https://fedoraproject.org/wiki/Changes/CryptoPolicy <https://fedoraproject.org/wiki/Changes/CryptoPolicy> for
> OpenSSL, NSS and GnuTLS.

Is this an additional requirement to create_default_context, which should presumably be able using this API to do sensible things?

>>        @abstractmethod
>>        def wrap_buffers(self, incoming: Any, outgoing: Any,
>>                         server_side=False: bool,
>>                         server_hostname=None: Optional[str]) -> TLSWrappedBuffer:
>>            """
>>            Wrap a pair of buffer objects (``incoming`` and ``outgoing``) to
>>            create an in-memory stream for TLS. The SSL routines will read data
>>            from ``incoming`` and decrypt it, and write encrypted data to
>>            ``outgoing``.
>> 
>>            The ``server_side`` and ``server_hostname`` parameters have the
>>            same meaning as in ``wrap_socket``.
>>            """
> 
> 
> How about not defining this methods at all? IMO it makes no sense to
> support client and server connections from the same context. This is
> also the gist of a PEP I'm currently working on.

When you say “not defining this at all”, do you mean not using “server_side”? Because we definitely need the some wrap methods.

> Cipher suites are going to be a mess! Too bad OpenSSL and GnuTLS do not
> use IANA names. :( It should be good enough to focus on a subset and use
> the wire protocol values as internal identifiers.
> 
> https://raw.githubusercontent.com/tiran/tlsdb/master/tlsdb.json <https://raw.githubusercontent.com/tiran/tlsdb/master/tlsdb.json>
Yeah, I was thinking an enum with values, which give us the advantage of a strongly-typed API as well as giving sensible internal identifiers.

Cory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/security-sig/attachments/20170111/beeb31b1/attachment-0001.html>