HTTPS是常见的HTTP安全版本，得到了广泛的应用。HTTPS将HTTP协议与一组强大的对称、非对称和基于证书的加密技术结合在一起，使得HTTPS安全且灵活，很容易在处于无序状态的、分散的全球互联网上进行管理。HTTPS 在 HTTP 与 TCP 层之间加入了 SSL/TLS 协议。

一、特点

• 采用混合加密——达成信息加密——规避窃听风险——实现机密性，
• 采用摘要算法——达成校验机制——规避篡改风险——实现报文完整性，
• 采用数字证书——达成身份证书——规避冒充风险——实现端点鉴别，
• 因为需要进行加密解密等过程，因此速度会更慢；
• 需要支付证书授权的高额费用。

二、HTTP与HTTPS的区别

• 安全性

  • HTTP 是超文本传输协议，信息是明文传输，存在安全风险的问题。
  • HTTPS 则解决 HTTP 不安全的缺陷，在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输。

• 连接建立过程

  • HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输。
  • 而 HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。

• 端口号

  • HTTP 的端口号是 80，HTTPS 的端口号是 443。

• HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。

三、TLS握手过程

SSL/TLS 协议基本流程：

• 客户端向服务器索要并验证服务器的证书。
• 双方协商生产「会话秘钥」。
• 双方采用「会话秘钥」进行加密通信。

前两步也就是 SSL/TLS 的建立过程，也就是握手阶段。

通常经过「四个消息」就可以完成 TLS 握手，也就是需要 2个 RTT 的时延，然后就可以在安全的通信环境里发送 HTTP 报文，实现 HTTPS 协议。HTTPS 是应用层协议，需要先完成 TCP 连接建立，然后走 TLS 握手过程后，才能建立通信安全的连接。SSL/TLS 的「握手阶段」涉及四次通信： 

 第一次握手：ClientHello

首先，由客户端向服务器发起加密通信请求，也就是 ClientHello 请求。在这一步，客户端主要向服务器发送以下信息：

• 客户端支持的 SSL/TLS 协议版本，如 TLS 1.2 版本。

• 客户端生产的随机数（Client Random），后面用于生产「会话秘钥」。

• 客户端支持的密码套件列表，如 RSA 加密算法。

第二次握手：ServerHello

服务器收到客户端请求后，向客户端发出响应，也就是 SeverHello。服务器回应如下内容：

• 确认 SSL/ TLS 协议版本，如果浏览器不支持，则关闭加密通信。

• 服务器生产的随机数（Server Random），后面用于生产「会话秘钥」。

• 确认的密码套件列表，如 RSA 加密算法。

• 服务器的数字证书

• Server Hello Done：服务端握手结束通知

第三次握手：客户端回应

• 客户端验证服务器的数字证书。

• 若证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送一个随机数（pre-master key），该随机数会被服务器公钥加密。

• 服务端收到后，用私钥解密，得到客户端发来的随机数 (pre-master)。

• 至此，客户端和服务端共享了三个随机数，分别是 Client Random、Server Random、pre-master。

• 双方根据已经得到的三个随机数，生成会话密钥（Master Secret），它是对称密钥，用于对后续的 HTTP 请求/响应的数据加解密。

• 生成密钥后，客户端发送加密通信算法改变通知（Change Cipher Spec），表示随后的信息都将用会话秘钥加密通信。

• 握手结束通知（Encrypted Handshake Message（Finishd）），表示客户端的握手阶段已经结束。这一项同时把之前所有内容发生的数据做个摘要，用来供服务端校验。

前两次握手明文，第三次握手中客户端发送的随机数使用公钥加密，服务端用私钥解密，再与前两次的随机数一同计算出对称密钥。之后全是对称密钥加密的密文。

第四次握手：服务器的最后回应

服务器收到客户端的信息后用私钥解密得到第三个随机数（pre-master key），再通过协商的加密算法，计算出本次通信的会话秘钥。然后向客户端发出最后的信息：

（1）加密通信算法改变通知（Change Cipher Spec），表示随后的信息都将用「会话秘钥」加密通信。

（2）握手结束通知（Encrypted Handshake Message（Finishd）），表示服务器的握手阶段已经结束。这一项同时把之前所有内容发生的数据做个摘要，用来供客户端校验。

至此，整个 SSL/TLS 的握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的 HTTP 协议，只不过用「会话秘钥」加密内容。

四、加密算法

对称密钥加密

对称密钥加密（Symmetric-Key Encryption），加密和解密使用同一密钥。

• 优点：运算速度快；
• 缺点：无法安全地将密钥传输给通信方。

非对称密钥加密

非对称密钥加密，又称公开密钥加密（Public-Key Encryption），加密和解密使用不同的密钥。公开密钥所有人都可以获得，通信发送方获得接收方的公开密钥之后，就可以使用公开密钥进行加密，接收方收到通信内容后使用私有密钥解密。

非对称密钥除了用来加密，还可以用来进行签名。因为私有密钥无法被其他人获取，因此通信发送方使用其私有密钥进行签名，通信接收方使用发送方的公开密钥对签名进行解密，就能判断这个签名是否正确。

• 优点：可以更安全地将公开密钥传输给通信发送方；
• 缺点：运算速度慢

混合加密

HTTPS通过混合加密的方式可以保证信息的机密性，解决了窃听的风险,采用的是对称加密和非对称加密结合的「混合加密」方式：

• 在通信建立前采用非对称加密的方式交换「会话秘钥」，后续就不再使用非对称加密。
• 在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据。

采用「混合加密」的方式的原因：

• 对称加密只使用一个密钥，运算速度快，密钥必须保密，无法做到安全的密钥交换。
• 非对称加密使用两个密钥：公钥和私钥，公钥可以任意分发而私钥保密，解决了密钥交换问题但速度慢。

 摘要算法

 摘要算法用来实现完整性，能够为数据生成独一无二的「指纹」，用于校验数据的完整性，解决篡改的风险。客户端在发送明文之前会通过摘要算法算出明文的摘要，发送的时候把「摘要 + 明文」一同 加密成密文后，发送给服务器，服务器解密后，用相同的摘要算法算出发送过来的明文，通过比较客户端携带的摘要和当前算出的摘要做比较，若相同，说明数据是完整的。

五、数字证书

数字证书的作用，是用来认证公钥持有者的身份，以防止第三方进行冒充。说简单些，证书就是用来告诉客户端，该服务端是否是合法的，只有证书合法，才代表服务端身份是可信的。为了让服务端的公钥可信任，服务端的证书都是由 CA （Certificate Authority，证书认证机构）签名的，CA 就是网络世界里的公安局、公证中心，具有极高的可信度，所以由它来给各个公钥签名，信任的一方签发的证书，那必然证书也是被信任的。之所以要签名，是因为签名的作用可以避免中间人在获取证书时对证书内容的篡改。一个数字证书通常包含了：

• 公钥；
• 持有者信息；
• 证书认证机构（CA）的信息；
• CA 对这份文件的数字签名及使用的算法；
• 证书有效期；
• 其他额外信息；

数字证书签发和验证流程

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

• 首先 CA 会把持有者的公钥、用途、颁发者、有效时间等信息打成一个包，然后对这些信息进行 Hash 计算，得到一个 Hash 值；
• 然后 CA 会使用自己的私钥将该 Hash 值加密，生成 Certificate Signature，也就是 CA 对证书做了签名；
• 最后将 Certificate Signature 添加在文件证书上，形成数字证书；

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

• 首先客户端会使用同样的 Hash 算法获取该证书的 Hash 值 H1；
• 通常浏览器和操作系统中集成了 CA 的公钥信息，浏览器收到证书后可以使用 CA 的公钥解密 Certificate Signature 内容，得到一个 Hash 值 H2 ；
• 最后比较 H1 和 H2，如果值相同，则为可信赖的证书，否则则认为证书不可信。

 证书链

 证书的验证过程中还存在一个证书信任链的问题，因为向 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 都可被信任。操作系统里一般都会内置一些根证书。这样的一层层地验证就构成了一条信任链路，整个证书信任链验证流程如下图所示：