TLS or SSL in asyncio

[ma...@juffo.org]

As has been mentioned before on the list (http://goo.gl/9A1dRN), SSL is an obsolete term and the protocol is really called TLS these days. But I didn't find any discussion about changing the PEP.

1. Should the references to "SSL connection" in the PEP perhaps be changed? Maybe just use "TLS/SSL" like the ssl module documentation does.

2. What about the API? The reference event loop uses Python's own ssl module based on OpenSSL, so the function argument ssl= somewhat makes sense. Calling it tls would look a bit inelegant:
    create_connection(..., tls=ssl.SSLContext(...))
Opinions?

Other event loops may well use different SSL libraries like GnuTLS. It seems from the PEP that they are still expected to accept ssl.SSLContext as an argument?

Regards,
Marti

[Guido van Rossum]

On Thu, Oct 24, 2013 at 6:16 AM, <ma...@juffo.org> wrote:

As has been mentioned before on the list (http://goo.gl/9A1dRN), SSL is an obsolete term and the protocol is really called TLS these days. But I didn't find any discussion about changing the PEP.

Most people still call it SSL, and it really shouldn't matter.

1. Should the references to "SSL connection" in the PEP perhaps be changed? Maybe just use "TLS/SSL" like the ssl module documentation does.

I'm fine with the docs clarifying that in most cases this means TLS, similarly to the way it is done for the existing ssl module in the standard library.

 

2. What about the API? The reference event loop uses Python's own ssl module based on OpenSSL, so the function argument ssl= somewhat makes sense. Calling it tls would look a bit inelegant:
    create_connection(..., tls=ssl.SSLContext(...))
Opinions?

Right, I think it's fine.

 

Other event loops may well use different SSL libraries like GnuTLS. It seems from the PEP that they are still expected to accept ssl.SSLContext as an argument?

Duck typing is fine here. There's no requirement that the argument is an instance of ssl.SSLContext. Any SSL/TLS implementation should be able to implement the same interface easily.

--
--Guido van Rossum (python.org/~guido)

[Guido van Rossum]

Glyph and I had an off-list discussion on this topic(*), where the complexity of the SSLContext object was revealed (it's very OpenSSL-specific and the Python API doesn't reveal all the contents). In the end we concluded that we don't have to solve this problem today. If a third party implements a better TLS transport, they can offer new top-level functions in their package to create connections and/or servers using that transport class. The signature of those functions is up to them. User who want to use such a TLS implementation have to import it and call one of those functions instead of loop.create_connection/server().

(*) AFAICT we went off-list accidentally, but by the time we discovered this we concluded that it wasn't worth it reposting the discussion to the list.