前言用TCP，UDP等传输数据时。数据包可能被他人截获，信息会被解析，给信息安全带来巨大挑战。最初的SSL协议是由Netscape提出的。它不会影响上层协议(如HTTP、电子邮件等。)，但能保证上层协议的通信安全。如果正确使用SSL，第三方只能推断连接两端的地址、加密类型、数据频率和发送数据的大概数量，而不能读取或修改任何实际数据。IETF后来在对其进行标准化时，将SSL协议改为了TLS。很多人会把SSL和TLS混在一起，但严格来说是指不同的协议版本(SSL3.0的升级版是TLS1.0)。本文重点介绍了TLS的概念、原理和网络优化。

1.加密、认证和完整性

TLS的目标是为信息传输提供三个基本保证：加密、认证和数据完整性。这三个服务不是必须的，可以根据具体的应用场景来选择。

加密：混淆数据的机制。

认证：一种验证身份有效性的机制。

完整性：一种检测消息是否被篡改或伪造的机制。

2.TLS握手

在通过TLS与服务器交换数据之前，客户端必须协商建立一个加密通道。协商内容包括：TLS版本、加密套件和证书验证(如有必要)。每次协商都需要客户端和服务器之间的往返。一般流程如下：

0: TLS运行在TCP之上，这意味着我们必须首先完成TCP三次握手，这需要一个完整的往返交互(RTT)。

5 ms:TCP连接建立后，客户端发送一些协商信息，如TLS协议版本、支持的密码套件列表以及其他TLS选项。

8ms:服务器选择TLS协议版本，从加密套件列表中选择一个密码套件，附上自己的证书，将响应返回给客户端。或者，服务器也可以向客户端发送证书身份验证请求和其他TLS扩展参数。

12毫秒：假设双方同意一个通用的TLS版本和加密算法。客户端使用服务器提供的证书，生成一个新的对称密钥，用服务器对其进行加密的公钥，并告诉服务器切换到加密的通信过程。到目前为止，所有交换的数据都是明文传输的，除了对称密钥是用服务器端公钥加密的。

40毫秒：服务器用自己的私钥解密客户端发送的对称密钥，通过验证MAC来检查消息的完整性，并返回加密的完成给客户端的消息。

168毫秒：客户端用对称密钥解密消息，并验证MAC。如果一切正常，加密隧道就建立了。可以发送应用数据。

应用层协议协商理论上，两个网络节点可以使用定制的应用协议来相互通信。解决这个问题的方法之一是在前期为协议分配一个众所周知的端口(例如HTTP使用端口80，TLS使用端口443)，并配置所有客户端和服务器使用它。然而，在实践中，这是一个缓慢而不切实际的过程：每个端口的分配必须得到批准，而且什么更糟糕的是，防火墙和其他中间服务器通常只允许使用80和443进行通信。为了简化自定义协议的部署，有必要重用端口80或443，然后通过附加机制协商协议。端口80是为HTTP保留的，HTTP规范提供了一个特殊的升级过程来实现这个目标。然而，使用升级可能会带来额外的网络往返延迟，并且由于中间服务器的存在，在实际应用中往往不可靠。

因为端口80不适合协商协议，所以应该使用端口443，它是为安全HTTPS会话保留的。端到端加密隧道模糊了中间设备的数据，因此它成为实现和部署任何应用协议的一种快速可靠的方式。但是，使用TLS解决了可靠性，我们仍然需要一种方法来协商应用协议！作为HTTPS会话，当然可以重用HTTP的升级机制进行协商，但这会带来额外的完整往返延迟(RTT)。一边和TLS握手，一边协商确认协议是否可行？

应用层协议协商(application layer protocol negotiation，ALPN)是TLS的扩展，支持TLS握手过程中的协议协商，从而消除了HTTP的升级机制所需的额外的往返延迟。流程如下：

向ClientHello消息添加一个新的ProtocolNameList字段，该字段包含支持的应用程序协议列表。

服务器检查ProtocolNameList字段，并在ServerHello消息中返回一个ProtocolName字段，以指示服务器选择的协议。

服务器可能只响应其中一个协议。如果它不支持客户端要求的任何协议，它可以选择中止连接。因此，TLS握手完成后，安全隧道就建立了，客户机和服务器使用的应用程序协议也协商好了——它们可以立即开始通信。

服务器名表示任意两个TCP端之间可以建立加密的TLS隧道：客户端只需要知道对端的IP地址就可以建立连接，进行TLS握手。但是，如果服务器需要部署多个独立的网站，每个网站都有自己的TLS证书，但是使用同一个IP地址——怎么办？为了解决上述问题，TLS协议中引入了SNI (Server Name Indication，服务器名称指示)扩展，允许客户端在握手开始时指示自己想要连接的主机名。检查服务器SNI主机名，选择合适的证书，然后继续握手。

注意：TLS SNI工作流程与HTTP 的主机头域公告过程。客户端在头域中指明它想要请求的主机：许多不同的域可能部署在同一个IP地址。SNI和主机用于区分不同的主机或域。

3.TLS会话恢复

全TLS握手需要额外的延迟和计算，这给所有需要安全通信的应用带来了严重的性能损失。为了帮助减少一些性能损失，TLS提供了一种恢复机制，即多个连接共享相同的协商密钥数据。

会话标识符会话标识符(RFC 5246)恢复机制最初是在SSL 2.0中引入的，它支持服务器创建一个32字节的会话标识符，并将其作为ServerHello 消息。在服务器内部，服务器存储会话ID及其相应的协商参数。相应地，客户端也同时存储会话ID信息。在随后的会议中客户端你好消息可以携带会话ID信息，告诉服务器客户端仍然记得与会话ID对应的密钥和加密算法，并且可以重用这些信息。假设客户端和服务器都可以在各自的缓存中找到共享会话ID参数，则可以减少握手次数，如下图所示。否则，开始新的会话协商并生成新的会话ID。

在会话标识符的帮助下，我们可以减少一次完整往返的开销以及协商共享密钥的公钥加密算法。这使我们能够快速建立安全连接，而不会失去安全性。然而，这个会话标识符机制是服务器需要为每个客户端创建和维护一个会话缓存。这会给服务器带来几个问题，对于一些每天几万甚至几百万单独连接的服务器：缓存session ID所需的内存消耗会非常大，还有就是session ID清除策略的问题。这对于一些流量大的网站来说，并不是一件简单的事情。理想情况下，使用共享TLS会话缓存可以获得最佳性能。以上问题都解决不了。许多高流量网站成功地使用了会话标识符。然而，对于任何多服务主机部署，会话标识符方案都需要一些认真的考虑和良好的系统架构，以确保良好的会话缓存。

会话记录表

由于大量的服务器访问，缓存会话信息是一个很大的负担。为了消除服务器需要维护每个客户端的会话状态缓存的要求Sesion票证引入了机制——服务器不再需要保存客户端的会话状态。如果客户端表明它支持会话票证，它将包含一个新会话票证消息在服务器的最后一步TLS握手，它包含加密通信所需的信息。这些数据是用只有服务器知道的密钥加密的。此会话票证由客户端存储，可以在后续会话中添加到ClientHello消息的Session Ticket扩展中。因此，所有会话信息只存储在客户端，会话票证仍然是安全的，因为它是用只有服务器知道的密钥加密的。

会话标识符和会话票证的机制通常被称为会话缓存和无状态恢复分别是。无状态恢复的主要改进是消除了服务器端的会话缓存，从而简化了部署。它要求客户在每次新会话开始时提供会话票证，直到票证过期。

注意：在实际应用中，在一组负载均衡的服务器中部署会话票证也需要仔细考虑：所有服务器必须使用相同的会话密钥，或者可能需要一个额外的机制来定期在所有服务器上共享密钥。

4.证书颁发和撤销

身份验证是建立每个TLS连接的重要部分。毕竟TLS可以通过加密隧道与任何一端进行通信，包括攻击者。除非我们能确定我们交流的对方是值得信任的，否则所有的加密工作都是无效的。如何证明一个主机值得信任？这需要证书，只有拥有合法证书的主机才能被信任。证书的来源有哪些？

手动指定的用户证书：每个浏览器和操作系统都提供了手动导入任何您信任的证书的机制。如何获得证书并验证其完整性完全取决于您。

证书颁发机构：证书颁发机构(CA)是受信任的第三方组织(所有者)，其证书值得信任。

浏览器和操作系统：每个操作系统和大多数浏览器都包含一个著名的证书颁发机构列表。因此，您也可以信任该软件的供应商来提供和维护信任列表。

在实际应用中，为每个网站手动验证证书是不切实际的(尽管您可以，如果您愿意的话)。因此，最常见的解决方案是在证书颁发机构(CA)的帮助下做到这一点(如下所示):在您的浏览器中指定哪些CA是可信的(根CA证书)，CA负责验证您访问的每个网站并进行审核，以确认这些证书没有被滥用或损坏。如果任何网站违反CA 的证书，那么CA有责任撤销它的证书。

有时，证书颁发机构可能需要吊销证书或使证书无效，这可能是由于证书的私钥被破坏、证书颁发机构本身被破坏或其他正常原因，如证书替换、证书颁发机构的更改等等。为了解决这个问题，证书本身包含了检查它是否被撤销的逻辑。因此，为了确保信任链不会受到攻击的影响，每个节点可以检查每个证书的状态以及签名。

证书吊销列表(CRL):每个证书颁发机构维护并定期发布一个已吊销证书的序列号列表。要验证证书的可靠性，可以直接查询CRL列表。

CRL文件本身可以定期发布或每次更新，CRL文件可以通过HTTP或任何其他文件传输协议传输。这个列表也是由CA签名的，通常允许在指定的时间间隔进行缓存。在实际应用中，该过程运行良好，但是也存在CRL机制可能存在缺陷的一些情况：

越来越多的撤销意味着CRL列表只会越来越长，每个客户端都必须获得整个序列号列表。

证书撤销没有即时通知机制——如果证书在客户端缓存期间被撤销，客户端将认为证书有效，直到缓存过期。

在线证书状态协议(online Certificate Status Protocol，OCSP):提供实时检查证书状态的机制，支持验证者直接查询证书数据库中的序列号，从而验证证书是否有效。

OSCP占用带宽少，支持实时验证，也带来一些问题。如下所示：

CA必须能够处理实时查询的实时性和负载。

CA必须确保服务在任何时候都是全球可用的。

在任何谈判之前，客户必须等待OCSP的请求。

因为CA知道客户端访问了哪些网站，所以实时OCSP请求可能会暴露客户端隐私。

5.TLS记录协议

日志协议主要用于识别TLS中的消息类型(握手、警告或数据由内容类型字段)，并保护和验证每个消息的完整性。传递应用程序数据的典型过程如下：

记录由协议接收应用数据；

数据分块，每个块最大大小为2 ^ 14，即16kb；

数据压缩(可选)；

添加消息认证码(MAC)或HMAC(用于验证消息的完整性和可靠性)；

使用协商的加密算法加密数据。

完成上述步骤后，加密数据将被传递到TCP层进行传输。在接收端，采用反向相同的工作流程：通过协商的加密算法解密数据，验证MAC，将提取的应用数据发送到应用层。另一个好消息是，上述所有过程都由TLS层自己处理，这对大多数应用程序来说是完全透明的。

当然，TLS记录协议也带来了一些重要的限制：

TLS记录的最大大小是16KB；

每条记录包含一个5字节的头、MAC(SSLv3、TLS 1.0、TLS 1.1最多20字节、TLS 1.2最多32字节)和填充)；如果采用分组加密算法；

为了解密和验证每条数据，必须确保所有数据都已收到。

6.TLS优化

计算成本

尽快完成(握手)

会话缓存和无状态恢复

TLS记录大小

TLS压缩

证书链的长度

OCSP信封

HTTP严格传输安全hfy

标签：协议服务器证书