网络知识详解之：HTTPS通信原理剖析（对称、非对称加密、数字签名、数字证书）

计算机网络相关知识体系详解

• 网络知识详解之：TCP连接原理详解
• 网络知识详解之：HTTP协议基础
• 网络知识详解之：HTTPS通信原理剖析（对称、非对称加密、数字签名、数字证书）
• 网络知识详解之：CA证书制作实战（Nginx数字证书实战）
• 网络知识详解之：网络攻击与安全防护
  

  文章目录

  • 网络知识详解之：HTTPS通信原理剖析（对称、非对称加密、数字签名、数字证书）
  • • 概念
    • 架构图
    • HTTPS工作原理
    • • 对称加密算法
      • 非对称加密算法
      • 数字签名
      • • 原理
        • 数字签名如何生成
        • 校验数字签名流程
        • 问题
      • 数字证书
      • • 原理
        • CA数字证书认证中心
        • 基于数字证书的通信
      • 数字签名和数字证书的区别
      • 完整的 HTTPS 的通信
      • • TLS握手过程
        • session的恢复

概念

HTTPS（HyperText Transfer Protocol over Secure Socket Layer）超文本传输安全协议， 近两年Google、Baidu、Facebook 等这样的互联网巨头，不 而合地开始大力推行 HTTPS， 国内外的大型互联网公司很多也都已经启用了全站 HTTPS，这也是未来互联网发展的趋势。

为鼓励全球网站的 HTTPS 实现，一些互联网公司都提出了自己的要求：

• Google 已调整搜索引擎算法，让采用 HTTPS 的网站在搜索中排名更靠前；
• 从 2017 年开始，Chrome 浏览器已把采用 HTTP 协议的网站标记为不安全 网站；
• 苹果要求 2017 年 App Store 中的所有应用都必须使用 HTTPS 加密连接；
• 当前国内炒的很火热的微信小程序也要求必须使用 HTTPS 协议；
• 新一代的 HTTP/2 协议的支持需以 HTTPS 为基础。

HTTPS的好处与作用在于：

作用

• 对数据进行加密，并建立一个信息安全通道，来保证传输过程中的数据安全
• 对网站服务器进行真实身份认证。

使用特征

我们经常会在Web的登录页面和购物结算界面等使用HTTPS通信。

• 使用HTTPS通信时，不再用 http:// ，而是改用 https:// 。
• 当浏览器访问HTTPS通信有效的Web网站时，浏览器的地址栏内会出现一个 带锁的标记。

架构图

HTTPS并非是应用层一个新的协议，通常 HTTP 直接和 TCP 通信，HTTPS则先 和安全层（SSL/TLS）通信，然后安全层再和 TCP 层通信。

SSL/TLS协议就是为了解决上面提到的HTTP存在的问题而生的，下面我们来看 一下它是怎么解决的：

1. 所有的信息都是加密传输的，第三方无法窃听
2. 配备身份验证（服务端程序），防止身份被冒充
3. 具有校验机制，一旦被篡改，通信双方会立刻发现

HTTPS工作原理

HTTPS是身披SSL/TLS外壳的HTTP

TLS全称传输层安全协议Transport Layer Security Protocol，TLS/SSL是一种加密通道的规范。

TLS协议是由TLS记录协议（TLS record Protocol）和TLS握手协议（TLS handshake Protocol）这两层协议叠加而成的。

• 记录协议：TLS Record protocol
  • TLS记录协议位于TLS握手协议的下层，是负责使用对称密码对消息进行加密通信的部分
  • 加密使用的密钥是通过握手协议在服务器和客户端之间协商决定的
• 握手协议：TLS Handshaking Protocols由TLS Change Ciper Spec Protocol（密码规格变更协议）和TLS Alert Protocol（警告协议）组成
  • 负责在客户端和服务器之间协商决定密码算法和共享密钥。
  • 密码规格变更协议负责向通信对象传达变更密码方式的信号，当协议中途发生错误时，就会通过警告协议传达给对方。
  • 警告协议是TLS握手协议负责在发送错误时将错误传达给对方。

HTTPS和HTTP协议相比提供了

1. 数据完整性： 内容传输经过完整性校验
2. 数据隐私性： 内容经过对称加密，每个连接生成一个唯一的加密密钥
3. 身份认证： 第三方无法伪造服务端（客户端）身份

其中，数据完整性和隐私性由TLS Record Protocol保证，身份认证由TLS Handshaking Protocols实现。

理解HTTPS前需要理解这些概念：对称加密、非对称加密、摘要算法、数字签 名、证书、认证中心（CA - Certificate Authority）

对称加密算法

定义

采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密，这种加密方法称为对称加密，也称为单密钥加密。

要素

原文、密钥、算法

密钥：在密码学中是一个定长的字符串、需要根据加密算法确定其长度

工作过程

对称加密通常使用的是相对较小的密钥，一般小于256 bit。因为密钥越大，加密越强，但加密与解密的过程越慢。如果你只用1 bit来做这个密钥，那黑客们 可以先试着用0来解密，不行的话就再用1解；但如果你的密钥有1 MB大，黑客 们可能永远也无法破解，但加密和解密的过程要花费很长的时间。密钥的大小既要照顾到安全性，也要照顾到效率。

加密：明文 + 密钥 -> 密文
解密：密文 + 密钥 -> 明文

算法

• DES（Data Encryption Standard）：数据加密标准（现在用的比较少，因为它的加密强度不够，能够暴力破解）
• 3DES：原理和DES几乎是一样的，只是使用3个密钥，对相同的数据执行三次加密，增强加密强度。(缺点：要维护3个密钥，大大增加了维护成本)
• AES（Advanced Encryption Standard）：高级加密标准，用来替代原先的DES，目前美国国家安全局使用的，苹果的钥匙串访问采用的就AES加密。是现在公认的最安全的加密方式，是对称密钥加密中最流行的算法。

AES128和AES256主要区别是密钥长度不同（分别是128bits,256bits)、加密处理轮数不同（分别是10轮，14轮），后者强度高于前者。

特点

优点：算法公开、计算量小、加密速度快、加密效率高。

缺点：相对来说不算特别安全，只有一把钥匙，密文如果被拦截，且密钥也 被劫持，那么，信息很容易被破译。

推演

为了防止上述现象的发生，人们想到一个办法：

对传输的信息加密（即使黑 客截获，也无法破解）

加密公式： f1 ( key（密钥），data ) = X（密文） 

解密公式： f2 ( key（密钥），X（密文） ) = data

非对称加密算法

简介

非对称加密是计算机通信安全的基石，保证了加密数据不会被破解。

非对称加密算法需要两个密钥：公开密钥(public key) 和私有密(private key)

公开密钥和私有密钥是一对

特点

如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密。

如果用私有密钥对数据进行加密，只有用对应的公开密钥才能解密。

由于其算法复杂，而使得加密、解密速度没有对称加密解密的速度快。有两种密钥，其中一个是公开的，这样就可以不需要像对称密码那样传输对方的密钥了，这样安全性就大了很多。

常用算法

RSA、DSA、ECDSA

推演 - 非对称加密

公钥加密：f1 ( publicKey，data ) = X
私钥解密：f2 ( privateKey，X ) = data
私钥加密：f3 ( privateKey，data) = X
公钥解密：f1 ( publicKey，X） = data

私钥保存在服务端，公钥保存在客户端，私钥永远不对外暴露

缺陷：

公钥是公开的（也就是黑客也会有公钥），所以第 ④ 步私钥加密的信息，如果被黑客截获，其可以使用公钥进行解密，获取其中的内容。

推演 - 对称加密和非对称加密

非对称加密既然也有缺陷，那我们就将对称加密，非对称加密两者结合起来， 取其精华、去其糟粕，发挥两者的各自的优势

解决问题

这里实际上是通过对称加密和非对称加密的组合使用，解决上面缺陷中提到的在第4步中，黑客可能会利用获取的公钥对响应密文进行解密，导致内容可能被窃听的问题。

解决的办法就是对暴露在外部的公钥进行改造，首先客户端利用公钥加密一串字符串，比如随机数，相当于一个新的密钥。将这个密码保存在本地，并发送给服务端。服务端在接收到这个新的密钥后，用自己的私钥进行解密，同样保存在本地。此时，客户端和服务器分别保存了一个相同的新的密钥。这样的好处是，在第一次客户端和服务器交换这个新的密钥后，之后的所有数据传输都可以通过这个新的密钥来进行加解密了，也就是利用了对称加密的优势，提升了加解密速度。

同时也保证了安全性。因为在第一次客户端利用公钥对新的密钥进行加密再传输到服务器的过程中，由于公钥加密的密文只能通过私钥解密，而私钥只有服务器有，因此这个过程中不会发生被窃取的风险。这里也就利用了非对称加密的优势。而之前缺陷中第4步，由于现在响应的密文是由一个新的密钥进行加密的，无法再用暴露在外部的公钥进行解密，也就解决了第四步中被窃取的风险。

因此，通过上述分析可以发现，这种对称加密+非对称加密的加密算法，充分利用了对称加密和非对称加密算法的优势。其中非对称加密算法的优势利用在于第一次客户端和服务端在彼此交换一个新的密码时使用，保证了这个新的密钥不会被窃取。同时，在之后的数据传输中，客户端和服务端都利用这个新的密钥进行加解密，加快了加解密速度，利用了对称加密的优势。

存在缺陷

报文可能遭篡改问题

通信方身份可能被伪装的问题

解决方案

解决报文可能遭篡改问题——数字签名

解决通信方身份可能被伪装的问题——数字证书

数字签名

原理

在上面讲解非对称加密算法时，由于公钥是暴露在外部的，任何人都可以获取。因此，第三方也能用公钥进行加密，那么如何保证服务端得到的数据是对应客户端发出的呢？

这需要配合数字签名技术。数字签名主要是利用哈希函数对要传递的数据进行运算后得到一个运算结果，将该结果也加密发送给服务端，服务端获取后进行解密，得到运算结果，然后将收到的数据进行相同的哈希运算后的结果进行比较。 由于哈希函数的单向性（不可逆），第三方无法根据公钥解密后的数据（明文的哈希运算结果）反推哈希运算之前的原数据。因此可以保证数据无法被篡改，解决上面缺陷中提到的报文可能遭篡改的问题。

在信息安全中，文件的安全性有两方面的含义：一是不可抵赖性，即文件一定来自于发送者，也就是身份正确；二是不可篡改性，即确信文件并没有中途被篡改，也就是数据完好。

考虑以下的场景：

假设有一天，Jermery收到了一份署名为 Tom 的文件。Jermery 希望能够确认这份文件一定是来自 Tom；另外 Jermery 希望能够确信，这份文件在传输过程中并没有被它人篡改。那么基于非对称密钥算法我们应该怎么做？

在非对称密钥算法中提到，公钥加密的内容使用私钥可以解密。同样的，私钥加密的内容使用公钥也可以解密。因此我们可以很容易想到。如果Tom利用自己手里的私钥对文件进行加密后，传输给 Jermery。Jermery 再通过公钥库中 Tom 的公钥进行解密，则可以证明文件一定是由 Tom 发出（由于只有Tom持有私钥）。另外，因为传输的是密文，如果能够使用公钥解密，同时也证明了文件并没有中途被篡改。这样的做法其实已经同时满足了不可抵赖性和不可篡改性。

然而，由于传输的文件可能很大， 为了证明文件的不可抵赖性和不可篡改性，需要对整个文件进行加密，由于非对称算法效率较低，这样做的代价太大。 因此常规的做法是用到信息摘要和数字签名的方式。

所谓信息摘要，其实就是某种 Hash 算法，将信息明文转化为固定长度的字符， 它具有如下特点：

• 无论输入的消息有多长，计算出来的消息摘要的长度总是固定的；
• 用相同的摘要算法对相同的消息求两次摘要，其结果必然相同；
• 一般地，只要输入的消息不同，对其进行摘要以后产生的摘要消息也几乎不可能相同；
• 消息摘要函数是单向函数，即不可逆的，而无法从摘要中恢复出任何的消息；（当原文用公钥加密后，这一条能保证摘要的泄露（摘要可用公钥解密）不影响原文的安全性）
• 好的摘要算法，没有人能从中找到“碰撞”，虽然“碰撞”是肯定存在的。即对于给定的一个摘要，不可能找到一条信息使其摘要正好是给定的。或者说，无法找到两条消息，是它们的摘要相同。

一般的，我们将信息的摘要也称作信息的指纹。 如同指纹的含义，相同的信息一定会得相同的指纹，而仅通过指纹又无法还原出原始信息。目前主要的摘要算法有 MD5（Message Digest-5）和 SHA1（Secure Hash Algorithm）。

数字签名有两种功能

1. 能确定消息确实是由发送方签名并发出来的，因为别人假冒不了发送方的签名。
2. 数字签名能确定消息的完整性,证明数据是否未被篡改过。

数字签名如何生成

将要发送的数据先用Hash算法（摘要算法、散列算法）生成消息摘要，然后用发送者的私钥加密生成数字签名，与原文一起传送给接收者。

接下来就是接收者校验数字签名的流程了

校验数字签名流程

接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用HASH函数对收到的原文产生一个摘要信息，与上一步得到的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性。

类似md5算法用来判断两个文本是否一样，是否被经过修改。

假设消息传递在客户端、服务器之间发生。

服务器将消息连同数字签名一起发送给客户端

客户端接收到消息后，通过校验数字签名，就可以验证接收到的消息就是服务器发送的。

问题

这个过程的前提是客户端知道服务器的公钥。问题的关键的是，和消息本身一样，公钥不能在不安全的网络中直接发送给客户端，或者说拿到的公钥如何证明是服务器的。 此时就需要引入了证书颁发机构（Certificate Authority，简称CA） ，CA数量并不多，客户端内置了所有受信任CA的证书。

消息摘要算法分为三类：

• MD(Message Digest)：消息摘要算法
• SHA(Secure Hash Algorithm)：安全散列算法
• MAC(Message Authentication Code)：消息认证码

数字证书

数字证书：是一个经证书认证结构数字签名的包含公开密钥、拥有者信息的文件，有点像生活中的身份证、护照等，是由一个官方的证书颁发机构签发的一组数据。这种证书很难伪造，用于使用者的身份证明

实际上，我们使用的证书分很多种类型，SSL证书只是其中的一种，SSL证书负责传输公钥。
我们常见的证书根据用途不同大致有以下几种：

1、SSL证书，用于加密HTTP协议，也就是HTTPS，TLS。如果一个web应用想要升级为https，需要购买证书。

2、代码签名证书，用于签名二进制文件，比如Windows内核驱动，Firefox插件，Java代码签名等等

3、客户端证书，用于加密邮件

4、双因素证书，网银专业版使用的USB Key里面用的就是这种类型的证书

证书中包含：组织信息、域名信息、公钥、证书有效期等信息

原理

数字证书的基本架构是公开密钥PKI，即利用一对密钥实施加密和解密。其中密钥包括私钥和公钥，私钥主要用于签名和解密，由用户自定义，只有用户自己知道；公钥用于签名验证和加密，可被多个用户共享。

数字证书的基本工作原理主要体现在：

第一，发送方在发送信息前，需先与接收方联系，同时利用公钥加密信息，信息在进行传输的过程当中一直是处于密文状态，包括接收方接收后也是加密的，确保了信息传输的单一性，若信息被窃取或截取，也必须利用接收方的私钥才可解读数据，而无法更改数据，这也有利保障信息的完整性和安全性。

第二，数字证书的数据签名类似于加密过程，数据在实施加密后，只有接收方才可打开或更改数据信息，并加上自己的签名后再传输至发送方，而接收方的私钥具唯一性和私密性，这也保证了签名的真实性和可靠性，进而保障信息的安全性。

还是根据上面的场景：

基于数字证书通信时，Tom生成了一对公私钥。Tom将公钥发布在公开的密钥库中。而Jeremy在向 Tom发送加密文件或者验证 Tom签名的文件时，均要从公钥库取到 Tom 的公钥。我们已经知道，一般来说公钥就是一段固定长度的字符串，并没有特定的含义。

这里的Tom的公钥，实际上就表示所属Tom的数字证书。

同时，为了让 Jeremy能够方便的辨别公钥，我们可以考虑对给公钥附加一些信息，例如该公钥使用的算法，该公钥的所有者（主题），该公钥的有效期等一系列属性。这样的数据结构我们称作 PKCS#10 数据包。即：

PKCS#10 数据包 = 公钥 + 算法(RSA) + 有效期 + 主题(持有者信息、公司、版本号等)

例如有一天一个叫做 James的人想冒充 Tom，也生成一对公私钥，并且使用了相同的公钥主题封装为 PKCS#10 数据结构。Jeremy其实并没有办法分辨哪个是真实 Tom的公钥。

CA数字证书认证中心

为了解决这个问题，就需要一个权威的第三方机构，对公钥信息进行认证。就如同对公钥信息文件盖上一个权威的章，防止仿照。这样的权威机构，我们称作 CA (Certificate Authority)，数字证书认证中心。CA 会通过一些手段对公钥持有者以及公钥附加信息进行验证，确保身份无误。

比如上图给出了一个数字证书的实例。从图中可以看出，证书中包含申请者公钥、申请者的组织信息和个人信息、签发机构的信息、有效时间、证书序列号等信息的明文，同时包含一个CA机构的数字签名。 其中签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用CA的私钥对信息摘要进行加密，密文即签名；

那么CA 如何为公钥信息盖章呢？非常简单，就是前文已经提到的数字签名技术。公钥及其附加信息作为证书的内容，CA 为此内容添加一个数字签名，就构成了一个数字证书。步骤如下：

1. CA 机构也持有公钥私钥对（由根 CA 颁发）。CA 会对这份私钥进行特别的保护，严禁泄漏和盗用。
2. Bob 将自己的公钥附加上一系列信息后，形成了 P10 数据包（请求包），并发送给 CA。、
3. CA 机构通过其他一些手段认证 Bob 的身份，然后使用自己的私钥对P10 请求进行签名。（也可能会先对数据进行一些简单修改，如修改有效期或主题等），签名结果，就称作数字证书。

基于数字证书的通信

当有了数字证书后，网络间的通信方式变更为：

用户向web服务器发起一个安全连接的请求服务器返回经过CA认证的数字证书，证书里面包含了服务器的public key。

用户拿到数字证书，怎么确保CA证书不被劫持，黑客完全可以把一个假的CA证书发给Client，进而欺骗Client，用户如何编写证书真伪？

CA的大杀器就是，CA把自己的CA证书集成在了浏览器和操作系统里面。 Client拿到浏览器或者操作系统的时候，已经有了CA证书，没有必要通过网络获取，那自然也不存在劫持的问题。

查看浏览器CA证书：设置–>安全检查–>安全–>管理证书

查看操作系统CA证书：certmgr.msc

Client 读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后利用对应 CA的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即服务器的公开密钥是值得信赖的。

客户端还会验证证书相关的域名信息、有效时间等信息; 客户端会内置信任CA的证书信息(包含公钥)，如果CA不被信任，则找不到对应 CA的证书，证书也会被判定非法。

SSL证书分类：

• DV（域名型SSL）：个人站点
• OV（企业型SSL）：企业官网
• EV（增强型SSL）：对安全需求更强的企业官网、电商、互联网金融网站

数字签名和数字证书的区别

有了数字签名，为什么还需要数字证书呢？数字签名的验证是在收到的文件中进行的，可以用来验证收到的文件是来源于密钥对（公钥+私钥）的持有者。 但是，如何确保此密钥对的持有者就是真实的持有者呢？收到的文件可能来源于第三者。也就是说，如果密钥对被顶替，信息接收方获取的是被掉包的公钥，第三者使用此公钥对应的私钥对文件进行签名，加入冒充的信息发给接收者，那么接收者也能正常解密和验证签名，这就是一个漏洞。即，如何保证公钥是真正的公钥？这就需要数字证书了。

获取数字证书，就是把真正的公钥放到 CA 中，CA 会对公钥持有者进行验证。这样，只要 CA 的权威性得到保障，公钥的真实性也就得到了保障。

完整的 HTTPS 的通信

TLS握手过程

明文----->非对称加密----->对称加密

第一步，浏览器给出TLS协议版本号、一个客户端生成的随机数1（Clientrandom），以及客户端支持的加密方法。（明文通讯）

第二步，服务器确认双方使用的加密方法，并给出数字证书、以及一个服务器生成的随机数2（Server random）。（明文通讯）

第三步，浏览器确认数字证书有效，然后生成一个新的随机数3（Pre-mastersecret），并使用数字证书中的公钥加密这个随机数，发给服务器。（使用非对称加密算法）

浏览器确认数字证书有效：浏览器和操作系统内部内置了很多CA机构的证书，是否篡改、是否在有效期内、域名和访问的网站是否匹配。

第四步，服务端使用自己的私钥，获取客户端发来的随机数（即Premastersecret）。

双方就都有三个一模一样的随机数，前两个是明文发送的，最后客户端生成的这个是使用证书中的公钥密文发送的。

第五步，客户端和服务器根据约定的加密方法，使用前面的三个随机数经过特定的算法，生成"对话密钥"（session key）（相当于生成了一个新的密钥），用来加密接下来的整个对话过程。

对话密钥，又叫做会话密钥，其实就是讲之前通讯中的三个随机数生成一个密钥（对称加密）

三个随机数----->第三个是使用非对称加密---->相同的算法------->会话密钥

第六步：客户端和服务器都会第一次使用会话密钥加密一个消息发送给对方。 (使用对称加密算法来提升通信过程中的加解密性能)

备注：客户端收到服务端发送的Certificate 报文后首先会校验证书的合法性：

• 证书路径信任链逐级校验通过（证书确由可信 CA 认证签发）；
• 签名解密成功（确系证书持有者亲笔）；
• 从签名解析出的摘要和证书公开内容的摘要一致（证书内容完整，未被篡改）；
• 主题子域与 URL 中的 HOST 一致，综上确保访问的网站是来自预期目标服务器且非劫持或钓鱼。

session的恢复

握手阶段用来建立SSL连接。如果出于某种原因，对话中断，就需要重新握手。

这时有两种方法可以恢复原来的session：一种叫做session ID，另一种叫做session ticket。

session ID的思想很简单，就是每一次对话都有一个编号（session ID）。如果对话中断，下次重连的时候，只要客户端给出这个编号，且服务器有这个编号的记录，双方就可以重新使用已有的"对话密钥"，而不必重新生成一把。

上图中，客户端给出session ID，服务器确认该编号存在，双方就不再进行握手阶段剩余的步骤，而直接用已有的对话密钥进行加密通信。

session ID是目前所有浏览器都支持的方法，但是它的缺点在于session ID往往只保留在一台服务器上。所以，如果客户端的请求发到另一台服务器，就无法恢复对话。session ticket就是为了解决这个问题而诞生的，目前只有Firefox和Chrome浏览器支持。

上图中，客户端不再发送session ID，而是发送一个服务器在上一次对话中发送过来的session ticket。这个session ticket是加密的，只有服务器才能解密，其中包括本次对话的主要信息，比如对话密钥和加密方法。当服务器收到sessionticket以后，解密后就不必重新生成对话密钥了。