HTTP系列-HTTPS篇
本篇目录
通过阅读本篇文章你可以学习到：
- HTTPS概念
- 相比于HTTP的优势/为什么需要HTTPS
- HTTP与HTTPS的区别
- 具体解决方式
- SSL/TLS
- 为何不是所有网站都用HTTPS
1. HTTPS概念
HTTPS它并非是一种新的协议，只是通信接口部分用SSL或者TLS协议替代(在HTTP和TCP之间建立中间层)。
换句话说HTTPS其实就是身披SSL协议这层外壳的HTTP。
可以理解为：
HTTPS = HTTP + SSL/TLS
2. 相比于HTTP的优势/为什么需要HTTPS
其实也就是弥补了HTTP的缺点：
- 数据隐私性，内容经过对称加密；
- 数据完整性，内容经过完整性校验；
- 身份认证，第三方无法伪装客户端/服务器的身份
3. HTTP与HTTPS的区别
可以从这几个方面来看：
- HTTPS标准端口443，HTTP是80
- HTTPS基于传输层，HTTP基于应用层
- HTTPS在浏览器上会显示绿色的安全锁，而HTTP没有
- 弥补了HTTP的缺点，数据的隐私性、完整性、身份验证。也就是更加安全。
4. 具体解决方式
对于HTTPS具体的解决方式，我认为还是得围绕它的功能来看：
- 解决内容被窃听（加解密）
- 解决内容被篡改（数字签名）
- 解决通信方身份遭伪装（数字证书）
这块的内容还是很多的，让我们来分别看看。
4.1 解决内容被窃听(加解密)
4.1.1 对称密钥加密(共享密钥加密)
概念：是最简单的加密方式，指加密解密用的都是相同的密钥。
过程：
-
发送秘文的一方把通过密钥加密的内容(也就是秘文)和这个密钥一起发送给接收方；
-
接收方接到之后用这个密钥把秘文解密得到里面的内容
优点：
- 加解密效率很快
缺点：
- 并不安全，只要拿到密钥任何人都能解密
4.1.2 非对称密钥加密(公开密钥加密)
概念：使用一对非对称的密钥，也就是会有两把密钥，一把是私钥(只有自己才能有)，一把是公钥(可以发布给任何人)，用私钥加密的数包只有公钥能解，用公钥加密的数据包只有私钥能解。
过程：发送秘文的一方用"对方的公钥"对信息进行加密，对方收到被加密的信息后再用自己的私钥进行解密。
特点：信息传输一对多，服务器只需要维持好一个私钥就能和多个客户端进行加密通信。
优点：
- 使得传输内容不能被破解。例如如果是公钥加密的数据，就算第三方截获了这个数据但是没有对应的私钥也破解不了。
缺点：
- 公钥是公开的，谁都可以获取，那么如果发送的加密信息是通过私钥加密的话，有公钥的黑客就可以用这个公钥来解密拿到里面的信息。
- 公钥并不包含服务器的信息，使用非对称加密算法并不能确保服务器身份的合法性。可能存在中间人攻击，也就是服务器发送给客户端的公钥可能在途中被人截获篡改。
- 在数据加解密的时候需要消耗一定的时间
降低了数据传输的效率。
4.1.3 混合加密机制(HTTPS采用的方式)
概念：结合两种加密方式的优点，在交换密钥环节使用非对称加密方式，之后的建立通信交换报文阶段使用对称加密方式。
流程：发送密文的一方使用"对方的公钥"进行加密处理"对称的密钥"，然后对方接收到之后使用自己的私钥进行解密得到"对称的密钥"，这就达到了确保交换的密钥是安全的前提下使用对称加密方式进行通信。
Q1：那混合加密机制的好处是什么呢？
难度：🌟🌟
刚刚已经说到了对称密钥加密和非对称密钥加密都有它们各种的优缺点，而混合加密机制就是将两者结合利用它们各自的优点来进行加密传输。
比如既然对称密钥的优点是加解密效率快，那么在客户端与服务端确定了连接之后就可以用它来进行加密传输。不过前提是得解决双方都能安全的拿到这把对称密钥。这时候就可以利用非对称密钥加密来传输这把对称密钥，因为我们知道非对称密钥加密的优点就是能保证传输的内容是安全的。
所以它的好处是即保证了对称密钥能在双方之间安全的传输，又能使用对称加密方式进行通信，这比单纯的使用非对称加密通信快了很多。以此来解决了HTTP中内容可能被窃听的问题。
Q2：那混合加密的缺点呢？
难度：🌟🌟
混合加密主要是为了解决HTTP中内容可能被窃听的问题。但是它并不能保证数据的完整性，也就是说在传输的时候数据是有可能被第三方篡改的，比如完全替换掉，所以说它并不能校验数据的完整性。如果需要做到这一点就需要使用到数字签名。
4.1.4 HTTPS的工作流程
（简单的叙述，如果面试官要听具体的过程可以看文章后续部分的 4.2 几种版本的握手）
难度：🌟🌟🌟
HTTPS主要是采用对称密钥加密和非对称密钥加密组合而成的混合加密机制进行传输。
也就是发送密文的一方用"对方的公钥"进行加密处理"对称的密钥"，然后对方在收到之后使用自己的私钥进行解密得到"对称的密钥"，这在确保双发交换的密钥是安全的前提下使用对称密钥方式进行通信。
这个过程简单来说就是：
- 客户端首先向服务端发送一个HTTPS请求
- 服务端会把事先配置好的公钥证书随着其它的信息返回给客户端
- 客户端在收到服务端发来的证书之后进行验证，验证的过程参考数字证书验证，会得到服务端的信息以及它的公钥
- 验证成功之后生成一个叫做 client_params 的参数发送给服务器；同时自己会用伪随机函数生成一个 secret，这个secret就是它们后续进行通信的对称密钥。
- 服务器在收到刚刚的 client_params之后，也会根据伪随机函数生成一个secret。这时候双方都有了相同的对称密钥。
- 后面的传输都会用这个 secret 进行对称密钥加解密传输
4.1.5 对称密钥加密和非对称密钥加密的区别
难度：🌟🌟
对称密钥加密是最简单的一种加密方式，它的加解密用的都是相同的密钥，这样带来的好处就是加解密效率很快，但是并不安全，如果有人拿到了这把密钥那谁都可以进行解密了。
而非对称密钥会有两把密钥，一把是私钥，只有自己才有；一把是公钥，可以发布给任何人。并且加密的内容只有相匹配的密钥才能解。这样带来的一个好处就是能保证传输的内容是安全的，因为例如如果是公钥加密的数据，就算是第三方截取了这个数据但是没有对应的私钥也破解不了。不过它也有缺点，一是公钥因为是公开的，谁都可以过去，如果内容是通过私钥加密的话，那拥有对应公钥的黑客就可以用这个公钥来进行解密得到里面的信息；二来公钥里并没有包含服务器的信息，也就是并不能确保服务器身份的合法性；并且非对称加密的时候要消耗一定的时间，减低了数据的传输效率。
4.2 解决内容被篡改(数字签名)
4.2.1 一些基本概念
数字签名的产生原因：虽然有了混合加密机制保证了内容不被监听，但是传输的数据可能会被篡改(比如完全替换掉)，即不能校验数据的完整性。而数字签名就是为了校验数据的完整性。
功能特点：
- 能确定消息确实是发送方签名并发出来的，因为别人假冒不了发送方的签名。
- 能确定内容的完整性，证明数据没有被篡改过。
Hash函数：
- 也就是哈希函数，哈希摘要函数，散列函数。
- 简单的说就是一种将任意长度的消息压缩到某一固定长度的消息摘要的函数。
4.2.2 数字签名的具体过程
（数字签名的概念以及验证流程）
难度：🌟🌟🌟
数字签名的产生主要就是为了解决HTTP中内容可能被篡改的问题，即校验数据的完整性。它能确定消息是发送方发送过来的，因为这里会有一个验证数字签名的过程，别人是假冒不了发送方的签名的。
数字签名它是什么呢？它的产生过程其实就是两步，第一步将原文用Hash函数生成一个叫消息摘要的东西，第二步就是用发送方的私钥对这个消息摘要进行进行加密。这个产生的东西就叫做数字签名，它一般会与原文一起发送给接收者。
而验证它的过程其实也并不复杂。
- 首先发送方会将原文与数字签名(也就是加密后的摘要)一起发送给接收方
- 接收方会接收到这两样东西，即原文和数字签名
- 接收方用Hash函数处理原文会得到一份消息摘要
- 同时用发送方的公钥解密数字签名也会得到一份消息摘要
- 只要比较这两份消息摘要是否相等就可以验证出数据有没有被篡改了
当然这里关键的一步就是要保证发送方传递过来的公钥是可信赖的，这时候就得用到数字证书了。
让我们来看看数据签名的流程图：
4.3 解决通信方身份遭伪装(数字证书)
4.3.1 数字证书的概念
难度：🌟🌟🌟
数字证书也叫公钥证书，或者简称证书。它主要是为了解决通信方身份遭伪装的问题，也就是验证通信方的身份。
因为我们知道在HTTPS中虽然有了混合加密机制保证数据不被监听，有了数字签名校验数据的完整性，但是数字签名校验的前提是能拿到发送方的公钥，并且保证这个公钥是可信赖的，所以就需要数字证书。
它简单来说其实是由一些权威的数字认证机构颁发给服务器的一个文件。数字认证机构简称CA，它是客户端和服务端都信任的第三方机构，我知道比较有名的一个就是威瑞信(VeriSign)。
4.3.2 数字证书的颁发流程
- 服务器的运营人员会向认证机构提交自己的公钥、组织信息、个人信息等并申请认证
- 而认证机构在拿到这些信息后会通过线上、线下各种途径验证申请者提交信息的真实性
- 在确认其真实性后，认证机构给这些信息(申请者的公钥，组织信息，个人信息以及认证机构自己的信息等)，我们简称为明文信息，进行数字签名，过程也就是签名提到的数字签名的步骤：
- 1.通过Hash函数处理明文信息生成一个信息摘要；
- 2.再用认证机构自己的私钥对信息摘要进行加密处理。
- 通过这两个步骤生成的文件就叫数字签名。
- 之后会将明文信息和数字签名组合而成的证书颁发给申请者，也就是服务器。
下图是证书的颁发流程：
4.3.3 证书的组成
主要由两部分组成：
- 明文信息
- 申请者的公钥
- 申请者的组织信息、个人信息
- 签发机构CA的信息
- 有效时间、证书序列号等明文信息
- 签名
- 它的产生过程其实就是上面介绍到的数字签名的产生
- 产生过程：CA先是通过Hash函数对公开的明文信息做处理生成一个信息摘要，接着用自己的私钥对信息摘要加密生成签名。
这些明文信息和这个签名组合起来就叫做证书，认证机构会把证书颁发给申请者(服务器)。
4.3.4 为什么说数字证书就能对通信方的身份进行验证呢？
（数字证书使得浏览器能验证服务器，还有它的验证过程）
难度：🌟🌟🌟
那是因为在客户端第一次给服务端发送HTTPS请求的时候，服务端会将它自己的证书随着其它的信息(例如server_random、 server_params、需要使用的加密套件等东西)一起返给客户端。
客户端在收到之后首先会验证这个证书，只有验证通过之后才会有后续操作。而验证的过程其实也就是数字签名的验证过程(题5)：
- 前面说过了，证书其实是由明文信息(申请者的公钥，组织信息，个人信息以及认证机构自己的信息等)和这个明文信息的数字签名组成的。(对应着题5也就是原文和数字签名)
- 客户端会用Hash函数处理明文信息生成一个信息摘要
- 然后再用内置在浏览器上的CA的公钥来解密证书里的数字签名，得到一个信息摘要。因为我们知道证书实际是由CA颁发给服务器的，并且里面的数字签名也是用的CA的私钥加密的，所以只有CA的公钥才能解。
- 最后再将两个信息摘要进行对比，若是一样则能保证通信方的身份是正确的。
其实验证证书的过程不仅仅是数字签名的验证，客户端还会验证证书相关的域名信息，有效时间，是不是在CRL吊销列表里，以及它的上一级是否有效等等。
（一般答到这里就可以了，如果面试官继续问你上一级是否有效这样验证，你就回答：这是一个递归的过程，直到验证到根证书也就是操作系统内置的Root证书或者浏览器内置的Root证书为止）
就像前面说的，只有能用CA的公钥解密的数字签名并且通过了认证的证书才是有效的，因为证书是CA颁布的。这也就保证了客户端收到的服务器发来的公钥是真实可用的(因为公钥在证书的明文信息里)。
（想想其实很好理解，因为浏览器它自己没有辨别证书是否合法的能力，它就把这事交给CA去做，CA是信任的过的机构，它只要把自己的公钥内嵌到浏览器里，浏览器再用这个CA公钥来解证书里的签名就可以了。而证书的签名也是经过CA的私钥加密生成的，只有CA的公钥能解，但它的公钥又不是随便人能拿到的，只有各大浏览器厂商才有，所以这就是数字证书的验证过程）
5. SSL/TLS
5.1 基本概念
SSL 安全套接层(Secure Sockets Layer)
TSL 传输层安全(Transport Layer Security)
版本：
SSL出过三个大版本，在第三个版本的时候被标准化成为 TLS，并被当成 TLS的第一个版本，即：
SSL3.1 = TLS1.0
之前的TLS1.0、TLS1.1都被认为是不安全的，当前主流版本是TLS1.2，2018年推出了更优秀的TSL1.3。
5.2 几种版本的握手
在HTTPS加密传输中，实际上涉及到 SSL/TLS 协议，这里是有一个TSL握手的过程。主要是分为了两部分：
- 传统的TLS握手也就是RSA握手；
- 现在主流的TLS1.2版本的握手，也就是ECDHE握手。
面试时可以表示自己都知道这两类握手，不过如果要挑一个说的话，个人认为可以介绍一下现在主流的TLS1.2版本的握手，请看下面的4.2.1。
5.2.1 主流的TLS1.2版本的握手，即ECDHE握手
难度：🌟🌟🌟🌟
它的过程大致来说是这样的：
-
客户端在第一次发送HTTPS请求的时候，会把 client_random、TSL版本号、加密套件列表发送给服务器
-
服务器在接收到之后确认TSL的版本号，同时发送 server_random、server_params、需要使用的加密套件、以及自己的证书给客户端
-
客户端在收到这些信息之后，首先是会对服务器的证书进行验证(也就是题目7)，若是验证成功则会传递一个 client_params 给服务器
-
与此同时客户端会通过ECDHE算法计算出一个pre_random，其中是传入了两个参数，一个是 client_params，还一个是 server_params。(也就是说：ECDHE(client_params, server_params) = per_random)
-
这时候客户端就同时拥有了 client_random、server_random、pre_random，它会将这三个参数通过一个伪随机函数计算得出最终的secret，这个secret就是它们后续通信所要用的对称密钥。
-
而在客户端生成完secret之后，会给服务器发送一个收尾消息，告诉服务器之后都要用对称加密，且对称加密的算法是用第一次约定好的。
-
服务器它在接收到刚刚传递过来的client_params之后，也会使用和客户端一样的方式生成secret，并且也会发送一个收尾消息给客户端。
-
当双方都收到收尾消息并验证成功之后，握手就结束了。后面开始用这个secret对称密钥加密报文进行传输。
（ECDHE基于椭圆曲线离散对数，传入的两个参数也被叫做椭圆曲线的公钥）
（此时面试官如果要问你RSA握手的细节就看题目 4.2.2和 4.2.3。如果不的话可能会问你RSA握手和ECDHE握手的区别，就看题目4.2.4）
5.2.2 可我就是想你描述一下RSA握手
（这道题主要是怕面试官还想你再描述一下RSA握手，当然你也可以先用这个简单的版本说给他听，详细描述看题4.2.3）
难度：🌟🌟🌟
- 客户端首先向服务端发送一个HTTPS请求
- 服务端会把事先配置好的公钥证书随着其它的信息返回给客户端
- 客户端在收到服务端发来的证书之后进行验证，验证的过程参考数字证书验证，会得到服务端的信息以及它的公钥
- 验证成功之后会用伪随机函数计算出一个加密所需要的对称密钥(secret)，并且用服务端的公钥加密这个对称密钥发送给服务端
- 服务端再用自己的私钥解密刚刚的消息，得到里面的对称密钥。此时服务端和客户端都有了对称密钥。
- 后面的传输都会用这个 secret 进行对称密钥加解密传输
5.2.3 能否详细描述一下RSA握手呢？
（还问你细节的话...就用这套）
难度：🌟🌟🌟🌟
- 客户端首先发送 client_random、TSL版本号、加密套件列表给服务器
- 服务器在接收到之后确认TSL版本号，同时发送server_random、需要使用的加密套件、自己的证书给客户端
- 客户端在收到这些信息之后，首先是会对服务器的证书进行验证(也就是题目7)，若是验证成功则会用RSA算法生成一个pre_random，且用服务器的公钥(在证书中)加密pre_random发送给服务器。
- 此时，客户端有了 client_random、server_random、pre_random，它会将这三个参数通过一个伪随机函数计算得出最终的secret，这个secret就是它们后续通信所要用的对称密钥。
- 服务器接收到了刚刚用自己公钥加密的pre_random之后，用自己的私钥进行解密，得到里面的 pre_random，用和客户端一样的方式生成secret。
- 之后就用这个 secret对称密钥加密报文传输。
（可以和4.2.1做一个对比，你很容易就可以看出，只是 step3 ，4，5不同而已）
5.2.4 那么ECDHE握手和RSA握手又有什么区别呢？
难度：🌟🌟🌟
它们的区别主要是：
- 生成secret(对称密钥)的过程不同。RSA中是使用RSA算法生成一个pre_random并用服务器的公钥加pre_random发送给服务器，然后各自用伪随机函数生成相同的secret对称密钥；而在ECDHE握手中，它没有用到RSA算法，而是用ECDHE算法生成的pre_random，且这个过程中比RSA多了client_params和server_params两个参数。
- 在生成完secret之后，ECDHE握手在客户端发送完收尾消息后可以提前
抢跑，直接发送 HTTP 报文，节省了一个 RTT，不必等到收尾消息到达服务器，然后等服务器返回收尾消息给自己，直接开始发请求。这也叫TLS False Start。 - 最主要的：RSA不具备向前安全性，ECDHE有
（向前安全性：一次破解并不影响历史信息的性质就是向前安全性）
5.2.5 向前安全性
难度：🌟🌟
一句话概括：一次破解并不影响历史信息的性质就是向前安全性。
比如在RSA握手的过程中，客户端拿到了服务端的公钥，然后用此公钥加密pre_random给服务端。如果此时有第三方有服务端的私钥，并且截获了之前所有报文的时候，那么它就可以破解这段密文并拿到pre_random、client_random、server_random并根据对应的伪随机函数生成secret，即拿到了最终通信的对称密钥，每一个历史报文都能通过这样的方式进行破解。它就不具有向前安全性。
但是ECDHE在每次握手的时候都会产生一个零时的密钥对(也就是client_params、server_params)，即使第三方有了私钥能破解，但是对之前的历史报文并没有影响。它就具有向前安全性。
5.3 TSL1.3版本吗？它较TSL1.2做了哪些改进
难度：🌟🌟
TSL1.3版本是2018年推出的。它较TSL1.2主要是做了以下改进：
- 强化安全
废除了很多的加密算法，只保留了5个加密套件。其中最主要的是废弃了RSA，因为在2015年发现了PRAEK攻击，即已经有人发现了RSA的漏洞能进行破解；而且RSA不具备向前安全性。
- 提高性能
同时利用会话复用节省了重新生成密钥的时间，利用 PSK 做到了0-RTT连接。
6. 为何不是所有网站都用HTTPS？
难度：🌟🌟
- HTTPS的实施需要门槛，因为从证书的选择、购买，再到部署，传统模式下都比较耗时耗力
- 另外大家普遍认为HTTPS会更慢一些，因为相比于HTTP的明文传输它的加密通信会消耗更多的CPU及内存资源
- (但其实用户可以通过性能优化，把证书部署到SLB(负载均衡)或者CDN来解决这个问题。)
- 购买证书需要开销
- 国内安全意识可能没那么强
参考文章
- 《图解HTTP》
