PEP 748: A Unified TLS API for Python #3853
Conversation
Signed-off-by: William Woodruff <[email protected]>
peps/pep-9999.rst
Outdated
|
|
||
| These bindings can be used by tools that expect the interface provided by the | ||
| Python standard library, with the goal of reducing the dependence of the Python | ||
| ecosystem on OpenSSL. |
There was a problem hiding this comment.
CC @jvdprng: this doesn't include your rendered diagrams, yet. We'll need to add those.
Signed-off-by: William Woodruff <[email protected]>
|
You can use PEP number 748. |
Signed-off-by: William Woodruff <[email protected]>
woodruffw
changed the title
This is getting a little out of control, though. Signed-off-by: William Woodruff <[email protected]>
| Author: Joop van de Pol <[email protected]>, | ||
| William Woodruff <[email protected]> | ||
| Sponsor: Alyssa Coghlan <[email protected]> | ||
| Discussions-To: https://discuss.python.org/t/pre-pep-discussion-revival-of-pep-543/51263 |
There was a problem hiding this comment.
When this ready, please open a new discussion and list it here.
You can either open the discussion just before merge and add it here, or remove this line for merge, then open the discussion, and open a new PR to list it here (and in the Post-History).
Co-authored-by: Hugo van Kemenade <[email protected]>
Signed-off-by: William Woodruff <[email protected]>
| implement the following: | ||
|
|
||
| * ``recv`` and ``send`` | ||
| * ``listen`` and ``accept`` |
There was a problem hiding this comment.
What is the expected behaviour of these two APIs if the socket was created from a client context?
There was a problem hiding this comment.
I think it should probably raise a generic error, as I'm not aware of situations where a TLS client would be waiting for a TLS server to make the connection. The current MVP does not handle this properly, so I should fix that.
| defined for TLS v1.3, and for TLS v1.2, it only contains the cipher suites that | ||
| correspond to the TLS v1.3 cipher suites, with ECDHE key exchange (for perfect | ||
| forward secrecy) and ECDSA or RSA signatures, which are an additional ten cipher | ||
| suites. |
There was a problem hiding this comment.
Likely worth explicitly stating here that libraries and applications that need interoperability with legacy ciphersuites will need to continue to use the existing OpenSSL based TLS APIs.
There was a problem hiding this comment.
Or add a sentence referring to the acceptance of raw integers covered in more detail later
peps/pep-0748.rst
Outdated
| Major future TLS features may require revisions of these protocol classes. These | ||
| revisions should be made cautiously: many backends may not be able to move | ||
| forward swiftly, and will be invalidated by changes in these protocol classes. | ||
| This is acceptable, but wherever possible features that are specific to |
There was a problem hiding this comment.
This sentence is odd. This new module would be expected to follow the same compatibility rules as the rest of the standard library (the existing SSL module exception for updating to more secure defaults over time would apply)
There was a problem hiding this comment.
Agreed; I think we took this verbatim from PEP 543, so this entire "future" section probably needs to be reworked.
Co-authored-by: Alyssa Coghlan <[email protected]>
Signed-off-by: William Woodruff <[email protected]>
Signed-off-by: William Woodruff <[email protected]>
Signed-off-by: William Woodruff <[email protected]>
Signed-off-by: William Woodruff <[email protected]>
Signed-off-by: William Woodruff <[email protected]>
There was a problem hiding this comment.
Network Framework presents some unique challenges here and may require a higher-level standardization, something that hooks into asyncio and asks the operating system for something more like "please establish a connection to a peer with these connection parameters" if we want it to fit into a truly platform-integrated-but-cross-platform system for TLS
| Network Framework is the macOS (10.15+) system TLS library. This library is | ||
| substantially more restricted than OpenSSL in many ways, as it has a much more | ||
| restricted class of users. One of these substantial restrictions is in |
There was a problem hiding this comment.
It seems like it would be worth mentioning that Network Framework precludes the implementation of either TLSBuffer or TLSSocket, since there is no way to parse bytes into or out of a bytes buffer, nor any way to cause send and recv to block, as the Network Framework versions of those functions take completion handlers and require a CoreFoundation runloop to already be running.
It's a little misleading to even call Network Framework a "system TLS library", which is why it seems "restricted". Personally I find its architecture very annoying, and badly done in a lot of ways, but in its model it considers TLS to be a the same sort of layer for applications as TCP. In the same way that you can't get raw sockets and then ask the operating system's ethernet driver to assemble connection data from segments in frames with BSD sockets, you cannot ask the operating system's TLS driver to assemble connection data from TCP streams into TLS records for you.
Signed-off-by: William Woodruff <[email protected]>
Co-authored-by: Hugo van Kemenade <[email protected]>
Co-authored-by: Hugo van Kemenade <[email protected]>
|
What's blocking this from getting merged? |
I have a few outstanding changes to make, that I haven't had time to make. But I think it could be merged as-is to get a draft version up, and I could start a follow-up PR with the remaining changes. |
| implementations do not support all of these constructors, and they can | ||
| communicate this to users as described in the “Runtime” section below. | ||
| Certificates from arbitrary identifiers, in particular, are expected to be | ||
| useful primarily to users seeking to build integrations on top of HSMs, TPMs, |
There was a problem hiding this comment.
These abbreviations are never defined.
There was a problem hiding this comment.
The "expand the first use" style should be sufficient for these two (hardware security modules (HSMs), trusted platform modules (TPMs), if these are actually the first use)
| """ | ||
| Creates a Certificate object from a path, buffer, or ID. | ||
|
|
||
| If none of these is given, an exception is raised. |
There was a problem hiding this comment.
What does it mean if more than one is given? Is that meaningful?
An alternative design could be a single base class with three concrete child classes corresponding to the three variants.
| :mod:`ssl` module exposes too many OpenSSL-specific function calls and features | ||
| to easily map to an alternative TLS implementation. | ||
|
|
||
| Proposal |
There was a problem hiding this comment.
The PEP never says where all the proposed new classes will live. Are you adding a new standard library module? If so, what is it called?
There was a problem hiding this comment.
Good catch. The proof-of-concept PyPI package is tlslib (https://pypi.org/project/tlslib/), while Alex Gaynor and Tom Prince also reserved tls a decade ago (to prevent it from being used for malicious purposes). That means both of those are available as viable names for the stdlib interface.
My recommendation would be to use tls, so tlslib can remain on PyPI as a backport module for any future enhancements to the interface.
Co-authored-by: Jelle Zijlstra <[email protected]>
Current pre-PEP discussion: https://discuss.python.org/t/pre-pep-discussion-revival-of-pep-543/51263
I'm leaving this in draft while @jvdprng and I clean it up a bit -- in particular, we need to copy the latest code examples over from https://github.com/trailofbits/tlslib.py and also make sure that we didn't miss anything while converting this over from our internal doc 🙂
📚 Documentation preview 📚: https://pep-previews--3853.org.readthedocs.build/