python tls_适用于Python的统一TLS API

python tls

I have just proposed PEP 543: A Unified TLS API for Python to the python-dev mailing list for discussion. While the bulk of the technical correspondence will happen on that mailing list, I wanted to briefly write a long-form, less formal discussion of why this PEP is important and the problems I’m trying to address.

我刚刚向python-dev邮件列表提出了PEP 543：针对Python的统一TLS API进行讨论。 尽管大部分技术通信将在该邮件列表中进行，但我还是想简短地写一篇关于该PEP为何重要以及我要解决的问题的非正式形式的长篇讨论。

To understand the problem that this PEP aims to address, it’s important to try to understand the approaches that different programming languages take to supporting TLS. TLS is an extremely widely-deployed network protocol and it’s essential for any language that wants to be used for “real work” to have at least some support for TLS, if only to ensure that data can be securely retrieved from websites. That means that anyone working on a programming language eventually needs to confront a core question: “how will my users do TLS?”

要了解此PEP旨在解决的问题，重要的是尝试了解不同编程语言支持TLS所采用的方法。 TLS是一种极其广泛使用的网络协议，对于所有想要用于“实际工作”的语言，至少要确保可以从网站安全地检索数据，它对于TLS至少具有一定的支持至关重要。 这意味着任何使用编程语言的人最终都需要面对一个核心问题：“我的用户将如何执行TLS？”

Conveniently, languages can be broken more or less down the middle into two groups, which I will for inflammatory reasons call “systems languages” and “higher-level languages”. This is an obviously absurd categorisation of languages, but it’s a simple enough division that lets us focus on intent.

方便地，语言可以或多或少地分为两类，出于煽动性的原因，我将它们称为“系统语言”和“高级语言”。 这显然是一种荒谬的语言分类 ，但这是一个足够简单的划分，使我们可以专注于意图。

For the “systems languages”, which for this example include languages like C, C++, and Rust, there is a focus on simplicity and minimalism: it is necessary to be able to build binaries that assume a minimal operating environment. For these languages, TLS is considered to be a “bring your own” affair: programmers that want TLS should reach for one of the many binary TLS libraries that the world has to offer (such as OpenSSL or GnuTLS), the language will not provide one for them. In these languages, many higher-level frameworks will exist that combine these libraries with appropriate I/O management code and protocol implementations for users that don’t need the flexibility of a BYO TLS approach. But it remains the case that the language does not privilege one TLS implementation above any other.

对于“系统语言”，在本示例中包括诸如C，C ++和Rust的语言，着重于简单性和简约性：必须能够构建假定最小操作环境的二进制文件。 对于这些语言，TLS被认为是“自成一体”的事情：希望TLS的程序员应该接触世界必须提供的许多二进制TLS库之一（例如OpenSSL或GnuTLS），而该语言将不会提供一个给他们。 在这些语言中，将存在许多更高级别的框架，这些框架将这些库与适当的I / O管理代码和协议实现相结合，以供不需要BYO TLS方法灵活性的用户使用。 但是仍然存在这种情况，即该语言不会优先于一种TLS实施。

For the “higher-level languages”, however, there is a higher focus on immediate programmer productivity. Many programmers will likely want to use these languages for providing sysadmin “glue” and other important tasks that get a great deal of value from going from zero to working as quickly as possible. For this reason, these languages are incentivised to create a “blessed” TLS implementation and API that they ship in their standard library. Python does this with its ssl module, Go has crypto/tls, Ruby has its OpenSSL module, and Java has JSSE.

但是，对于“高级语言”，他们更加注重即时程序员的生产力。 许多程序员可能会希望使用这些语言来提供sysadmin“胶水”和其他重要任务，这些任务从零到尽快工作具有巨大的价值。 因此，激励这些语言创建标准库中附带的“受祝福的” TLS实现和API。 Python通过其ssl模块来实现这一点，Go具有crypto/tls ，Ruby具有其OpenSSL模块，而Java具有JSSE 。

These blessed implementations can be further divided into two groups: custom implementations, and bindings. crypto/tls and JSSE are both custom TLS implementations that are written from scratch in the language that uses them, while ssl and OpenSSL are both bindings (unsurprisingly, they’re both bindings to the venerable OpenSSL library). In general, languages that ship bindings overwhelmingly choose to bind OpenSSL. Python is one of these languages.

这些有福的实现可以进一步分为两组：自定义实现和绑定。 crypto/tls和JSSE都是自定义TLS实现，都是使用使用它们的语言从头开始编写的，而ssl和OpenSSL都是绑定（毫无疑问，它们都绑定到了古老的OpenSSL库）。 通常，提供绑定的语言绝大多数选择绑定OpenSSL。 Python是这些语言之一。

Despite its name, Python’s ssl module is not actually intended to be an abstract SSL (better called TLS) implementation. It is strictly a binding to OpenSSL. It uses OpenSSL concepts fairly directly, and frequently directly exposes OpenSSL constants and flags. This means it would be better named the openssl module. The module’s API cannot be easily translated to work with one of the many other TLS implementations that exist.

尽管有其名称，Python的ssl模块实际上并不是要用作抽象SSL（更好地称为TLS）实现。 严格来说，它是对OpenSSL的绑定。 它相当直接地使用OpenSSL概念，并且经常直接公开OpenSSL常量和标志。 这意味着最好将其命名为openssl模块。 该模块的API无法轻松转换为与现有的许多其他TLS实现之一一起使用。

Now, at this point it would be reasonable to say: so what? Good question.

现在，在这一点上可以合理地说：那又怎样？ 好问题。

It turns out that OpenSSL is just one of many TLS implementations in the world. It’s comfortably the one with the best name recognition, and is definitely the most widely-deployed open-source TLS implementation in the world. But there are plenty of others. For example, a quick jaunt over to Wikipedia presents the following others: Botan, BoringSSL, Bouncy Castle, cryptlib, GnuTLS, LibreSSL, MatrixSSL, mbedTLS, NSS, s2n, SChannel, Secure Transport, and wolfSSL.

事实证明，OpenSSL只是世界上许多TLS实现的一种。 令人欣慰的是，它具有最佳的名称识别能力，并且绝对是世界上部署最广泛的开源TLS实现。 但是还有很多其他的。 例如， 对Wikipedia的快速攻击显示了以下其他内容：Botan，BoringSSL，Bouncy Castle，cryptlib，GnuTLS，LibreSSL，MatrixSSL，mbedTLS，NSS，s2n，SChannel，安全传输和wolfSSL。

While OpenSSL is a reasonable choice, there are plenty of good reasons for wanting to use other TLS implementations. For example, NSS is widely deployed in Red Hat deployments for other security purposes, and users may not want to deploy with multiple TLS stacks. Alternatively, users may want to use as much GPL’d software as possible, and so would prefer to use GnuTLS. Or maybe you’re running MicroPython and would like to use TLS, but don’t want the massive binary size of OpenSSL and so would prefer something like mbedTLS instead. These are all excellent reasons to want to use alternative implementations.

尽管OpenSSL是一个合理的选择，但有很多充分的理由希望使用其他TLS实现。 例如，出于其他安全目的，NSS已广泛部署在Red Hat部署中，并且用户可能不希望使用多个TLS堆栈进行部署。 或者，用户可能希望使用尽可能多的GPL软件，因此更喜欢使用GnuTLS。 或者，也许您正在运行MicroPython并希望使用TLS，但不希望使用OpenSSL的巨大二进制大小，因此希望使用mbedTLS之类的东西。 这些都是要使用替代实现的绝佳理由。

But far and away the most common reason to want to use an alternative implementation is to write user-facing software that feels “platform-native”. This is a complex notion that ultimately boils down to: if I installed my software-vendor’s preferred web browser, and browsed to this URL, I should get the same result in the Python code as I do in the web browser. For Linux operating systems that usually means using OpenSSL, but can sometimes mean using GnuTLS or NSS depending on the OS in question. For Mac users, that would mean using Secure Transport, and for Windows users, it would mean using SChannel.

但是，很显然，使用替代实现的最常见原因是编写感觉“平台原生”的面向用户的软件。 这是一个复杂的概念，最终可以归结为：如果我安装了软件供应商的首选Web浏览器，并浏览到该URL，则应该在Python代码中获得与在Web浏览器中相同的结果。 对于Linux操作系统，这通常表示使用OpenSSL，但有时可能表示使用GnuTLS或NSS，具体取决于所涉及的OS。 对于Mac用户，这意味着使用安全传输，对于Windows用户，这意味着使用SChannel。

However, Python ultimately provides no tools to do this in a general way. While there are tools to use these other libraries, such as Will Bond’s impressive oscrypto library, there are no tools available to Python that allow people writing applications to write to a generic TLS API that can be implemented by a number of TLS backends. This leads to a surprising number of real problems. A short list of them includes:

但是，Python最终没有提供一般工具来执行此操作。 虽然有使用这些其他库的工具，例如Will Bond令人印象深刻的oscrypto库，但是Python没有可用的工具允许编写应用程序的人写入可以由许多TLS后端实现的通用TLS API。 这导致了令人惊讶的大量实际问题。 其中的简短列表包括：

1. It becomes very hard to write “native apps” for many platforms. On Linux it’s mostly OK, if you restrain your definition of “Linux” to include “systems that use OpenSSL as their default TLS implementation”. But if you want to write, say, a Mac application that feels like it was written in Swift, this is a weird wart that requires a lot of custom code to get around.
2. System administrator choices regarding the trust database (basically, “which certificate authorities do we trust”) are not respected. This is very problematic in enterprise environments which typically want to install their own certificate authorities for their internal systems: unless they happen to be using Linux-with-OpenSSL on all their machines, this doesn’t necessarily work nicely.
3. Users often don’t realise they are trusting the OpenSSL that their Python is linked against: in many cases, they don’t know where it came from! This is bad on systems that don’t ship OpenSSL themselves (Windows) or that ship ancient OpenSSLs (macOS), as those libraries will often not be kept up-to-date with security fixes. This exposes users who use Python-based applications to risks they would not have encountered with native applications.

1. 为许多平台编写“本机应用程序”变得非常困难。 在Linux上，如果将“ Linux”的定义限制为包括“使用OpenSSL作为其默认TLS实现的系统”，则通常可以。 但是，如果您想编写一个Mac应用程序，感觉就像是用Swift编写的，那真是奇怪，需要很多自定义代码才能解决。
2. 不遵守有关信任数据库的系统管理员选择（基本上是“我们信任哪些证书颁发机构”）。 在企业环境中，这通常要为其内部系统安装自己的证书颁发机构，这是非常成问题的：除非他们碰巧在其所有机器上都使用Linux-with-OpenSSL，否则不一定能很好地工作。
3. 用户通常不会意识到他们信任Python与之链接的OpenSSL：在许多情况下，他们不知道它来自何处！ 这对于不自带OpenSSL的系统（Windows）或自带旧式OpenSSL（macOS）的系统来说是不好的，因为这些库通常不会通过安全修复程序保持最新。 这使使用基于Python的应用程序的用户面临本机应用程序不会遇到的风险。

I need to emphasise here: the problem is not that Python cannot use alternative TLS stacks. Of course it can. The problem is that because the standard library provides a TLS implementation, there is a strong incentive to write to it. In general, the standard library of a language exerts a strong influence over the kinds of applications that get written, and given that for many of Python’s historical uses the ssl module has been “good enough”, there has been little impetus to support other models.

我在这里需要强调：问题不是Python无法使用替代TLS堆栈。 当然可以。 问题在于，由于标准库提供了TLS实现，因此强烈地鼓励对其进行写入。 通常，一种语言的标准库会对编写的各种应用程序产生强大的影响，并且鉴于python的许多历史使用， ssl模块已经“足够好”，几乎没有动力来支持其他模型。

What we need to solve this problem is a kind of lubricant: something that makes it so easy to support non-OpenSSL TLS implementations that there is simply no reason not to do it. This will allow the Python community to move towards a model whereby libraries and tools can feel more like platform-native programs.

我们需要解决的问题是一种润滑剂：它使支持非OpenSSL TLS实现变得如此容易，因此根本没有理由不这样做。 这将使Python社区朝着一个使库和工具看起来更像平台本地程序的模型迈进。

Longer-term, it will also reduce the reliance of Python on OpenSSL. The core Python development team should not be required to ship OpenSSL along with their code to support users on Windows and macOS. This isn’t their job or their primary skill set, and it fundamentally puts the Python development team on the hook for providing security updates to OpenSSL’s schedule. It should be possible to ship a version of Python to Windows and Mac users that does not require them to have OpenSSL on their system if they don’t want to.

从长远来看，它将减少Python对OpenSSL的依赖。 不需要Python核心开发团队将OpenSSL及其代码一起提供来支持Windows和macOS上的用户。 这不是他们的工作，也不是他们的主要技能，从根本上来说，这使Python开发团队无法为OpenSSL的计划提供安全更新。 如果有可能，可以向Windows和Mac用户发布Python版本，该版本不需要他们在系统上具有OpenSSL。

翻译自: https://www.pybloggers.com/2017/02/a-unified-tls-api-for-python/

python tls