AllowNSSForCrypto
|
旧设计页面
此页面曾用于帮助设计 OpenStack 早期版本的一个特性。它可能已经被实现，也可能没有。因此，此页面可能不会更新，并且可能包含过时的信息。上次更新时间为 2015-01-09 |
目录
简介
[NSS] (网络安全服务) 是一个实现密码服务的库和工具集。它支持 SSL v2 和 v3、TLS、PKCS #5、PKCS #7、PKCS #11、PKCS #12、S/MIME、X.509 v3 证书以及其他安全标准。NSS 是一个 Mozilla 项目，广泛应用于 Mozilla 项目和其他地方。NSS 具有长期 FIPS 140 认证记录。NSS 是 OpenSSL 的竞争替代方案。与 OpenSSL 不同，NSS 的设计核心在于安全的密钥管理，能够很好地与智能卡和其他基于硬件的安全解决方案集成。许多组织，特别是政府机构，要求 NSS 作为密码提供者。
目前在 OpenStack 中，密码服务由 OpenSSL 提供。OpenSSL 的使用直接构建到代码库中。该项目将把密码提供者分解为一个可配置的选项，允许部署选择首选的密码提供者。OpenSSL 将仍然是默认选项。重构应该允许将来轻松集成其他密码提供者，例如 GnuTLS。
进程内库调用与子进程forking
OpenSSL 操作的 Python 绑定要么几乎不存在，要么不完整。迄今为止的方法是通过 fork 子进程来调用 OpenSSL 命令。这既效率低下，又有可能通过进程参数泄露安全敏感信息。使用（进程内）库调用来执行密码操作是首选。
进程内库调用的优点
- 效率更高
- 不太可能泄露安全信息
- 更好的故障诊断（API 错误通常映射到 1 或 2 个命令退出值）
- 更灵活（命令实用程序通常只提供 API 中可用选项的子集）
分阶段方法
所涉及的工作分解为一系列分阶段的步骤。以下尝试解释这些分阶段步骤将如何进行。
通用代码
大量的密码代码在 keystone 和 keystoneclient 之间重复。不幸的是，目前 keystone 和 keystoneclient 之间没有共享通用代码的机制。这非常不幸，因为必须并行维护两个非常相似的代码库。
密码在 Keystone 中使用最多。Keystone 创建和管理用于 SSL/TLS 以及对象签名和验证的 X509 证书和密钥。Python-keystoneclient 消耗其中一些，并在各种地方实现几乎相同的代码。
由于 keystone 具有更复杂的密码功能，因此首先对其进行修改，并作为 keystoneclient 中密码代码的模板。然后最终将这两个代码库合并到一个 keystone 和 keystone client 之间共享的通用代码库中。
从一个高级别的角度来看，工作的分阶段进行如下
- 修改 keystone
- 将步骤 1 的一部分 keystone 代码移植到 keystoneclient
- 将 1 和 2 合并到通用代码库中。
阶段 1：分离密码提供者类
- 分解现有的 OpenSSL'isms。当前代码暴露了一些 OpenSSL 特有的内容，在其他密码实现中没有直接的对应物。
- 将 OpenSSL 操作分解为从通用密码提供者类派生的 OpenSSL 密码提供者类。
- 添加配置支持以选择 OpenSSL 作为密码提供者。
- 验证所有单元测试是否在选择 OpenSSL 作为密码提供者的情况下成功运行。
- 实现 NSS 密码提供者类
- 更新单元测试以同时使用 OpenSSL 和 NSS 提供者
阶段 2：对 keystoneclient 重复阶段 1
阶段 1 中的步骤必须对 keystoneclient 重复。这应该更简单，因为阶段 1 中完成的工作可以复制/移植到 keystoneclient 代码库中。
阶段 3：进程内库调用
将密码提供者类重构为通用基类和 2 个子类。一个子类提供子进程调用模型的实现（以前的现有工作），另一个子类使用进程内库调用实现相同的功能。
目前，只有 NSS 设想或进程内库调用，因为目前 NSS 是唯一具有广泛 Python 绑定的密码提供者。
基本步骤是
- 拆分密码提供者类以允许实现进程内或子进程调用的子类。
- 更新单元测试以选择和使用不同的调用模型，最初修复单元测试以调用现有的子进程调用模型。确保所有测试都通过。
- 为 NSS 密码提供者实现进程内调用。更新单元测试以迭代两种调用模型。
分阶段方法总结
工作项分解为许多不同的独立步骤。它们可以看作是一系列嵌套循环。如果需要，嵌套顺序可以重新排列。例如，将通用代码分解为共享模块可以在分阶段步骤中的各种位置执行。
