01-从HTTP到HTTPS

一、HTTP报文结构

http协议是Hyper Test Transfer Protocol（超文本传输协议）的缩写，是服务器和本地浏览器之间的传送协议。用于 HTTP 协议交互的信息被称为 HTTP 报文，客户端的 HTTP 报文叫做请求报文；响应端（服务器端）的叫做响应报文，HTTP 报文本身是由多行数据构成的字符串文本。

1.1、HTTP 请求报文结构：

HTTP 报文大致可分为请求行、请求头、空行、请求主体四部分。也有人将报文分为请求首部（请求行+请求头）、空行、请求主体。通常，前几部分是必有的，最后的请求体不是必有的，每个部分结尾都用空行来作为结束标志。

• 请求行：请求方法（Method） + 空格 + 统一资源标识符（URI） + 空格 + HTTP版本 + CR LF ；
• 请求头：字段名 + 冒号 + 值 + CRLF ；
• 空行： 回车符（CR）+ 换行符（LF） ；
• 请求体： 由用户自定义添加，如post的body等；

请求首部实例（谷歌浏览器Network面板）：

1.2、HTTP 响应报文结构：

响应报文结构与请求报文结构唯一的区别在于第一行中用状态信息代替了请求信息。状态行（status line）通过提供一个状态码来说明所请求的资源情况。

• 状态行：HTTP版本 + 空格 + 状态码 + 空格 + 状态码描述 + CR LF ；
• 响应头：字段名 + 冒号 + 值 + CR LF ；
• 空行： 回车符（CR）+ 换行符（LF） ；
• 响应体： 由用户自定义添加，如post的body等；
• 响应首部实例（谷歌浏览器Network面板）：

二、HTTP的缺点

在HTTP协议中有可能存在信息窃取或身份伪装等安全问题。

2.1、通信使用明文（不加密）

由于HTTP本身不具备加密的功能，所以也无法做到对通信整体（使用HTTP协议通信的请求和响应的内容）进行加密。即，HTTP报文使用明文（指未经过加密的报文）方式发送。
HTTP明文协议的缺陷是导致数据泄露、数据篡改、流量劫持、钓鱼攻击等安全问题的重要原因。HTTP协议无法加密数据，所有通信数据都在网络中明文“裸奔”。通过网络的嗅探设备及一些技术手段，就可还原HTTP报文内容。
可以看到窃听无处不在
窃听的方式有多种，比较常见有抓包工具（Wireshark）或者嗅探器（Sniffer）或 （Fiddler）等工具。

2.2、无法证明报文的完整性

同样是在A到B传输过程中，数据包被劫持、篡改之后继续传输，虽然接收方收到的数据包就是发送方发送的那个，但是内容已经遭到篡改，这样无法保证报文的完整性。

2.3、不验证通信方的身份，因此有可能遭遇伪装

HTTP协议中的请求和响应不会对通信方进行确认。在HTTP协议通信时，由于不存在确认通信方的处理步骤，任何人都可以发起请求。另外，服务器只要接收到请求，不管对方是谁都会返回一个响应（但也仅限于发送端的IP地址和端口号没有被Web服务器设定限制访问的前提下）
HTTP协议无法验证通信方身份，任何人都可以伪造虚假服务器欺骗用户，实现“钓鱼欺诈”，用户无法察觉。

三、HTTPS协议

HTTPS并非是应用层的一种新协议。只是HTTP通信接口部分用SSL和TLS协议代替而已。
通常，HTTP直接和TCP通信。当使用SSL时，则演变成先和SSL通信，再由SSL和TCP通信了。简言之，所谓HTTPS，其实就是身披SSL协议这层外壳的HTTP。

在采用SSL后，HTTP就拥有了HTTPS的加密、证书和完整性保护这些功能。也就是说HTTP加上加密处理和认证以及完整性保护后即是HTTPS。
HTTPS主要作用是：
（1）对数据进行加密，并建立一个信息安全通道，来保证传输过程中的数据安全;
（2）对网站服务器进行真实身份认证。

四、HTTPS如何解决HTTP上述问题?

4.1、解决内容可能被窃听的问题——加密

方法1.对称加密

这种方式加密和解密同用一个密钥。加密和解密都会用到密钥。没有密钥就无法对密码解密，反过来说，任何人只要持有密钥就能解密了。

该方式存在的问题：
服务端去制定秘钥K的时候，它不知道一共有多少客户端，也不可能为每一个客户端制定一个秘钥key,因为那样的话，假设有1亿个客户端，那么服务端就要存储1亿个秘钥key，那么这样的话,秘钥key的存储比业务是数据的存储都大，所有一般服务端只有一个秘钥key。
如果服务端只有一个key, 那么黑客也可以获取到这个key。黑客在正常状态下是充当一个普通的客户端，其实也是可以获取到这个key的。黑客那么此时就可以获取到客户端发送数据的信息。

方法2.非对称加密

非对称加密使用一对非对称的密钥。一把叫做私有密钥，另一把叫做公开密钥。顾名思义，私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得。
使用公开密钥加密方式，发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走。

非对称加密的特点是信息传输一对多，服务器只需要维持一个私钥就能够和多个客户端进行加密通信。

这种方式有以下缺点：

• 公钥是公开的，所以针对私钥加密的信息，黑客截获后可以使用公钥进行解密，获取其中的内容；
• 公钥并不包含服务器的信息，使用非对称加密算法无法确保服务器身份的合法性，存在中间人攻击的风险，服务器发送给客户端的公钥可能在传送过程中被中间人截获并篡改；
• 使用非对称加密在数据加密解密过程需要消耗一定时间，降低了数据传输效率；

方法3.对称加密+非对称加密(HTTPS采用这种方式)

使用对称密钥的好处是解密的效率比较快，使用非对称密钥的好处是可以使得传输的内容不能被破解，因为就算你拦截到了数据，但是没有对应的私钥，也是不能破解内容的。就将对称加密与非对称加密结合起来,充分利用两者各自的优势，在交换密钥环节使用非对称加密方式，之后的建立通信交换报文阶段则使用对称加密方式。

该方式的原理：

1. 客户端请求服务端获取服务端的公钥Key

2. 服务端返回自己的公钥给客户端

3. 客户端生成秘钥num1, 并且使用非对称加密的方式，使用服务端的公钥进行加密传输

4. 服务端使用自己的私钥解密出 秘钥num1，并且返回ok给客户端（这个过程中，即使黑客拦截到了num1加密之后的数据，由于是没有私钥的，所以无法进行解密）

5. 后面客户端与服务端之间的数据传输就使用num1为秘钥进行对称加密

4.2、数据完整性

网络传输过程中需要经过很多中间节点，虽然数据无法被解密，但可能被篡改，那如何校验数据的完整性呢？----校验数字签名。
数字签名有两种功效：

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

数字签名如何生成:

将一段文本先用Hash函数生成消息摘要，然后用发送者的私钥加密生成数字签名，与原文文一起传送给接收者。接下来就是接收者校验数字签名的流程了。
校验数字签名流程：

接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用HASH函数对收到的原文产生一个摘要信息，与上一步得到的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性。
假设消息传递在A，B两人之间发生。A将消息连同数字签名一起发送给B，B接收到消息后，通过校验数字签名，就可以验证接收到的消息就是A发送的。当然，这个过程的前提是B知道A的公钥。问题的关键的是，和消息本身一样，公钥不能在不安全的网络中直接发送给B, 或者说拿到的公钥如何证明是A的。
此时就需要引入了证书颁发机构（Certificate Authority，简称CA），CA数量并不多，B客户端内置了所有受信任CA的证书。CA对James的公钥（和其他信息）数字签名后生成证书。
数字签名有两种功效：

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

4.3、身份认证

我们来介绍一下数字证书认证机构的业务流程：

• 服务器的运营人员向第三方机构CA提交**公钥、组织信息、个人信息(域名)**等信息并申请认证;
• CA通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等;
• 如信息审核通过，CA会向申请者签发认证文件-证书。**证书包含以下信息：**申请者公钥、申请者的组织信息和个人信息、签发机构 CA的信息、有效时间、证书序列号等信息的明文，同时包含一个签名。 其中签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用 CA的私钥对信息摘要进行加密，密文即签名;
• 客户端 Client 向服务器 Server 发出请求时，Server 返回证书文件;
• 客户端 Client 读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应 CA的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即服务器的公开密钥是值得信赖的。
• 客户端还会验证证书相关的域名信息、有效时间等信息; 客户端会内置信任CA的证书信息(包含公钥)，如果CA不被信任，则找不到对应 CA的证书，证书也会被判定非法。

参考文章：

参考文章：

https://juejin.cn/post/6844903630533836807

https://www.cnblogs.com/zhjh256/p/12541893.html

https://www.bilibili.com/video/BV1M44y1175D?spm_id_from=333.337.search-card.all.click&vd_source=c3d1cfe6ba078f657468853c28453471

HTTPS更多系列关注”前后端技术精选“