HTTPS 原理分析

作者：leapmie

来源：https://blog.leapmie.com/archives/418/

这篇干货不错，把HTTPS的原理讲清楚了，而且容易懂，建议大家好好读一下。

#HTTPS

随着 HTTPS 建站的成本下降，现在大部分的网站都已经开始用上 HTTPS 协议。大家都知道 HTTPS 比 HTTP 安全，也听说过与 HTTPS 协议相关的概念有 SSL 、非对称加密、 CA证书等，但对于以下灵魂三拷问可能就答不上了：

1.为什么用了 HTTPS 就是安全的？

2.HTTPS 的底层原理如何实现？

3.用了 HTTPS 就一定安全吗？

本文将层层深入，从原理上把 HTTPS 的安全性讲透。

# HTTPS 的实现原理

大家可能都听说过 HTTPS 协议之所以是安全的是因为 HTTPS 协议会对传输的数据进行加密，而加密过程是使用了非对称加密实现。但其实，HTTPS 在内容传输的加密上使用的是对称加密，非对称加密只作用在证书验证阶段。

HTTPS的整体过程分为证书验证和数据传输阶段，具体的交互过程如下：

① 证书验证阶段

浏览器发起 HTTPS 请求

服务端返回 HTTPS 证书

客户端验证证书是否合法，如果不合法则提示告警

② 数据传输阶段

1.当证书验证合法后，在本地生成随机数

2.通过公钥加密随机数，并把加密后的随机数传输到服务端

3.服务端通过私钥对随机数进行解密

4.服务端通过客户端传入的随机数构造对称加密算法，对返回结果内容进行加密后传输

# 为什么数据传输是用对称加密？

首先，非对称加密的加解密效率是非常低的，而 http 的应用场景中通常端与端之间存在大量的交互，非对称加密的效率是无法接受的；

另外，在 HTTPS 的场景中只有服务端保存了私钥，一对公私钥只能实现单向的加解密，所以 HTTPS 中内容传输加密采取的是对称加密，而不是非对称加密。

# 为什么需要 CA 认证机构颁发证书？

HTTP 协议被认为不安全是因为传输过程容易被监听者勾线监听、伪造服务器，而 HTTPS 协议主要解决的便是网络传输的安全性问题。

首先我们假设不存在认证机构，任何人都可以制作证书，这带来的安全风险便是经典的“中间人攻击”问题。

“中间人攻击”的具体过程如下：

过程原理：

1.本地请求被劫持（如DNS劫持等），所有请求均发送到中间人的服务器

2.中间人服务器返回中间人自己的证书

3.客户端创建随机数，通过中间人证书的公钥对随机数加密后传送给中间人，然后凭随机数构造对称加密对传输内容进行加密传输

4.中间人因为拥有客户端的随机数，可以通过对称加密算法进行内容解密

5.中间人以客户端的请求内容再向正规网站发起请求

6.因为中间人与服务器的通信过程是合法的，正规网站通过建立的安全通道返回加密后的数据

7.中间人凭借与正规网站建立的对称加密算法对内容进行解密

8.中间人通过与客户端建立的对称加密算法对正规内容返回的数据进行加密传输

9.客户端通过与中间人建立的对称加密算法对返回结果数据进行解密

由于缺少对证书的验证，所以客户端虽然发起的是 HTTPS 请求，但客户端完全不知道自己的网络已被拦截，传输内容被中间人全部窃取。

# 浏览器是如何确保 CA 证书的合法性？

1. 证书包含什么信息？

颁发机构信息

公钥

公司信息

域名

有效期

指纹

2. 证书的合法性依据是什么？

首先，权威机构是要有认证的，不是随便一个机构都有资格颁发证书，不然也不叫做权威机构。另外，证书的可信性基于信任制，权威机构需要对其颁发的证书进行信用背书，只要是权威机构生成的证书，我们就认为是合法的。所以权威机构会对申请者的信息进行审核，不同等级的权威机构对审核的要求也不一样，于是证书也分为免费的、便宜的和贵的。

3. 浏览器如何验证证书的合法性？

浏览器发起 HTTPS 请求时，服务器会返回网站的 SSL 证书，浏览器需要对证书做以下验证：

1.验证域名、有效期等信息是否正确。证书上都有包含这些信息，比较容易完成验证；

2.判断证书来源是否合法。每份签发证书都可以根据验证链查找到对应的根证书，操作系统、浏览器会在本地存储权威机构的根证书，利用本地根证书可以对对应机构签发证书完成来源验证；

3.判断证书是否被篡改。需要与 CA 服务器进行校验；

4.判断证书是否已吊销。通过CRL（Certificate Revocation List 证书注销列表）和 OCSP（Online Certificate Status Protocol 在线证书状态协议）实现，其中 OCSP 可用于第3步中以减少与 CA 服务器的交互，提高验证效率

以上任意一步都满足的情况下浏览器才认为证书是合法的。

这里插一个我想了很久的但其实答案很简单的问题：

既然证书是公开的，如果要发起中间人攻击，我在官网上下载一份证书作为我的服务器证书，那客户端肯定会认同这个证书是合法的，如何避免这种证书冒用的情况？

其实这就是非加密对称中公私钥的用处，虽然中间人可以得到证书，但私钥是无法获取的，一份公钥是不可能推算出其对应的私钥，中间人即使拿到证书也无法伪装成合法服务端，因为无法对客户端传入的加密数据进行解密。

4. 只有认证机构可以生成证书吗？

如果需要浏览器不提示安全风险，那只能使用认证机构签发的证书。但浏览器通常只是提示安全风险，并不限制网站不能访问，所以从技术上谁都可以生成证书，只要有证书就可以完成网站的 HTTPS 传输。例如早期的 12306 采用的便是手动安装私有证书的形式实现 HTTPS 访问。

# 本地随机数被窃取怎么办？

证书验证是采用非对称加密实现，但是传输过程是采用对称加密，而其中对称加密算法中重要的随机数是由本地生成并且存储于本地的，HTTPS 如何保证随机数不会被窃取？

其实 HTTPS 并不包含对随机数的安全保证，HTTPS 保证的只是传输过程安全，而随机数存储于本地，本地的安全属于另一安全范畴，应对的措施有安装杀毒软件、反木马、浏览器升级修复漏洞等。

# 用了 HTTPS 会被抓包吗？

HTTPS 的数据是加密的，常规下抓包工具代理请求后抓到的包内容是加密状态，无法直接查看。

但是，正如前文所说，浏览器只会提示安全风险，如果用户授权仍然可以继续访问网站，完成请求。因此，只要客户端是我们自己的终端，我们授权的情况下，便可以组建中间人网络，而抓包工具便是作为中间人的代理。通常 HTTPS 抓包工具的使用方法是会生成一个证书，用户需要手动把证书安装到客户端中，然后终端发起的所有请求通过该证书完成与抓包工具的交互，然后抓包工具再转发请求到服务器，最后把服务器返回的结果在控制台输出后再返回给终端，从而完成整个请求的闭环。

既然 HTTPS 不能防抓包，那 HTTPS 有什么意义？

A: 客户端发起 HTTPS 请求，服务端返回证书，客户端对证书进行验证，验证通过后本地生成用于改造对称加密算法的随机数，通过证书中的公钥对随机数进行加密传输到服务端，服务端接收后通过私钥解密得到随机数，之后的数据交互通过对称加密算法进行加解密。

Q: 为什么需要证书？

A: 防止”中间人“攻击，同时可以为网站提供身份证明。

Q: 使用 HTTPS 会被抓包吗？

A: 会被抓包，HTTPS 只防止用户在不知情的情况下通信被监听，如果用户主动授信，是可以构建“中间人”网络，代理软件可以对传输内容进行解密。

【教程】阿里云申请免费SSL证书实现网站HTTPS化

https://yq.aliyun.com/articles/755169?spm=a2c4e.11153940.0.0.577e259dAJnFVm

https://yq.aliyun.com/articles/755168?spm=a2c4e.11153940.0.0.577e259dAJnFVm

腾讯云申请免费SSL证书

从 HTTP 到 HTTPS

HTTPS是互联网 web 大势所趋。各大网站都已陆续部署了HTTPS，这篇文章我们来探讨什么是HTTPS以及为什么要部署HTTPS。

这篇文章收录在《Said - 从HTTP到HTTPS》系列：

从 HTTP 到 HTTPS - 什么是 HTTPS

从 HTTP 到 HTTPS - IIS如何部署 HTTPS

从 HTTP 到 HTTPS - 网站部署 HTTPS 中需要做的事情

HTTP

当你在浏览器输入一个网址 (例如 http://tasaid.com)的时候，浏览器发起一个 HTTP 请求，带着请求信息 (参见HTTP Headers)，连接到服务器，把请求信息递给服务器，服务器收到信息之后，解析相关的信息，然后进行处理，再返回浏览器请求的数据。

简单来说是这么一个流程：

小明跟浏览器爸爸说我想要去中关村某个店家拿一些东西 (发起请求)

浏览器爸爸就把小明要的东西记在一张清单上 (生成HTTP协议)

然后浏览器爸爸派出一个线程小弟，噌噌噌跑到中关村的店里，把清单递给店家，说小明要这些东西 (进行传输)

店家让线程小弟稍等，然后去屋子里面拿小明的这些东西 (服务器收到请求)

店家把东西拿出来后，并且也打印了一份清单，让线程小弟带着清单和东西一起拿回去 (服务器处理请求完毕)

然后线程小弟回到浏览器爸爸那边，把服务器给的清单和物品交给浏览器爸爸，浏览器爸爸根据清单核对物品 (浏览器处理响应)

然后把物品打包交给了小明(浏览器渲染并呈现界面)

看图说话：

这其中有个问题，浏览器爸爸和服务器都没有验证清单信息的有效性和对方的身份。万一有人在中间把线程小哥拦下来，暴揍一顿，然后把物品清单给换了怎么办？或者有人把线程小哥在半路上暴揍一顿，拿了清单换了另外一个小哥怎么办？

这是个很严肃的问题：假如服务器要把一些东西锁在柜子里，需要小明给密码才可以打开柜子。然后小明把密码写在清单上让浏览器爸爸交给服务器。这时候，如果这张清单被人拦截下来，不就得到了小明的密码？

简单来说，传输的信息中包含用户密码，被拦截了怎么办？

HTTPS

正因为HTTP请求有这些安全性的问题，所以HTTPS诞生了，致力于解决了这些安全性问题，我们进行一下对比：

安全性	HTTP	HTTPS
窃听风险	传递的信息是明文的，可能会被有心人拦截下来窃听	信息加密传播
篡改风险	传递的信息可能会被篡改	信息校验，一旦被篡改立刻就会被发现
伪装风险	没有验证通信另外一头对方的身份，可能遭遇伪装	身份校验

那么HTTPS是如何做到更安全的呢？

简单来说，HTTPS 即是在 HTTP 下加入了一层 SSL 加密，所以被称为HTTPS。具体的加密过程则是公匙加密法：

客户端向服务器索要公匙，然后使用公匙加密信息

服务器收到加密后的信息，用自己的私匙解密

公匙密码和算法都是公开的，而私匙则是保密的。加密使用的公匙和解码使用的密匙都是不相同的，因此这是一个非对称加密算法。

数字证书

提及 HTTPS ，就会听到大家说需要证书才能部署，那么什么是证书呢？

因为互联网不安全，公匙也是信息的一部分，也是会有被篡改的风险的。所以引入了互联网权威机构 - CA 机构，又称为证书授权 (Certificate Authority) 机构，浏览器会内置这些“受信任的根证书颁发机构”(即 CA)。

服务端向权威的身份鉴定 CA 机构申请数字证书，CA 机构验证了网站之后，会把网站录入到内部列表，采用 Hash 把服务端的一些相关信息生成摘要，然后 CA 机构用自己的私匙，把服务端的公匙和相关信息一起加密，然后给申请证书的服务端颁发数字证书，用于其他客户端 (比如浏览器) 认证这个网站的公匙。

客户端通过服务端下发的证书，找到对应的 CA，然后向 CA 验证这个证书是否有效，CA 验证通过之后，下发服务端的公匙。

因为 CA 是权威并且可信的，所以客户端 (浏览器) 信任 CA，而 CA 又信任经过认证的服务端，所以客户端 (浏览器) 也信任这个服务端，这就是信任链 (Chain Of Trust)。

而 CA 颁发的数字证书，一般包含这些信息：

简单来说：为了保证公匙是安全的，所以通过数字证书验证公匙。

加密通信

一条完整的HTTPS请求应该是这样的：

客户端 (浏览器) 发起 HTTP 请求，请求连接服务端，发送支持的加密通信协议 (和版本)，并且生成一个随机数，后续用于生成“对话密钥“。

服务端确认加密通信协议 (和版本)，同时也生成一个随机数，后续用于生成“对话密匙“，并且将 CA 颁发的数字证书，一起发送给客户端。

客户端收到数字证书后，检测内置的“受信任的根证书颁发机构“，查看解开数字证书的公匙是否在。

如果解开数字证书的公匙存在，则使用它解开数字证书，得到正确的服务器公匙，同时再次生成一个随机数，用于服务器公匙加密，并发送给服务器。

此时本地和服务器同时将三个随机数，根据约定的加密方法进行加密，各自生成本次会话的所使用的同一把“会话密匙”。

到这里，认证阶段已经完毕，数据传输从非对称加密换成了对称加密(因为考虑到性能)，接下来所有的数据传输都是使用HTTP协议进行传输，只不过使用了“会话密匙”来加密内容。

见下图：

参考和引用

HTTPS 工作原理

阮一峰 - 数字签名是什么

阮一峰 - SSL/TLS协议运行机制的概述

HTTP 为什么不安全.

安全通信的四大原则

HTTPS 通信原理简述

其它 HTTPS 相关问题

证书信任链

总结

近年来各大公司对信息安全传输越来越重视，也逐步把网站升级成 HTTPS 了。那么，大家知道 HTTPS 的原理是怎样的吗？到底它是如何确保信息安全传输的？本文试图由浅入深地把 HTTPS 讲明白，相信大家看完之后一定能明白HTTPS 的原理。

HTTP 由于是明文传输，主要存在三大风险：窃听风险、篡改风险、冒充风险。

1.1 窃听风险

中间人可以获取到通信内容，由于内容是明文，所以获取明文后有安全风险。

1.2 篡改风险

中间人可以篡改报文内容后再发送给对方，风险极大。

1.3 冒充风险

比如你以为是在和某宝通信，但实际上是在和一个钓鱼网站通信。

HTTPS 显然是为了解决这三大风险而存在的，接下来我们看看 HTTPS 到底解决了什么问题。

看了上一节，不难猜到 HTTPS 就是为了解决上述三个风险而生的，一般我们认为安全的通信需要包括以下四个原则:机密性、完整性，身份认证和不可否认。

机密性：即对数据加密，解决了窃听风险，因为即使被中间人窃听，由于数据是加密的，他也拿不到明文；

完整性：指数据在传输过程中没有被篡改，不多不少，保持原样，中途如果哪怕改了一个标点符号，接收方也能识别出来，从来判定接收报文不合法；

身份认证：确认对方的真实身份，即证明“你妈是你妈”的问题，这样就解决了冒充风险，用户不用担心访问的是某宝结果却在和钓鱼网站通信的问题；

不可否认: 即不可否认已发生的行为，比如小明向小红借了 1000 元，但没打借条，或者打了借条但没有签名，就会造成小红的资金损失。

接下来我们一步步来看看 HTTPS 是如何实现以满足以上四大安全通信原则的。

对称加密：HTTPS 的最终加密形式。

既然 HTTP 是明文传输的，那我们给报文加密不就行了，既然要加密，我们肯定需要通信双方协商好密钥吧。一种是通信双方使用同一把密钥，即对称加密的方式来给报文进行加解密。

如图示：使用对称加密的通信双方使用同一把密钥进行加解密。

对称加密具有加解密速度快，性能高的特点，也是 HTTPS 最终采用的加密形式。但是这里有一个关键问题：对称加密的通信双方要使用同一把密钥，这个密钥是如何协商出来的？如果通过报文的方式直接传输密钥，之后的通信其实还是在裸奔，因为这个密钥会被中间人截获甚至替换掉，这样中间人就可以用截获的密钥解密报文，甚至替换掉密钥以达到篡改报文的目的。

有人说对这个密钥加密不就完了，但对方如果要解密这个密钥还是要传加密密钥给对方，依然还是会被中间人截获的，这么看来直接传输密钥无论怎样都无法摆脱俄罗斯套娃的难题，是不可行的。

非对称加密：解决单向对称密钥的传输问题

直接传输密钥无论从哪一端传从上节分析来看是不行了，这里我们再看另一种加密方式：非对称加密。

非对称加密即加解密双方使用不同的密钥，一把作为公钥，可以公开的，一把作为私钥，不能公开，公钥加密的密文只有私钥可以解密，私钥加密的内容，也只有公钥可以解密。

注：私钥加密其实这个说法其实并不严谨，准确的说私钥加密应该叫私钥签名。因为私密加密的信息公钥是可以解密的，而公钥是公开的，任何人都可以拿到，用公钥解密叫做验签。

这样的话对于 server 来说，保管好私钥，发布公钥给其他 client, 其他 client 只要把对称加密的密钥加密传给 server 即可。如此一来由于公钥加密只有私钥能解密，而私钥只有 server 有，所以能保证 client 向 server 传输是安全的，server 解密后即可拿到对称加密密钥，这样交换了密钥之后就可以用对称加密密钥通信了。

但是问题又来了， server 怎么把公钥安全地传输给 client 呢。如果直接传公钥，也会存在被中间人调包的风险。

数字证书，解决公钥传输信任问题

如何解决公钥传输问题呢？从现实生活中的场景找答案。员工入职时，企业一般会要求提供学历证明，显然不是什么阿猫阿狗的本本都可称为学历，这个学历必须由第三方权威机构（Certificate Authority，简称 CA）即教育部颁发。同理，server 也可以向 CA 申请证书，在证书中附上公钥，然后将证书传给 client，证书由站点管理者向 CA 申请，申请的时候会提交 DNS 主机名等信息，CA 会根据这些信息生成证书。

这样当 client 拿到证书后，就可以获得证书上的公钥，再用此公钥加密对称加密密钥传给 server 即可。看起来确实很完美，不过在这里大家要考虑两个问题

问题一：如何验证证书的真实性，如何防止证书被篡改

想象一下上文中我们提到的学历，企业如何认定你提供的学历证书是真是假呢？答案是用学历编号，企业拿到证书后用学历编号在学信网上一查就知道证书真伪了，学历编号其实就是我们常说的数字签名，可以防止证书造假。

回到 HTTPS 上，证书的数字签名该如何产生的呢？一图胜千言：

步骤如下：

1、首先使用一些摘要算法（如 MD5）将证书明文（如证书序列号，DNS 主机名等）生成摘要，然后再用第三方权威机构的私钥对生成的摘要进行加密（签名）。

消息摘要是把任意长度的输入揉和而产生长度固定的伪随机输入的算法，无论输入的消息有多长，计算出来的消息摘要的长度总是固定的。

一般来说，只要内容不同，产生的摘要必然不同（相同的概率可以认为接近于 0），所以可以验证内容是否被篡改了。

为啥要先生成摘要再加密呢，不能直接加密？

因为使用非对称加密是非常耗时的。如果把整个证书内容都加密生成签名的话，客户端验验签也需要把签名解密，证书明文较长，客户端验签就需要很长的时间，而用摘要的话，会把内容很长的明文压缩成小得多的定长字符串，客户端验签的话就会快得多。

2、客户端拿到证书后也用同样的摘要算法对证书明文计算摘要，两者一笔对就可以发现报文是否被篡改了。那为啥要用第三方权威机构（Certificate Authority，简称 CA）私钥对摘要加密呢？

因为摘要算法是公开的，中间人可以替换掉证书明文，再根据证书上的摘要算法计算出摘要后把证书上的摘要也给替换掉！这样 client 拿到证书后计算摘要发现一样，误以为此证书是合法就中招了。

所以必须要用 CA 的私钥给摘要进行加密生成签名，这样的话 client 得用 CA 的公钥来给签名解密，拿到的才是未经篡改合法的摘要（私钥签名，公钥才能解密）。

server 将证书传给 client 后，client 的验签过程如下：

这样的话，由于只有 CA 的公钥才能解密签名，如果客户端收到一个假的证书，使用 CA 的公钥是无法解密的，如果客户端收到了真的证书，但证书上的内容被篡改了，摘要比对不成功的话，客户端也会认定此证书非法。

细心的你一定发现了问题，CA 公钥如何安全地传输到 client ？如果还是从 server 传输到 client，依然无法解决公钥被调包的风险。实际上此公钥是存在于 CA 证书上，而此证书（也称 Root CA 证书）被操作系统信任，内置在操作系统上的，无需传输，如果用的是 Mac 的同学，可以打开 keychain 查看一下，可以看到很多内置的被信任的证书。

server 传输 CA 颁发的证书，客户收到证书后使用内置 CA 证书中的公钥来解密签名，验签即可，这样的话就解决了公钥传输过程中被调包的风险。

问题二、如何防止证书被调包

实际上任何站点都可以向第三方权威机构申请证书，中间人也不例外。

正常站点和中间人都可以向 CA 申请证书，获得认证的证书由于都是 CA 颁发的，所以都是合法的。那么此时中间人是否可以在传输过程中将正常站点发给 client 的证书替换成自己的证书呢，如下所示：

答案是不行，因为客户端除了通过验签的方式验证证书是否合法之外，还需要验证证书上的域名与自己的请求域名是否一致，中间人中途虽然可以替换自己向 CA 申请的合法证书，但此证书中的域名与 client 请求的域名不一致，client 会认定为不通过！

但是上面的证书调包给了我们一种思路，什么思路？大家想想，HTTPS 既然是加密的， charles 这些中间人为啥能抓到明文的包呢？其实就是用了证书调包这一手法，想想看，在用 charles 抓 HTTPS 的包之前我们先要做什么，当然是安装 charles 的证书。

这个证书里有 charles 的公钥，这样的话 charles 就可以将 server 传给 client 的证书调包成自己的证书，client 拿到后就可以用你安装的 charles 证书来验签等，验证通过之后就会用 charles 证书中的公钥来加密对称密钥了。整个流程如下：

由此可知，charles 这些中间人能抓取 HTTPS 包的前提是信任它们的 CA 证书，然后就可以通过替换证书的方式进行瞒天过海，所以我们千万不要随便信任第三方的证书，避免安全风险。

什么是双向认证？

以上的讲述过程中，我们只是在 client 端验证了 server 传输证书的合法性。但 server 如何验证 client 的合法性，还是用证书，我们在网上进行转账等操作时，想想看是不是要先将银行发给我们的 U 盾插到电脑上？其实也是因为 U 盾内置了证书，通信时将证书发给 server，server 验证通过之后即可开始通信。

画外音：身份认证只是 U 盾功能的一种，还有其他功能，比如加解密都是在 U 盾中执行，保证了密钥不会出现在内存中

什么是证书信任链？

前文说了，我们可以向 CA 申请证书，但全世界的顶级 CA（Root CA）就那么几个，每天都有很多人要向它申请证书，它也忙不过来啊，怎么办呢？想想看在一个公司里如果大家都找 CEO 办事，他是不是要疯了，那他能怎么办？授权，他会把权力交给 CTO，CFO 等，这样你们只要把 CTO 之类的就行了，CTO 如果也忙不过来呢，继续往下授权啊。

同样的，既然顶级 CA 忙不过来，那它就向下一级，下下级 CA 授权即可，这样我们就只要找一级/二级/三级 CA 申请证书即可。怎么证明这些证书被 Root CA 授权过了呢，小一点的 CA 可以让大一点的 CA 来签名认证。比如一级 CA 让 Root CA 来签名认证，二级 CA 让一级 CA 来签名认证,Root CA 没有人给他签名认证，只能自己证明自己了，这个证书就叫「自签名证书」或者「根证书」，我们必须信任它，不然证书信任链是走不下去的（这个根证书前文我们提过，其实是内置在操作系统中的）

现在我们看看如果站点申请的是二级 CA 颁发的证书，client 收到之后会如何验证这个证书呢，实际上 service 传了传给二级 CA 的证书外，还会把证书信任链也一起传给客户端，这样客户端会按如下步骤进行验证：

浏览器就使用信任的根证书（根公钥）解析证书链的根证书得到一级证书的公钥+摘要验签；

拿一级证书的公钥解密一级证书，拿到二级证书的公钥和摘要验签；

再然后拿二级证书的公钥解密 server 传过来的二级证书，得到服务器的公钥和摘要验签，验证过程就结束了。

相信大家看完本文应该对 HTTPS 的原理有了很清楚的认识了， HTTPS 无非就是 HTTP + SSL/TLS

而 SSL/TLS 的功能其实本质上是：如何协商出安全的对称加密密钥，以利用此密钥进行后续通讯的过程。

带着这个疑问，相信你不难理解数字证书和数字签名这两个让人费解的含义，搞懂了这些，也就明白了为啥 HTTPS 是加密的，charles 这些工具却能抓包出明文来。

本文详细介绍了 HTTPS 相较于 HTTP 更安全的原因，包括对称加密、非对称加密、完整性摘要、数字证书以及 SSL/TLS 握手等内容，图文并茂、理论与实战结合、建议收藏！

1. 不安全的 HTTP

近些年来，越来越多的网站使用 HTTPS 协议进行数据传输，原因在于 HTTPS 相较于 HTTP 能够提供更加安全的服务。

很多浏览器对于使用 HTTP 协议的网站会加上『警告』的标志表示数据传输不安全，而对于使用 HTTPS 协议的网站会加上一把『锁』标志表示数据传输安全。

为什么 HTTP 协议不安全呢？主要表现在以下三个方面：

容易被窃听：HTTP 传输的数据是明文。黑客很容易通过嗅探技术截获报文，由于数据没有加密，内容可以被黑客所理解。

举个例子：如果用户输入密码取款，那么黑客窃听了此密码后，就可以为所欲为了！

容易被篡改：黑客可以在截获 HTTP 报文后，对报文进行修改，然后再发送到目的地。

举个例子：如果用户想要转账给家人，而黑客将收款人修改成了自己，将会造成用户出现损失！

容易被伪造身份：黑客可以伪造 HTTP 报文，假装自己是用户真正想要访问的网站，然后与用户进行通信。

举个例子：如果用户想要访问淘宝网站进行购物，而黑客冒充自己是淘宝网站，用户就可能在此假淘宝网站上买东西，造成损失！

HTTPS 是如何解决以上安全性问题的呢？主要方法如下所示：

数据加密：HTTPS 传输的不再是明文，而是采用加密算法传输密文，黑客即使截获了报文，也无法理解内容！

完整性摘要：HTTPS 通过摘要算法得到报文的一个摘要，如果黑客篡改了报文内容，那么重新生成的摘要将发生变化，接收方校验后就知道数据不再完整，被篡改了！

数字证书：HTTPS 通过数字证书来验证通信实体的身份，而黑客因为没有相应的证书，一旦冒充其他网站将会被识破！

2. 加密算法

加密算法用于解决 HTTP 传输数据容易被窃听的问题。

为了防止传输数据被黑客所窃听，客户端与服务器之间需要对数据进行加解密处理。

发送方使用加密算法将明文加密为密文，而接收方使用相应的解密算法将密文解密为明文。黑客只能看到密文，因而并不能获取到任何有用信息。如下图所示：

一般来说，加密算法分为两大类，对称加密和非对称加密。

对称加密：指加密和解码使用同一把密钥，即图中的密钥 A 等于密钥 B；

非对称加密：指加密和解密使用不同的密钥，即图中的密钥 A 不等于密钥 B。

（1）对称加密

对称加密算法中加密和解密的钥匙是同一把，称之为密钥。

凯撒密码是一种较为简单的对称加密算法，可用于对英语文本进行加解密。其主要思想是：将明文中的每个字母按照字母表所在位置右移 K 位，得到密文（允许回绕）。

举个例子，设 K = 2，那么明文中的字母 'a' 用字母 'c' 代替，字母 'z' 用字母 'b' 代替。此时 K = 2 就是对称加密算法中的密钥。

这种方式的缺点在于：每个字母经过加密后只有唯一的密文表示，如果黑客收集了很多数据后进行统计分析，很可能就破解了加密手段。

更好的方式是采用多个凯撒密码 K 轮询进行加密，比如位置为奇数的字母采用密钥 K = 2 加密，位置为偶数的字母采用密钥 K = 3 加密。

然而凯撒密码只能加密英文文本，若想要加密所有字符，可以采用分组加密的方式。

我们知道任何数据在计算机中实际存储的是 0/1 比特的组合。分组加密的主要思想是：将要加密的报文处理为 K 比特的分组，每个分组通过一对一的映射表进行加密。

举个例子，设 K = 3，映射表如下图，那么报文010110001111 将会被加密为101000111001。此时 K=3 以及映射表就是对称加密算法中的密钥。

与前面采用多个凯撒密码 K 作为密钥的方式一样，为了增加破解的难度，一种更好的方式是采用多个映射表，轮询对数据进行加密。

计算机网络中常用的对称加密算法有：DES、3DES、AES等，都属于分组加密算法。

（2）非对称加密

非对称加密算法中加密和解密的钥匙不同，分别称为公钥和私钥。其特点在于：

如果用公钥加密，则只能用私钥解密，此时公钥是不能解密的。

如果用私钥加密，则只能用公钥解密，此时私钥是不能解密的。

公钥是对外公开的，任何人都能够得到；私钥只有自己知道，不能泄露。

为什么有了对称加密后还会出现非对称加密呢？

原因在于对称加密的前提是通信双方需要商量出一个密钥，而商量密钥的时候传输的是明文，如果此密钥被黑客所截获，即使后面的报文进行了加密，黑客也可以通过此密钥进行解密！

非对称加密的一个特点是：公钥加密，只有私钥可以解密。那么就无需像对称加密那样提前协商好密钥。通信双方可以直接将自己的公钥发送给另一方，这个公钥即使黑客知道也无所谓，当一方用此公钥加密后，即使黑客截获了报文，也无法用公钥解密，只有拥有私钥的另一方才能解密成功！

计算机网络中常用的非对称加密算法有：RSA、 ECDHE等。

相较于对称加密，非对称加密算法更加复杂难懂，数学推理较多，如果对具体算法感兴趣的，可以看一下阮一峰的两篇文章：RSA 算法原理（一）和RSA 算法原理（二）。

https://www.ruanyifeng.com/blog/2013/06/rsa_algorithm_part_one.html

http://www.ruanyifeng.com/blog/2013/07/rsa_algorithm_part_two.html

（3）混合加密

前面提到，对称加密算法需要提前协商出密钥，而协商的过程用的是明文（因为还没有密钥），如果黑客截获了明文密钥，那么之后即使加密了，黑客也可以用密钥进行解密，此时就无安全性可言了！

非对称加密算法解决了此问题，但是其存在大量的指数运算，加密速度非常慢！而对称加密算法的加密速度非常快，一般是非对称加密算法的 100-10000 倍！

那能不能将二者综合起来，使得数据传输不仅安全且高效呢？答案是肯定的！HTTPS 采用混合加密方式，既采用对称加密，也采用非对称加密。

对称加密算法的弱点在于协商密钥的过程采用明文不安全，存在密钥泄漏的可能，那么我们是不是可以不采用明文，而是采用非对称加密算法来协商此密钥，之后传输数据时再采用对称加密算法进行加密。

也就是说，用非对称加密算法传输密钥，用对称加密算法传输实际数据。此密钥一般称为『会话密钥』。

会话密钥通过非对称加密算法传输，非常安全；

大量数据通过对称加密算法传输（多次），会话密钥只需要传一次，非常高效！

3. 摘要算法

摘要算法用于解决 HTTP 传输数据容易被篡改的问题。

摘要算法也称为哈希算法，其输入为任意数据，输出为固定长度的字符串（称为摘要）。主要特点如下：

不可逆，即无法通过输出反推输入。

相同的输入必会产生相同的输出。

不同的输入大概率会产生不同的输出。

无论输入的数据有多长，输出摘要的长度固定不变。

举个例子：如果将数据的比特流每 8 个比特进行分组（不足的补零），然后将所有分组进行按位异或运算，那么生成的结果就可以称为摘要，此算法就是一种简单的摘要算法。

如果两个输入数据经过摘要算法得到的输出摘要一致，则称为出现了哈希碰撞。一个好的摘要算法出现哈希碰撞的概率非常低，而且非常难以通过输出猜测输入的内容！

计算机网络中常用的摘要算法有：MD5、SHA-1、SHA-256等。

为了防止传输数据被黑客所篡改，发送方除了发送实际数据外，还利用摘要算法得到数据的一个摘要，并将此摘要一并发送。

接收方收到数据后，利用同样的摘要算法再次得到数据的摘要，并将其与发送方发送的摘要进行比对校验，如果二者不一致，则说明数据被篡改了，反之则没有。

小伙伴们很容易看出来上述方式存在明显缺陷，如果黑客不仅篡改了数据，而且同时篡改了摘要，接收方不就无法判断数据是否被篡改了吗？

为了防止这种情况的发生，发送方与接收方必须有一个只有二者知道的，而黑客不能知道的东西，比如对称加密的会话密钥。不过为了提升安全性，此时一般不使用会话密钥，而是使用一个新的密钥，称之为鉴别密钥，这个密钥的获取同会话密钥。

有了鉴别密钥后，摘要算法的输入就不仅仅是传输数据了，而是传输数据和鉴别密钥！黑客由于不知道鉴别密钥，就无法再伪造输入，篡改的摘要也就不正确了，从而保证了安全性！

数据和鉴别密钥级联后经过摘要算法所生成的摘要有个专用名字，称为报文鉴别码，简称MAC。

为了进一步提升安全性，实际上客户端和服务器将使用不同的会话密钥和鉴别密钥，也就是一共需要四个密钥：

用于从客户端发送到服务器的数据的会话密钥；

用于从服务器发送到客户端的数据的会话密钥；

用于从客户端发送到服务器的数据的鉴别密钥；

用于从服务器发送到客户端的数据的鉴别密钥。

4. 数字证书

数字证书用于解决 HTTP 协议中身份容易被伪造的问题。

前面提到 HTTPS 采用非对称加密算法传输会话密钥。一般是服务器将公钥对外公布，客户端利用此公钥加密会话密钥，然后服务器通过私钥解密得到会话密钥，此时双方即协商好了用于对称加密传输数据的密钥。

但是万一服务器的公钥是被黑客伪造的呢？比如经典的『中间人攻击』问题：

客户端发送的请求被中间人（黑客）劫持（如使用 DNS 劫持），所有请求均发送至中间人。

中间人假装自己是正规网站（服务器），向客户端返回自己的公钥 2 ，并索要正规网站的公钥 1。

客户端使用中间人的公钥 2 加密会话密钥1，并发送至中间人。

中间人使用自己的私钥 2 解密得到会话密钥1，同时假装自己是客户端，使用正规网站的公钥 1 加密会话密钥2（可以与会话密钥 1 相同）并发送至正规网站。

客户端使用会话密钥1对数据进行加密，并发送至中间人。

中间人使用会话密钥1对数据进行解密，得到明文数据！（实现了窃听）

中间人使用会话密钥2对数据（可能是篡改的）进行加密，并发送至正规网站。

此时，客户端与服务器的通信再无安全性可言！中间人不仅能够窃听到消息内容，还能够进行篡改！

客户端如何知道自己所拥有的公钥是来自于正规网站而不是中间人呢？这时候就需要数字证书了！

数字证书的概念就像是我们的身份证一样，专门用于验证通信实体的身份。咱们的身份证是去派出所申请的，而数字证书则需要向认证中心（Certification Authority，CA）申请，而且是需要收费的！

通过数字证书解决中间人攻击的具体过程为：

服务器（正规网站）首先生成一对公钥和私钥，然后将域名、申请者、公钥（注意不是私钥，私钥是无论如何也不能泄露的）等信息整合在一起，生成 .csr 文件，并将此文件发给认证中心 CA。

CA 收到申请后，会通过各种手段验证申请者的信息，如无异常，则使用摘要算法得到 .csr 中明文信息的一个摘要，再用 CA 自己的私钥对这个摘要进行加密，生成一串密文，密文也称为数字签名。数字证书即包含此数字签名和 .csr 中明文信息。CA 把这个证书返回给申请人。

为了防止中间人攻击，客户端要求服务器发送其证书，并进行验证。

客户端在验证证书时，把证书里的签名与及明文信息分别取出来，然后会用自身携带的 CA 机构的公钥去解密签名，得到摘要 1，再利用摘要算法得到明文信息的摘要 2，对比摘要 1 和摘要 2，如果一样，说明证书是合法的，也就是证书里的公钥是正确的，否则说明证书不合法。

浏览器如何得到认证中心的公钥呢？万一此公钥是被伪造的呢？为了防止套娃，实际电脑操作系统中会内置这些认证中心的公钥！因而无需担心认证中心公钥被伪造的问题。

Chrome 浏览器一旦发现一个网站数字证书无效，就会生成如下界面进行提示，如果用户强制访问，则存在一定的风险。

5. SSL/TLS 握手

根据前面所述，进行一下小结：

HTTPS 通过混合加密算法解决 HTTP 传输数据容易被窃听的问题，此过程需要协商会话密钥。

HTTPS 通过摘要算法解决 HTTP 传输数据容易被篡改的问题，此过程需要协商鉴别密钥。

HTTPS 通过数字证书解决 HTTP 协议中身份容易被伪造的问题，此过程需要客户端验证服务器的证书。

那么 HTTPS 具体是怎么做的呢？通信双方在什么时候协商会话密钥和鉴别密钥、什么时候验证证书合法性的呢？答案是 SSL/TLS 协议握手的时候。

HTTPS 比 HTTP 多的那个『S』就是指 SSL/TLS 协议。

在 HTTPS 协议中，当客户端与服务器通过三次握手建立 TCP 连接之后，并不会直接传输数据，而是先会经过一个 SSL/TLS 握手的过程，用于协商会话密钥、鉴别密钥以及验证证书等，之后就可以安全传输数据了！

下面通过 Wireshark 抓包，具体讲一下 SSL/TLS 1.2 四次握手的过程。

第一次握手

客户端向服务器发起加密通信请求，内容主要包括：

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

客户端生产的随机数 1，用于后续生成会话密钥和鉴别密钥。

客户端支持的密码套件列表，每个密码套件包含：

用于传输会话密钥的非对称加密算法，如 ECDHE、RSA；用于验证数字证书的非对称加密算法，如 ECDHE、RSA；用于传输数据的对称加密算法，如 AES_128_GCM、AES_128_CBC；用于验证报文完整性的摘要算法，如 SHA256、SHA384；

格式为：TLS_非对称加密算法_非对称加密算法_对称加密算法_摘要算法，如果两个非对称加密算法一致，可省略不写。

第二次握手

服务器收到客户端加密通信请求后，向客户端发出响应，内容主要包括：

确认的 SSL/ TLS 协议版本，如果双方支持的版本不同，则关闭加密通信。

服务器生产的随机数 2，用于后续生成会话密钥和鉴别密钥。

确认的密码套件，如 TLS_RSA_WITH_AES128_CBC_SHA。

服务器的数字证书。

第三次握手

客户端收到服务器的回应之后，会验证其数字证书是否合法（验证方法在数字证书小节中有说明），如果证书合法，则进行第三次握手，内容主要包括：

客户端生产的另一个随机数 3（称为前主密钥，Pre-Master Secret，简写为 PMS），此随机数会被服务器公钥加密。

客户端根据随机数 1、随机数 2 以及前主密钥计算出主密钥（Master Secret，MS），接着将主密钥切片得到两个会话密钥和两个鉴别密钥。

加密通信算法改变通知，表示之后数据都将用会话密钥进行加密。

客户端握手结束通知，表示客户端的握手阶段已经结束。客户端会生成所有握手报文数据的摘要，并用会话密钥加密后发送给服务器，用来供服务端校验。

第四次握手

服务器收到客户端的消息后，利用自己的私钥解密出前主密钥，并根据随机数 1、随机数 2 以及前主密钥计算出主密钥，接着将主密钥切片得到两个会话密钥和两个鉴别密钥。

之后进行第四次握手，内容主要包括：

加密通信算法改变通知，表示之后数据都将用会话密钥进行加密。

服务器握手结束通知，表示服务器的握手阶段已经结束。服务器会生成所有握手报文数据的摘要，并用会话密钥加密后发送给客户端，用来供客户端校验。

至此，整个 SSL/TLS 的握手阶段全部结束！

为什么第三、第四次握手要发送所有握手报文的摘要呢？

主要原因是防止握手信息被篡改。比如客户端支持的密码套件列表中，有些加密算法较弱，有些加密算法较强，而此密码套件是明文传输的，万一黑客将此密码套件列表进行了修改，只留下一些安全性较低的加密算法，那么服务器就只能从这些安全性较低的加密算法中选择，安全性大大降低。因此需要通过发送摘要的形式防止握手信息被篡改。

为什么不直接发送一个主密钥，而是用两个随机数加一个前主密钥重新生成一个主密钥呢？

主要原因是防止连接重放。如果没有前面两个随机数，仅仅由客户端生成一个主密钥，并通过服务器公钥加密发送给服务器。那么黑客在嗅探了服务器与客户端之间的所有报文后，可以再次冒充客户端向服务器发送相同的报文（虽然黑客不知道内容是什么），因为报文信息都是之前客户端和服务器验证过的，因此服务器会认为是客户端与其通信，导致又一次连接。

假如服务器是一个购物网站，那么此连接重放会导致客户端再一次下单，造成损失。

而如果有了前两个随机数，即使黑客冒充客户端想要连接重放，然而由于随机数不同，生成的密钥则不同，黑客重新发送的内容将失效（服务器不能理解、完整性摘要也不对）。

最后，用一张图总结 TLS 四次握手的过程。

在HTTP里，一切都是明文传输的，流量在途中可随心所欲的被控制。而在线使用的 WebApp，流量里既有通信数据，又有程序的界面和代码，劫持简直轻而易举。

HTTPS虽然不是绝对安全，但运营商要想劫持也不是这么简单的事情。

下面我们来聊一聊HTTPS

如何做到防劫持。SSL握手

先来看看HTTPS建立连接的过程，相比HTTP的三次握手，HTTPS在三次握手之后多了SSL握手。如下图：

SSL握手整个流程大概如下：

1.浏览器将自己支持的一套加密规则发送给网站。

2.网站部署了一组SSL秘钥，分私钥和秘钥。

3.网站从浏览器的加密规则中选出一组加密算法与HASH算法，并将自己的身份信息（公钥）以证书的形式发回给浏览器。证书里面包含了网站地址，加密公钥，以及证书的颁发机构等信息。

4.获得网站证书之后浏览器要做以下工作：

a) 验证证书的合法性（颁发证书的机构是否合法，证书中包含的网站地址是否与正在访问的地址一致等），如果证书受信任，则浏览器栏里面会显示一个小锁头，否则会给出证书不受信的提示。

b) 如果证书受信任，或者是用户接受了不受信的证书，浏览器会生成一串随机数的密码，并用证书中提供的公钥加密。

c) 使用约定好的HASH计算握手消息，并使用生成的随机数对消息进行加密。这个加密过程是非对称加密，即公钥加密，私钥解密。私钥只在网站服务器上存储，其他人无法获得这个私钥，也就无法解密。可理解为公钥是锁，私钥是钥匙，客户端将随机数用公钥锁上，经过网络传输到服务器，整个过程就算有人拦截了信息，由于没有私钥解锁，也就无法解密。

过程如下图：

CA证书校验

5.将生成的所有信息发送给网站。

6.网站接收浏览器发来的数据之后，使用自己的私钥将信息解密取出密码，使用密码解密浏览器发来的握手消息，并验证HASH是否与浏览器发来的一致。

7.使用密码加密一段握手消息，发送给浏览器。

8.浏览器解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。

这里浏览器与网站互相发送加密的握手消息并验证，目的是为了保证双方都获得了一致的密码，并且可以正常的加密解密数据，为后续真正数据的传输做一次测试。

备注：非对称加密算法用于在握手过程中加密生成的密码，对称加密算法用于对真正传输的数据进行加密，而HASH算法用于验证数据的完整性。由于浏览器生成的密码是整个数据加密的关键，因此在传输的时候使用了非对称加密算法对其加密。非对称加密算法会生成公钥和私钥，公钥只能用于加密数据，因此可以随意传输，而网站的私钥用于对数据进行解密，所以网站都会非常小心的保管自己的私钥，防止泄漏。

如何防劫持

对于HTTP请求来说，常见的劫持有DNS劫持和内容劫持。

举个网上的例子，有人在知乎问过一个问题。

在浏览器输入如下域名https:// www.zhihu.com那浏览器要打开这个网站，首先要解析域名www.zhihu.com,结果这个域名被黑客劫持到他的私人服务器1.2.3.4,结果我的浏览器和他的私人服务器1.2.3.4建立SSL连接，他的服务器1.2.3.4也和www.zhihu.com建立SSL的连接，我收发的数据都通过他的服务器1.2.3.4中转，也就是黑客的服务器1.2.3.4相当于一个https代理服务器，结果我收发的所有数据，他都能看到。可能这样被劫持吗？

这个黑客的攻击就是通常说的中间人攻击，跳转1.2.3.4就是DNS劫持，DNS被劫持到一个非源端的IP上。我们根据上文SSL握手的流程来分析一下，这种可能性是否存在。

首先如果黑客要跟你的浏览器建立SSL连接，那么他需要有一个CA证书，而通常系统内置根证书都是大型机构的根证书，几乎无法伪造。如果非要做一个只能是自签名证书。

Paste_Image.png

浏览器拿着对方的自签名证书和系统证书进行校验，结果一定是如下图所示：

Paste_Image.png

如果他要假冒其他机构颁发证书，因为没有颁发机构的秘钥，那么这个证书的指纹一定没办法对上，还是一样会报警。

Paste_Image.png

除非用户自己主动导入一个自己信任的证书。

12306

记住，不要随便安装受信任证书，否则HTTPS也帮不了你。我们平时为了调试HTTPS请求，使用Charles/MitmProxy进行抓包，也需要在手机端导入一个证书，让用户选择信任安装，目的就是将Charles/MitmProxy作为中间人代理，如果没有用户信任安装证书的过程，也同样无法解析HTTPS的请求包。

还有人就说了，我可以让用户回落到HTTP协议啊，中间人用HTTPS跟服务器通信，然后用HTTP跟客户端通信——要知道大部分用户在地址栏输入URL时，并没有指定协议的习惯，都是打www开头而不是打https://www开头，能用HTTPS全是Web+Server上80端口301+Location到HTTPS的功劳。

看起来似乎中间人充当了一个替换页面里HTTPS资源到HTTP的反向代理，好像可行性还是很高。

但是只要利用HSTS（HTTP+Strict+Transport+Security，RFC6797）就可以解决这个问题。通过在HTTP+Header中加入Strict-Transport-Security的声明，告诉浏览器在一定时间内必须通过HTTPS

协议访问本域名下的资源。

这种情况下，只要用户曾经在安全网络环境下访问过一次某站，中间人在指定时间内也无法让其回落到HTTP。

解决完DNS劫持，再看内容劫持就简单多了。

你作为一个中间人，你没有服务器私钥A，是不能解密客户端发送的内容的，如果你没有客户端自己生成的密钥B，所以你也不能解密客户端发过去的内容的。

总结：

1.CA证书保证了公钥的可靠性。

2.服务端私钥+公钥的非对称加解密保证了客户端生成的随机数传输安全，不会被中间人拦截获取。But，非对称加密对服务端开销大。

3.所以利用随机数的对称加密保证后续通讯的安全性，也可以降低服务器的解密开销。

4.HTTPS只针对传输内容进行加密，保证的是客户端和网站之间的信息就算被拦截也无法破解。如果不是全站HTTPS，仅仅只是在登录页采用HTTPS，那些HTTP连接的页面同样是危险的，从HTTP->HTTPS跳转依然可能被劫持。国内的部分银行就是这样，对安全性的考量还比不上百度，百度早就全站HTTPS了。