版本服务器关闭连接(版本服务器关闭连接是否启用修复程序)

前沿拓展：

版本服务器关闭连接

我刚刚解决这个问题。我的原因可能是之前清理了一次以试试。望采纳。

HTTP与HTTPS介绍

超文本传输协议HTTP协议被用于在Web浏览器和网站服务器之间传递信息，HTTP协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此，HTTP协议不适合传输一些敏感信息，比如：信用**、密码等支付信息。

为了解决HTTP协议的这一缺陷，需要使用另一种协议：安**接字层超文本传输协议HTTPS，为了数据传输的安全，HTTPS在HTTP的基础上加入了SSL/TLS协议，SSL/TLS依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密。

HTTPS协议是由SSL/TLS+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全

HTTPS协议的主要作用可以分为两种：一种是建立一个信息安全通道，来保证数据传输的安全；另一种就是确认网站的真实性。

HTTPS和HTTP的主要区别

1、https协议需要到CA申请证书，一般免费证书较少，因而需要一定费用。

2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl/tls加密传输协议。

3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。

4、http的连接很简单，是无状态的；HTTPS协议是由SSL/TLS+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

HTTPS的主干层次介绍

这部分内容作为前提点缀，如果你是初次了解HTTPS，看不懂这里不要紧，只要把文章后面看完，再回过头来看这里的内容，就能恍然大悟了。

第一层：HTTPS本质上是为了实现加密通信，理论上，加密通信就是双方都持有一个对称加密的秘钥，第二就可以安全通信了

但是，无论这个最初的秘钥是由客户端传给服务端，还是服务端传给客户端，都是明文传输，中间人都可以知道。那就让这个过程变成密文就好了呗，而且还得是中间人解不开的密文。

第二层：使用非对称加密 加密客户端与服务端协商生成对称秘钥之前各种盐值、种子。

但是，在使用非对称加密秘钥之前，比如由服务端生成非对称秘钥，它需要将生成的公钥给到客户端，这个时候公钥就会在网络中明文传输，任何人都可以更改，会有中间人攻击的问题。因此，只能引入公信机构CA，使我们传输自己的公钥时可以保证不会被篡改！

第三层：服务端把自己的公钥给 CA，让 CA 用 CA 的私钥加密，第二返回加密结果（可以用CA的公钥解密，如果要篡改结果，必须再次用 CA 的私钥加密，由于中间人没法获取私钥，所以无法篡改）。

客户端在使用HTTPS方式与Web服务器通信时的步骤

　（1）客户使用https的URL访问Web服务器，要求与Web服务器建立SSL连接。

　（2）Web服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端。

　（3）客户端的浏览器与Web服务器开始协商SSL/TLS连接的安全等级，也就是信息加密的等级。

　（4）客户端的浏览器根据双方同意的安全等级，建立会话密钥，第二利用网站的公钥将会话密钥加密，并传送给网站。

　（5）Web服务器利用自己的私钥解密出会话密钥。

　（6）Web服务器利用会话密钥加密与客户端之间的通信。

尽管HTTPS并非绝对安全，掌握根证书的机构、掌握加密算法的组织同样可以进行中间人形式的攻击，但HTTPS仍是现行架构下最安全的解决方案，他大幅增加了中间人攻击的成本

CA证书的申请及其使用过程

上面客户端使用HTTPS与服务器通信中使用到了CA认证，这里可能大家会问为什么不直接使用非对称加密的形式直接进行，第一这里先介绍下非对称加密。

非对称加密：客户端和服务端均拥有一个公有密匙和一个私有密匙。公有密匙可以对外暴露，而私有密匙只有自己可见。

使用公有密匙加密的消息，只有对应的私有密匙才能解开。反过来，使用私有密匙加密的消息，只有公有密匙才能解开。这样客户端在发送消息前，先用服务器的公匙对消息进行加密，服务器收到后再用自己的私匙进行解密。

非对称加密的优点：

非对称加密采用公有密匙和私有密匙的方式，解决了http中消息保密性问题，而且使得私有密匙泄露的风险降低。

因为公匙加密的消息只有对应的私匙才能解开，所以较大程度上保证了消息的来源性以及消息的准确性和完整性。

非对称加密的缺点：

非对称加密时需要使用到接收方的公匙对消息进行加密，但是公匙不是保密的，任何人都可以拿到，中间人也可以。那么中间人可以做两件事，第一件是中间人可以在客户端与服务器交换公匙的时候，将客户端的公匙替换成自己的。这样服务器拿到的公匙将不是客户端的，而是中间人的。服务器也无法判断公匙来源的正确性。第二件是中间人可以不替换公匙，但是他可以截获客户端发来的消息，第二篡改，第二用服务器的公匙加密再发往服务器，服务器将收到错误的消息。

非对称加密的性能相对对称加密来说会慢上几倍甚至几百倍，比较消耗系统资源。正是因为如此，https将两种加密结合了起来。

为了应对上面非对称加密带来的问题，我们就引入了数字证书与数字签名

CA 签发证书的过程，如上图左边部分：

⾸先 CA 会把持有者的公钥、⽤途、颁发者、有效时间等信息打成⼀个包，第二对这些信息进⾏ Hash 计算， 得到⼀个 Hash 值；

第二 CA 会使⽤⾃⼰的私钥将该 Hash 值加密，⽣成 Certificate Signature，也就是 CA 对证书做了签名；

最后将 Certificate Signature 添加在⽂件证书上，形成数字证书；

客户端校验服务端的数字证书的过程，如上图右边部分：

⾸先客户端会使⽤同样的 Hash 算法获取该证书的 Hash 值 H1；

通常浏览器和**作系统中集成了 CA 的公钥信息，浏览器收到证书后可以使⽤ CA 的公钥解密 Certificate Signature 内容，得到⼀个 Hash 值 H2 ；

最后⽐较 H1 和 H2，如果值相同，则为可信赖的证书，否则则认为证书不可信。

故CA认证介入我们的HTTPS连接的过程如下：

1、服务器拥有自己的私钥与公钥

2、服务器将公钥交给CA认证机构，请求给予一份数字证书

3、CA认证机构生成数字证书，并颁发给服务器

4、服务器将带有公钥信息的数字证书发给客户端

5、进入客户端生成对称密钥再进行对接的过程……

关于证书链

事实上，证书的验证过程中还存在⼀个证书信任链的问题，因为我们向 CA 申请的证书⼀般不是根证书签发的， ⽽是由中间证书签发的，⽐如百度的证书，从下图你可以看到，证书的层级有**：

对于这种**层级关系的证书的验证过程如下：

客户端收到 baidu.com 的证书后，发现这个证书的签发者不是根证书，就⽆法根据本地已有的根证书中的公钥去验证 baidu.com 证书是否可信。于是，客户端根据 baidu.com 证书中的签发者，找到该证书的颁发机构 是 “GlobalSign Organization Validation CA – SHA256 – G2”，第二向 CA 请求该中间证书。

请求到证书后发现 “GlobalSign Organization Validation CA – SHA256 – G2” 证书是由 “GlobalSign Root CA” 签发的，由于 “GlobalSign Root CA” 没有再上级签发机构，说明它是根证书，也就是⾃签证书。应⽤软件会 检查此证书有否已预载于根证书清单上，如果有，则可以利⽤根证书中的公钥去验证 “GlobalSign Organization Validation CA – SHA256 – G2” 证书，如果发现验证通过，就认为该中间证书是可信的。

“GlobalSign Organization Validation CA – SHA256 – G2” 证书被信任后，可以使⽤ “GlobalSign Organization Validation CA – SHA256 – G2” 证书中的公钥去验证 baidu.com 证书的可信性，如果验证通过，就可以信任 baidu.com 证书。

在这四个步骤中，最开始客户端只信任根证书 GlobalSign Root CA 证书的，第二 “GlobalSign Root CA” 证书信任 “GlobalSign Organization Validation CA – SHA256 – G2” 证书，⽽ “GlobalSign Organization Validation CA – SHA256 – G2” 证书⼜信任 baidu.com 证书，于是客户端也信任 baidu.com 证书。

总括来说，由于⽤户信任 GlobalSign，所以由 GlobalSign 所担保的 baidu.com 可以被信任，另外由于⽤户信任** 作系统或浏览器的软件商，所以由软件商预载了根证书的 GlobalSign 都可被信任。

SSL与TLS

SSL：（Secure Socket Layer，安**接字层），位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层。SSL通过互相认证、使用数字签名确保完整性、使用加密确保私密性，以实现客户端和服务器之间的安全通讯。该协议由两层组成：SSL记录协议和SSL握手协议。

TLS：(Transport Layer Security，传输层安全协议)，用于两个应用程序之间提供保密性和数据完整性。该协议由两层组成：TLS记录协议和TLS握手协议。TLS是HTTP与TCP协议之间的一层，通常TLS发生在TCP三次握手之后，此时进行TLS四次握手，第二再进行HTTP通信

SSL/TLS历史

1994年，NetScape公司设计了SSL协议（Secure Sockets Layer）的1.0版，但是未发布。

1995年，NetScape公司发布SSL 2.0版，很快发现有严重漏洞。

1996年，SSL 3.0版问世，得到大规模应用。

1999年，互联网标准化组织ISOC接替NetScape公司，发布了SSL的升级版TLS 1.0版。

2006年和2008年，TLS进行了两次升级，分别为TLS 1.1版和TLS 1.2版。最新的变动是2011年TLS 1.2的修订版，在2018年也发布了TLS1.3版本。

TLS 1.0通常被标示为SSL 3.1，TLS 1.1为SSL 3.2，TLS 1.2为SSL 3.3。

目前应用的最广泛的 TLS 是 1.2，而之前的协议（TLS1.1/1.0、SSLv3/v2）都已经被认为是不安全的了

SSL/TLS协议的基本过程（TLS1.2）

客户端向服务器端索要并验证公钥。

双方协商生成"对话密钥"。

双方采用"对话密钥"进行加密通信。

上面过程的前两步，又称为"握手阶段"（handshake）

下面是我们本次模拟访问https://www.baidu.com时抓的包，大家可以看到这里面涉及的流程逻辑

1 客户端发出请求（ClientHello）

（1） 支持的协议版本，比如TLS 1.2版。

（2） 一个客户端生成的随机数1，稍后用于生成"对话密钥"。

（3） 【支持的密码套件】支持的加密方法，比如RSA公钥加密。

（4） 支持的压缩方法。

（5） 一个session id，标识是否复用服务器之前的tls连接（需要服务器支持）

2 服务器回应（SeverHello）

（1） 确认使用的加密通信协议版本，比如TLS 1.2版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。

（2） 一个服务器生成的随机数2，稍后用于生成"对话密钥"。

（3） 【确认密码套件】确认使用的加密方法，比如RSA公钥加密，此时带有公钥信息。

（4） 一个session id（若同意复用连接）

3 服务器回应（Server Certificate）

（1）服务器证书（该证书即包含服务器公钥）。

4 服务器回应（Server Key Exchange）

（1）服务器算法变更通知，服务端给客户端一个用于 ECDHE 算法的公钥

5 服务器回应（Server CertificateRequest）

（1）请求客户端证书，此案例中没有，一般银行等需要客户端也加密的才有，比如 U 盾。

6 服务器回应（Server ServerHelloDone）- 标识着 serverHello 这个握手过程结束了。

7 客户端回应（Client Certificate）- 回应客户端证书，本案例不涉及

8 客户端回应（ClientKeyExchange）

（1）客户端在验证完服务器的证书后，生成一个新的随机数（pre_master），通过服务器的公钥加密后发给服务器。

到这里，服务端与客户端将 生成最终通信的对称加密秘钥：master_secret

计算过程根据上面得到的三个随机数：

随机数 1（客户端随机数）：在 ClientHello 消息里，由客户端生成的随机数1

随机数 2（服务端随机数）：在 ServerHello 消息里，由服务端生成的随机数2

随机数 3（pre_master)：通过秘钥交换算法 ECDHE 计算出的，我们叫它 pre_master。

最终的对称加密秘钥 master_secret，就是根据这三个随机数共同计算出来的。

9 客户端回应（Client CertificateVerif）

（1）验证客户端证书有效性，本次不涉及

10 客户端回应（Client ChangeCipherSpec）

（1）秘钥改变通知，此时客户端已经生成了 master_secret，之后的消息将都通过 master secret 来加密。

11 客户端回应（Client Finish）

（1） 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。

12 服务器回应（Server ChangeCipherSpec）

（1）秘钥改变通知，此时服务端也已经生成了 master_secret 了，后面的通信都用此值加密。

13 服务器回应（Server Finish）

（1）同 Client Finish，服务器端发送握手结束通知，同时会带上前面所发内容的hash签名到客户端，保证前面通信数据的正确性。

上述流程简易版（不包含验证客户端证书）：

1. client –> server ClientHello

客户端生成随机数，并发送一组密码学套件供服务端选

2. server–> client ServerHello

服务端生成随机数，并从上述密码学套件组里选一个

3. server–> client Certificate

服务端发给客户端证书

4. server–> client ServerKeyExchange

服务端发给客户端秘钥交换算法所需的值

5. server–> client ServerHelloDone

服务端 hello 阶段结束

6. client –> server ClientKeyExchange

客户端发给服务端秘钥交换算法所需的值pre_master

7. client –> server ChangeCipherSpec

客户端告诉服务端，我已经知道秘钥了，之后的消息我就都加密发送了。

8. client –> server Finish

结束并验证

7. server –> server ChangeCipherSpec

服务端告诉客户端，我已经知道秘钥了，之后的消息我就都加密发送了。

9. server–> client Finish

结束并验证

图片流程

为什么一定要用三个随机数，来生成"会话密钥"呢？

"不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。

对于RSA密钥交换算法来说，pre-master-key本身就是一个随机数，再加上hello消息中的随机数，三个随机数通过一个密钥导出器最终导出一个对称密钥。

pre master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre master secret就有可能被猜出来，那么仅适用pre master secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。"

此外，如果前一步，服务器要求客户端证书，客户端会在这一步发送证书及相关信息。

以上介绍为TLS1.2的版本，其他TLS如1.0版本的流程会稍有不同，但大致逻辑是一样的。

TLS 1.2 转换流程逻辑也可以参考：26 | 信任始于握手：TLS1.2连接过程解析-极客时间

更新的 TLS 1.3也可以参考：27 | 更好更快的握手：TLS1.3特性解析-极客时间

TLS的主要目标是使SSL更安全，并使协议的规范更精确和完善。TLS 在SSL v3.0 的基础上，提供了以下增强内容：

　　1）更安全的MAC算法

　　2）更严密的警报

　　3）“灰**域”规范的更明确的定义

TLS对于安全性的改进点如下（了解即可）：

1）对于消息认证使用密钥散列法：TLS 使用“消息认证代码的密钥散列法”（HMAC），当记录在开放的网络（如因特网）上传送时，该代码确保记录不会被变更。SSLv3.0还提供键控消息认证，但HMAC比SSLv3.0使用的（消息认证代码）MAC 功能更安全。

2）增强的伪随机功能（PRF）：PRF生成密钥数据。在TLS中，HMAC定义PRF。PRF使用两种散列算法保证其安全性。如果任一算法暴露了，只要第二种算法未暴露，则数据仍然是安全的。

3）改进的已完成消息验证：TLS和SSLv3.0都对两个端点提供已完成的消息，该消息认证交换的消息没有被变更。然而，TLS将此已完成消息基于PRF和HMAC值之上，这也比SSLv3.0更安全。

4）一致证书处理：与SSLv3.0不同，TLS试图指定必须在TLS之间实现交换的证书类型。

5）特定警报消息：TLS提供更多的特定和附加警报，以指示任一会话端点检测到的问题。TLS还对何时应该发送某些警报进行记录。

SSL/TLS 密码套件

浏览器和服务器在使用 TLS 建立连接时需要选择一组恰当的加密算法来实现安全通信，这些算法的组合被称为“密码套件”（cipher suite，也叫加密套件）。上述Client/Server Hello过程中就涉及密码套件的约定流程。

TLS 的密码套件命名格式为：密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法

如对于套件：“ECDHE-RSA-AES256-GCM-SHA384”，其解释为：握手时使用 ECDHE 算法进行密钥交换，用 RSA 签名和身份认证，握手后的通信使用 AES 对称算法，密钥长度 256 位，分组模式是 GCM，摘要算法 SHA384 用于消息认证和产生随机数。

HTTPS很安全，很古老也很成熟，为什么一直到今天我们还有66%的网站不支持HTTPS呢？

1、慢，HTTPS未经任何优化的情况下要比HTTP慢几百毫秒以上，特别在移动端可能要慢500毫秒以上，关于HTTPS慢和如何优化已经是一个非常系统和复杂的话题

2、贵，特别在计算性能和服务器成本方面。HTTPS为什么会增加服务器的成本？相信大家也都清楚HTTPS要额外计算，要频繁地做加密和解密**作，几乎每一个字节都需要做加解密，这就产生了服务器成本

另外还有:

1、大量的计算。SSL的每一个字节都涉及到较为复杂的计算。即使是clientHello，也需要在握手完成时做校验。

2、TLS协议的封装和解析。HTTPS所有数据都是按照TLS record格式进行封装和解析的。

3、协议的网络交互。从TLS的握手过程可以看出，即使不需要进行任何计算，TLS的握手也需要至少1个RTT（round trip time)以上的网络交互。

RTT(Round-Trip Time): 往返时延。在计算机网络中它是一个重要的性能指标，表示从发送端发送数据开始，到发送端收到来自接收端的确认（接收端收到数据后便立即发送确认），总共经历的时延。

4、HTTPS降低用户访问速度（需多次握手）

5、网站改用 HTTPS 以后，由 HTTP 跳转到 HTTPS 的方式增加了用户访问耗时（多数网站采用 301、302 跳转）

6、HTTPS 涉及到的安全算**消耗 CPU 资源，需要增加服务器资源（https 访问过程需要加解密）

HTTPS涉及的计算环节

1、非对称密钥交换。比如RSA, Diffie-Hellman, ECDHE.这类算法的主要作用就是根据客户端和服务端不对称的信息，经过高强度的密钥生成算法，生成对称密钥，用于加解密后续应用消息。

2、对称加解密。服务端使用密钥A对响应内容进行加密，客户端使用相同的密钥A对加密内容进行解密，反之亦然。

3、消息一致性验证。每一段加密的内容都会附加一个MAC消息，即消息认证码。简单地说就是对内容进行的安全哈希计算，接收方需要校验MAC码。

4、证书签名校验。这个阶段主要发生在客户端校验服务端证书身份时，需要对证书签名进行校验，确保证书的真实性。

以上图片文字解释来源：HTTP与HTTPS对访问速度（性能）的影响 – 宋可欣 – 博客园

OCSP(Online Certificate Status Protocol，在线证书状态协议)

HTTPS的缺点

虽然说HTTPS有很大的优势，但其相对来说，还是存在不足之处的：

（1）HTTPS协议握手阶段比较费时，会使页面的加载时间延长近50%，增加10%到20%的耗电；

（2）HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；

（3）SSL证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。

（4）SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗。

（5）HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。

实践中建议保留http。所以我们在切换的时候可以做http和https的兼容，具体实现方式是，去掉页面链接中的http头部，这样可以自动匹配http头和https头。例如：将http://www.baidu.com改为//www.baidu.com。第二当用户从http的入口进入访问页面时，页面就是http，如果用户是从https的入口进入访问页面，页面即使https的

如何优化HTTPS的速度

HTTPS连接大致可以划分为两个部分：第一个是建立连接时的非对称加密握手，第二个是握手后的对称加密报文传输。

由于目前流行的 AES、ChaCha20 性能都很好，还有硬件优化，报文传输的性能损耗可以说是非常地小，小到几乎可以忽略不计了。所以，通常所说的“HTTPS 连接慢”指的就是刚开始建立连接的那段时间。

在 TCP 建连之后，正式数据传输之前，HTTPS 比 HTTP 增加了一个 TLS 握手的步骤，这个步骤最长可以花费两个消息往返，也就是 2-RTT（TLS1.3只需1-RTT）。而且在握手消息的网络耗时之外，还会有其他的一些“**”消耗，比如：

产生用于密钥交换的临时公私钥对（ECDHE）；

验证证书时访问 CA 获取 CRL 或者 OCSP；

非对称加密解密处理“Pre-Master”。

1、HSTS重定向技术

HSTS（HTTP Strict Transport Security，HTTP 严格传输安全）技术，启用HSTS后，将保证浏览器始终连接到网站的 HTTPS 加密版本。这相当于告诉浏览器：我这个网站必须严格使用 HTTPS 协议，在半年之内（182.5 天）都不允许用 HTTP，你以后就自己做转换吧，不要再来麻烦我了。

1. 用户在浏览器里输入 HTTP 协议进行访问时，浏览器会自动将 HTTP 转换为 HTTPS 进行访问，确保用户访问安全；

2. 省去301跳转的出现，缩短访问时间；

3. 能阻止基于 SSL Strip 的中间人攻击，万一证书有错误，则显示错误，用户不能回避警告，从而能够更加有效安全的保障用户的访问。

2、TLS握手优化

在传输应用数据之前，客户端必须与服务端协商密钥、加密算法等信息，服务端还要把自己的证书发给客户端表明其身份，这些环节构成 TLS 握手过程。

使用 ECDHE 椭圆曲线密码套件，可以节约带宽和计算量，还能实现“False Start”，采用 False Start （抢先开始）技术，浏览器在与服务器完成 TLS 握手前，就开始发送请求数据，服务器在收到这些数据后，完成 TLS 握手的同时，开始发送响应数据。

开启 False Start 功能后，数据传输时间将进一步缩短。

3、Session Identifier（会话标识符）复用

如果用户的一个业务请求包含了多条的加密流，客户端与服务器将会反复握手，必定会导致更多的时间损耗。或者某些特殊情况导致了对话突然中断，双方就需要重新握手，增加了用户访问时间。

（1）服务器为每一次的会话都生成并记录一个 ID 号，第二发送给客户端；

（2）如果客户端发起重新连接，则只要向服务器发送该 ID 号；

（3）服务器收到客户端发来的 ID 号，第二查找自己的会话记录，匹配 ID 之后，双方就可以重新使用之前的对称加密秘钥进行数据加密传输，而不必重新生成，减少交互时间（只用一个消息往返就可以建立安全连接）。

但它也有缺点，服务器必须保存每一个客户端的会话数据，对于拥有百万、千万级别用户的网站来说存储量就成了大问题，加重了服务器的负担。于是又出现了第二种“Session Ticket”的方案。

它有点类似 HTTP 的 Cookie，存储的责任由服务器转移到了客户端，服务器加密会话信息，用“New Session Ticket”消息发给客户端，让客户端保存。重连的时候，客户端使用扩展“session_ticket”发送“Ticket”而不是“Session ID”，服务器解密后验证有效期，就可以恢复会话，开始加密通信。不过“Session Ticket”方案需要使用一个固定的密钥文件（ticket_key）来加密 Ticket，为了防止密钥被破解，保证“前向安全”，密钥文件需要定期轮换，比如设置为一小时或者一天。

4、开启OSCP Stapling（OSCP装订），提高TLS握手效率

客户端的证书验证其实是个很复杂的**作，除了要公钥解密验证多个证书签名外，因为证书还有可能会被撤销失效，客户端有时还会再去访问 CA，下载 CRL （Certificate revocation list，证书吊销列表，用于确认证书是否有效，体积较大，现基本不用）或者 OCSP 数据，这又会产生 DNS 查询、建立连接、收发数据等一系列网络通信，增加好几个 RTT。

采用OCSP Stapling ，提升 HTTPS 性能。服务端主动获取 OCSP 查询结果并随着证书一起发送给客户端，从而客户端可直接通过 Web Server 验证证书，提高 TLS 握手效率。

服务器模拟浏览器向 CA 发起请求，并将带有 CA 机构签名的 OCSP 响应保存到本地，第二在与客户端握手阶段，将 OCSP 响应下发给浏览器，省去浏览器的在线验证过程。由于浏览器不需要直接向 CA 站点查询证书状态，这个功能对访问速度的提升非常明显。

5、完全前向加密PFS，保护用户数据，预防私钥泄漏

非对称加密算法 RSA，包含了公钥、私钥，其中私钥是保密不对外公开的，由于此算法既可以用于加密也可以用于签名，所以用途甚广，但是还是会遇到一些问题：

（1） 假如我是一名黑客，虽然现在我不知道私钥，但是我可以先把客户端与服务器之前的传输数据（已加密）全部保存下来

（2）如果某一天，服务器维护人员不小心把私钥泄露了，或者服务器被我攻破获取到了私钥

（3）那我就可以利用这个私钥，破解掉之前已被我保存的数据，从中获取有用的信息，即所谓的“今日截获，明日破解”。

所以为了防止上述现象发生，我们必须保护好自己的私钥。

如果私钥确实被泄漏了，那我们改如何补救呢？那就需要PFS（perfect forward secrecy）完全前向保密功能，此功能用于客户端与服务器交换对称密钥，起到前向保密的作用，也即就算私钥被泄漏，黑客也无法破解先前已加密的数据。维基解释是：长期使用的主密钥泄漏不会导致过去的会话密钥泄漏

实现此功能需要服务器支持以下算法和签名组合：

（1）ECDHE 密钥交换、RSA 签名；

（2）ECDHE 密钥交换、ECDSA 签名；

ECDHE 算法在每次握手时都会生成一对临时的公钥和私钥，每次通信的密钥对都是不同的，也就是“一次一密”，即使黑客花大力气破解了这一次的会话密钥，也只是这次通信被攻击，之前的历史消息不会受到影响，仍然是安全的。

使用ECDHE算法的TLS交换过程具有如下优点：运算速度快，安全性高，还支持“False Start”，能够把握手的消息往返由 2-RTT 减少到 1-RTT

所以现在主流的服务器和浏览器在握手阶段都已经不再使用 RSA，改用 ECDHE，而 TLS1.3 在协议里明确废除 RSA 和 DH 则在标准层面保证了“前向安全”。

拓展知识：

版本服务器关闭连接

加我QQ 给你搞定

版本服务器关闭连接

查看下引擎上面的人物** 看看上面的注册角色打勾了没有