⚠️此项目是未维护的实验性遗留代码。它已被 swift-nio-ssl 取代，后者包含 Swift 服务器工作组 推荐的 TLS API。

此处保留仅供历史参考。

目前，没有与所有当前 Swift 平台（Apple 和 Linux）兼容的标准 Swift 安全库。这种缺乏标准化导致了多个项目，这些项目要么编写自己的 Swift 安全功能，要么使用他们选择的安全库（无论是 OpenSSL、LibreSSL 等）。这是不可取的，因为它可能导致

• 依赖项不兼容，如果不同的模块需要多个安全包（一个项目在其依赖关系图中不能同时拥有 OpenSSL 和 LibreSSL）
• 不安全（使用未修补或不安全的库）
• 不可维护性（使用非标准或非原生库）
• 更复杂的代码（为每个平台使用不同的 API）。

本提案概述了一组设计目标以及 Swift 服务器 API 项目的安全工作组为创建在 Apple 和 Linux (Ubuntu) 平台上交叉兼容的单一 Swift 安全组件而应采取的方法。安全 API 将包括较低级别的加密 API（包括哈希、对称和非对称加密）以及更高级别的 API（包括密钥/证书管理和安全通信，例如 TLS）。

在 Apple 和 Linux 上为 Swift 提供一致的开发体验有助于提高开发人员的生产力、更安全的代码以及跨这些平台更好地重用 Swift 资产/库。

同时，利用平台的原生库是有利的，因为它可以提高可维护性，并可能提高整体安全性。这是由于对非原生库的版本和构建/安装方法缺乏控制和一致性所驱动的。

我们为 Swift 安全组件提出以下一组设计目标

• 同时支持 Apple 和 Linux（目前为 Ubuntu 14.04 和 16.04）
• 与受支持平台上的原生安全库集成，以便用户无需负责安装和维护任何其他库；
• 原生库应动态链接，以便及时进行安全修补；
• 避免重新实现安全功能，在底层库中现有功能可用的情况下使用它们；
• 在操作系统之间提供一致且统一的 Swift 接口，以便开发人员可以编写简单的跨平台应用程序；
• 抽象出通信协议，主要与数据流交互。

使用这些目标，我们将在每个平台上使用以下原生库

• 在 Linux 上，我们将使用 OpenSSL，它不仅是最流行的开源安全库，而且还通过了 FIPS 140 合规性验证。OpenSSL 由两个主要的（子）库组成：libssl 和 libcrypto。libcrypto 是一个全面且功能齐全的加密库，它提供了 libssl 使用的基本加密例程，而 libssl 则实现了 SSL 和 TLS 协议。
• 在 Apple 上，我们将分别使用 CommonCrypto 和 Secure Transport，它们分别映射到 OpenSSL 的 libcrypto 和 libssl。

然后，建议的解决方案将包括一个薄薄的 Swift 层，该层定义了一个通用的 API 表面，这些 API 表面使用 Linux 上的 OpenSSL 和 Apple 上的 CommonCrypto 和 Secure Transport 实现。

两个现有项目已采用与本提案类似的方法

• BlueSSLService [https://github.com/IBM-Swift/BlueSSLService] 是一个 TLS 库，用作使用委托/协议模型的 Sockets 的附加框架。它在 Apple 上使用 Apple Secure Transport，在 Linux 上使用 OpenSSL。
• BlueCryptor [https://github.com/IBM-Swift/BlueCryptor] 是一个加密库，在 Apple 上使用 Common Crypto，在 Linux 上使用 OpenSSL。目前，BlueCryptor 不包含非对称密钥功能，因为 Apple 不在 CommonCrypto 级别公开非对称加密 API，而是在 SecKey 和 KeyChain 级别 API 公开它们。

有关更多信息，我们请读者参考 [https://developer.ibm.com/swift/2016/12/13/securing-kitura-cross-platform-challenges/]，作者在其中讨论了 BlueSSLService 的底层框架中的差异如何导致略有不同的跨平台行为。

提供统一的跨平台 API 的直接解决方案是使用相同的底层安全库。下面我们展示了为什么在我们的解决方案中使用用户安装的或非原生的库是不可取的。

考虑 OpenSSL，它是一个跨平台库，可在 macOS 和 Linux 上运行。由于跨版本缺乏 API 兼容性，Apple 从 OS X v10.7 开始弃用了 OpenSSL。自弃用以来，用户负责自行安装和升级 OpenSSL。用户可以获取 OpenSSL 源代码并自行编译（并使用他们自己的自定义标志），或使用第三方软件包管理工具（如 homebrew 或 macport）或自行下载二进制文件。OpenSSL 可以在 macOS 上安装的多种方式导致了更大范围的 OpenSSL 二进制文件，这可能会导致与调用 API 和应用程序不兼容。反过来，这使得 API 的可维护性和正确性更加困难。

当我们考虑到 OpenSSL 跨版本的 API 兼容性不足以及用户现在完全负责库的升级这一事实时，这个问题会进一步加剧。升级的及时性也可能影响库和任何链接应用程序的安全性。

相比之下，原生框架由操作系统交付和维护，并且通常将 API 更改与操作系统版本相关联，这大大提高了链接应用程序的可维护性。

使用原生库的最后一个动机是，供应商通常会对其自己的模块进行安全认证流程，因此用户可以免费获得此认证。特别是，许多涉及政府或企业数据或用户的用例，都需要 FIPS 140 合规性或验证。FIPS 是美国政府 (NIST) 的加密标准，并且是大多数政府机构和许多企业的强制性要求。获得认证的过程是困难、昂贵且耗时的，并且仅由供应商和大型组织完成。

在 Linux 上，OpenSSL 包含 OpenSSL FIPS 对象模块，该模块已通过 FIPS 140-2 合规性验证（不仅仅是合规）。然而，由于 OpenSSL 在 macOS 上被弃用，Apple 不再在 macOS 上提交 OpenSSL 进行 FIPS 140 验证，因此 macOS 上的 OpenSSL 不再符合 FIPS 标准。Apple 提交了自己的 CoreCrypto 和 CoreCrypto Kernel 进行验证。

虽然 Linux 上有许多替代的加密和安全库，包括 LibreSSL、BoringSSL 等，但它们的开源版本不符合 FIPS 标准。例如，LibreSSL 有意删除了 OpenSSL 的 FIPS 对象模块，以使库更精简，从而提高安全性和性能。