2  TLS/DTLS 和 TLS 前身 SSL

2  TLS/DTLS 和 TLS 前身 SSL

Erlang SSL 应用程序为当前支持的版本实现了 TLS/DTLS 协议，请参见 ssl(3) 手册页。

默认情况下，TLS 在 TCP/IP 协议之上运行，尽管您可以使用与内核中 gen_tcp 模块具有相同应用程序编程接口 (API) 的任何其他可靠传输协议。DTLS 默认情况下在 UDP/IP 之上运行，这意味着应用程序数据没有传递保证。其他传输方式（如 SCTP）可能在将来的版本中得到支持。

如果客户端和服务器希望使用升级机制（例如由 RFC 2817 定义）将常规 TCP/IP 连接升级到 TLS 连接，则 Erlang SSL 应用程序 API 支持此操作。这对于例如在同一个端口上支持 HTTP 和 HTTPS 以及实现虚拟主机非常有用。请注意，这仅是 TLS 功能。

为了实现身份验证和隐私，客户端和服务器在传输或接收任何数据之前执行 TLS/DTLS 握手过程。在握手过程中，它们就协议版本和加密算法达成一致，使用公钥密码生成共享密钥，并选择性地使用数字证书相互验证身份。

对称密钥算法只有一个密钥。该密钥用于加密和解密。与公钥算法（使用两个密钥，一个公钥和一个私钥）相比，这些算法速度更快，因此通常用于加密大量数据。

对称加密的密钥是为每个连接唯一生成的，并且基于在 TLS/DTLS 握手过程中协商的密钥。

TLS/DTLS 握手协议和数据传输在 TLS/DTLS 记录协议之上运行，该协议使用带密钥散列的消息认证码 (MAC) 或基于散列的 MAC (HMAC) 来保护消息数据的完整性。来自 TLS RFC：“消息认证码是根据消息和一些秘密数据计算出的单向散列。在不知道秘密数据的情况下，很难伪造。它的目的是检测消息是否被篡改。”

证书类似于驾驶执照或护照。证书持有人称为主体。证书使用证书颁发者的私钥签名。通过让颁发者反过来由另一个证书认证，依此类推，直到到达所谓的根证书，该证书是自签名的，即由其自身颁发，从而建立信任链。

证书只能由证书颁发机构 (CA) 颁发。世界上只有少数顶尖的 CA 颁发根证书。您可以通过点击网页浏览器的菜单查看其中一些证书。

对等身份验证通过 RFC 3280 中定义的公钥路径验证完成。这基本上意味着以下内容

  • 证书链中的每个证书都由前一个证书颁发。
  • 证书属性有效。
  • 根证书是存在于对等方保存的受信任证书数据库中的受信任证书。

服务器始终在 TLS 握手过程中发送证书链，但客户端仅在服务器请求时发送证书。如果客户端没有合适的证书，它可以向服务器发送“空”证书。

客户端可以选择接受一些路径评估错误，例如，网页浏览器可以询问用户是否接受未知的 CA 根证书。但是，如果服务器请求证书，它不会接受任何路径验证错误。服务器是否接受或拒绝“空”证书作为对证书请求的响应是可以配置的。

2.5  TLS 会话 - 预 TLS-1.3

来自 TLS RFC：“TLS 会话是客户端和服务器之间的关联。会话由握手协议创建。会话定义一组加密安全参数，这些参数可以在多个连接之间共享。会话用于避免为每个连接协商新的安全参数的昂贵操作。”

默认情况下，会话数据由 SSL 应用程序保存在内存存储中，因此会话数据在应用程序重新启动或接管时丢失。如果需要持久性数据存储，用户可以定义自己的回调模块来处理会话数据存储。当会话数据库超出其限制或在保存后 24 小时（RFC 最长生命周期建议）时，会话数据也会失效。会话数据保存的时间量可以配置。

默认情况下，TLS/DTLS 客户端尝试重用可用会话，并且默认情况下，当客户端请求时，TLS/DTLS 服务器同意重用会话。另请参见 TLS 1.3 之前的会话重用

在 TLS 1.3 中，会话重用被基于预共享密钥概念的新会话票证机制取代。此机制还使 RFC5077 中的会话票证过时，该机制未由此应用程序实现。另请参见 TLS 1.3 中的会话票证和会话恢复

版权所有 © 1999-2024 爱立信 AB。保留所有权利。