本博客 hjy-xh，转载请申明出处
HTTP 存在的问题
提到 HTTP ，大家的第一印象就是不安全，那它到底是哪里不安全呢？
先说说 HTTP 的基本信息：它属于应用层的协议， 基于TCP/IP，通过 TCP 协议进行传输，依靠 IP 协议进行寻址
网络中的数据是以包的形式在网络模型各层之间传递的，而 HTTP 的数据报文在这些层之间都是没有加密的明文，那么它就会引发以下的一些问题：
- 内容可能被窃听
通信时，中间会经历很多个阶段，而每个阶段报文内容都有可能会被窃听 - 无法验证接收报文的完整性（可能会被篡改）
无法验证接收到报文是否被篡改，比如说被删除了一部分或者新增了一部分 - 没有验证通信双方的身份（可能被冒充）
无法判断请求是来自何方，出自谁手
什么是 HTTPS？
HTTPS 中的 S 代表“安全”。HTTPS 使用 TLS（或 SSL）来加密HTTP 请求和响应
TLS 使用一种称为公钥加密的技术：密钥有两个，即公钥和私钥，其中公钥通过服务器的 SSL 证书与客户端设备共享。当客户端打开与服务器的连接时，这两个设备使用公钥和私钥商定新的密钥（称为会话密钥），以加密它们之间的后续通信。
然后，所有 HTTP 请求和响应都使用这些会话密钥进行加密，使任何截获通信的人都只能看到随机字符串，而不是明文
HTTPS 做了什么？
HTTPS 解决了 HTTP 存在的问题，也就是它解决了三个问题：
- 加密：HTTPS 通过对数据加密来使其免受窃听者对数据的监听，这就意味着当用户在浏览网站时，没有人能够监听他和网站之间的信息交换，或者跟踪用户的活动，访问记录等，从而窃取用户信息
- 数据一致性：数据在传输的过程中不会被窃听者所修改，用户发送的数据会完整的传输到服务端，保证用户发的是什么，服务器接收的就是什么
- 身份认证：是指确认对方的真实身份，也就是证明你是你（可以比作人脸识别），它可以防止中间人攻击并建立用户信任。
HTTPS 采用混合加密机制，也就是对称加密与非对称加密混用来实现加密机制
首先得先了解几个概念：
- 加密：将明文变换为密文的过程
- 解密：加密的逆过程，即由密文恢复出原明文的过程
- 密钥：指某个用来完成加密、解密、完整性验证等密码学应用的秘密信息
- 对称加密：加密和解密采用同一个密钥
- 非对称加密：加密和解密的时候采用的是不同的密钥
加密
非对称加密相比对称加密更加复杂，效率更低，在前端业务中一般都是存在大量的 HTTP 请求，所以非对称加密的低效是无法被接受的。此外，非对称加密的场景只在服务端保存私钥，也就是说一对公私钥只能单向传输数据，因此可以用来确认通信安全以及服务端返回证书。确认安全之后，传输数据采用的就是速度更快的对称加密，因此可以简单记忆如下阶段：
- 证书交换验证阶段–>非对称加密
- 客户端发起 HTTPS 请求
- 服务端返回 HTTPS 证书
- 客户端验证证书是否合法，不合法则提示警告
- 数据传输阶段–>对称加密
- 当证书验证合法后，在本地生成随机密码串
- 通过公钥加密随机密码串，并把结果传给服务器端
- 服务端通过撕咬对接机密码解密
- 服务端通过客户端传入的随机密码穿构建对称加密算法，对返回结果内容进行加密后传输
数据完整性
确保数据完整性，也就意味着数据安全没有被第三方篡改，这时候就需要通过 数字签名
数字签名是一段由发送者生成的特殊加密校验码，用于传输过程中确认报文的完整性。数字签名涉及到了两种技术：非对称加密 和 数字摘要。生成数字摘要的算法通过 MD5 和 SHA 这种不可逆算法，将不定长的报文内容提取出定长的数字摘要
假设现在有通信双方A和B，两者之间使用两套非对称加密机制
现在A向B发消息，那么，如果在发送过程中，有人修改了里面密文消息，B拿到的密文，解密之后得到明文，并非A所发送的，信息不正确
要解决两个问题
- A的身份认证
- A发送的消息完整性
那么就要进行以下操作：
- 将明文进行摘要运算后得到摘要（消息完整性）
- 再将摘要用A的私钥加密（身份认证），得到数字签名，将密文和数字签名一块发给B
- B收到报文后，使用相同的摘要算法提取出摘要，将数字签名用A的公钥进行解密后，得到正确的摘要
证书
上面加密的过程也存在一个问题，安全的本质是使用密钥进行加密。但是如果密钥本身就有问题，那么安全也就无从谈起，因此这个密钥必须是通信双方认可的。这个工作不能交给客户端做，也不能服务端做，一半交给第三方权威机构 – 数字证书认证机构（CA，Certificate Authority）
认证机关的公开密钥必须安全地转交给客户端，使用通信方式是，如何安全转交是一件很困难的事，因此多数浏览器发布版本时，都会是现在内置常用认证机关的公钥
浏览器是如何确保 CA 证书的合法性？
浏览器发起 HTTPS 请求时，服务器会返回网站的 SSL 证书，浏览器需要对证书做以下验证：
- 验证域名、有效期等信息
- 判断证书来源是否合法
- 每份签发证书都可以根据验证链查找到对应的根证书，操作系统、浏览器会在本地存储权威机构的根证书，利用本地根证书可以对对应机构签发证书完成来源验证
- 判断证书是否被篡改
- 需要与 CA 服务器进行校验
- 判断证书是否已吊销
- 通过CRL（Certificate Revocation List 证书注销列表）和 OCSP（Online Certificate Status Protocol 在线证书状态协议）实现，其中 OCSP 可用于第3步中以减少与 CA 服务器的交互，提高验证效率
HTTPS 工作流程
HTTPS 的整个通信过程可以分为两大阶段：
- 证书验证
- 数据传输阶段
- 非对称加密
- 对称加密
- 客户端请求 HTTPS 网址，然后连接到 server 的 443 端口 (HTTPS 默认端口，类似于 HTTP 的80端口)
- 服务器响应客户端请求，将证书传递给客户端，证书包含公钥和大量其他信息，比如证书颁发机构信息，公司信息和证书有效期等
- 客户端解析证书并对其进行验证
- 如果证书不是可信机构颁布，或者证书中的域名与实际域名不一致，或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信
- 如果证书没有问题，客户端就会从服务器证书中取出服务器的公钥A。然后客户端还会生成一个随机码 KEY，并使用公钥A将其加密
- 客户端把加密后的随机码 KEY 发送给服务器，作为后面对称加密的密钥
- 服务器在收到随机码 KEY 之后会使用私钥B将其解密
经过以上这些步骤，客户端和服务器终于建立了安全连接，完美解决了对称加密的密钥泄露问题，接下来就可以用对称加密愉快地进行通信了 - 双方使用对称加密愉快地传输所有数据
HTTPS 绝对安全吗
HTTPS 也会被抓包，只不过内容被加密过
但是用户可以主动对证书进行授权，如果用户授权通过，那么代理软件是可以对传输内容进行解密的
