HTTPS协议
目录
一、基本介绍
二、HTTPS的工作过程
一、基本介绍
HTTPS 也是⼀个应用层协议，在 HTTP 协议的基础上引入了⼀个加密层。HTTP 协议内容都是按照文本的方式明文传输的，这就导致在传输过程中出现⼀些被篡改的情况。在互联网上, 明文传输是比较危险的事情，HTTPS 就是在 HTTP 的基础上进行了加密, 进一步的来保证用户的信息安全。
比如臭名昭著的 "运营商劫持"。由于我们通过网络传输的任何的数据包都会经过运营商的网络设备(路由器, 交换机等), 那么运营商的网络设备就可以解析出你传输的数据内容, 并进⾏篡改。
点击 "下载按钮", 其实就是在给服务器发送了⼀个 HTTP 请求, 获取到的 HTTP 响应其实就包含了该APP 的下载链接。运营商劫持之后, 就发现这个请求是要下载天天动听, 那么就自动的把交给用户的响应给篡改成 "QQ浏览器" 的下载地址了。
不⽌运营商可以劫持, 其他的黑客也可以⽤类似的⼿段进行劫持, 来窃取用户隐私信息, 或者篡改内容。
几个核心概念：
- 明文：要传输的原始数据
- 密文：把明文进行加密之后得到一个让别人不能理解的数据
- 加密：明文 -> 密文
- 解密：密文 -> 明文
- 密钥：进行加密和解密的重要数据/辅助工具
二、HTTPS的工作过程
既然要保证数据安全, 就需要进行"加密"。网络传输中不再直接传输明文了，而是加密之后的 "密文"。加密的方式有很多, 但是整体可以分成两大类: 对称加密 和 非对称加密。
- 对称加密：无论是加密还是解密，使用同一个密钥
- 非对称加密：一对密钥（从数学角度生成的一对数），使用其中的一个加密，用另一个解密。其中公开出来的那个密钥称为“公钥”，剩下那个私藏起来的密钥称为“私钥”。
引入对称加密之后，即使数据被截获，由于黑客不知道密钥是啥，因此就无法进行解密， 也就不知道请求的真实内容是啥了。
但事情没这么简单。 服务器同一时刻其实是给很多客户端提供服务的，这么多客户端，每个人用的秘钥都必须是不同的(如果是相同那密钥就太容易扩散了，黑客就也能拿到了，就像不能每个人的银行卡密码相同)。因此服务器就需要维护每个客户端和每个密钥之间的关联关系，这也是个很麻烦的事情。
比较理想的做法是要求让每个客户端连上服务器的时候，自己生成一个随机的对称密钥，服务器也得拿到这个密钥，才能解密。 就是在客户端和服务器建立连接的时候, 双方协商确定这次的密钥是啥。但密钥也是明文传的，黑客一得到密钥，后续的加密也没有起到作用了。
非对称加密并非用来替代对称加密，而是辅助。业务数据仍然是对称加密，通过非对称加密对要传输的对称密钥进行加密。为什么不都用非对称加密？因为非对称加密运算量开销比较大，比较消耗性能。
客户端持有公钥，对“密文请求（密钥是888888）”这个数据的解密是需要私钥的，黑客由于没有私钥，就没法解密获得对称密钥，进而不能解密数据。
公钥可以随便公开，只要把私钥保护好就行了。
但还有缺陷 -> 中间人攻击
针对中间人攻击，引入证书机制
问题的关键，能够让客户端识别出，拿到的公钥是不是正确的，合理的，不是伪造的公钥，此处，需要引入第三方公证机构。
如果想搭建服务器，使用HTTPS，就需要在公证机构申请证书（电子，一串数据），申请的时候就需要提交一些资料，比如网站的域名，营业执照，备案号，公钥是啥等，公证机构就能生成一个“电子证书”，这个证书可以理解成是⼀个结构化的字符串, 里面包含了以下信息：
服务器获得申请到的证书之后，后续客户端从服务器拿公钥，就不只是拿公钥，而是拿整个证书，此时客户端就可以凭借手中的数字签名，对证书的合法性进行验证。
签名（校验和+加密）保证了证书合法性的关键要点。原始数据相同，计算得到的校验和就相同，校验和不同，说明原始数据就不同。
签名的生成：公证机构生成一对公钥私钥，公证机构保存好私钥，公钥则发给各个客户端。公正机构将证书中的各个字段综合在一起，计算校验和，拿着自己的私钥对刚才的校验和进行非对称加密 ，于是就得到了数字签名。客户端验证：
- 把证书的各个字段再算一遍校验和，得到checksum1
- 然后客户端使用公正机构的公钥，对数字签名进行解密，得到checksum2
- 对比checksum1是否相等，如果相等，视为当前证书的各个字段，就是和服务器这边发出来的证书是一摸一样的；如果不相等，意味着证书上的内容被中间的黑客篡改过了，此时浏览器往往会弹出警告界面，提示用户该网站不安全
可靠性讨论：
- 客户端手里拿着公证机构的公钥，客户端如何确定这个公证机构的公钥是正确的，不是黑客伪造的呢？这个东西不是通过网络获取的，而是操作系统内置的。
- 黑客可不可以篡改数据后，同时更新数字签名，让数字签名机密出来的checksum2，和篡改过的checksum1一致呢？理论上是不可行的。黑客篡改了数据之后，要想重新生成一个数字签名，需要使用公证机构的私钥来加密。（这个私钥不是黑客能拿到的）
- 黑客如果自己生成一个私钥呢？这个时候客户端拿着公证机构的公钥，也解密不了，此时客户端解密出错，也可以认为证书有问题，也会弹出大大的窗口。
另：Fiddler等抓包工具，为啥能解析HTTPS的数据？它们能够拿到对称密钥，才能对数据解密。Fiddler就在对我们进行中间人攻击，我们允许它对我们进行攻击。（开启https选项，弹出一个框，是否信任Fiddler提供的证书~）
面试会遇到原题
- 引入对称加密
- 传输对称密钥
- 对对称密钥进行加密，引入非对称加密
- 中间人攻击
- 引入证书，解决中间人攻击
经典面试题
在浏览器输入url之后，到最终展示出页面为止，这个过程计算机都做了哪些事情？
- 站在网络原理的角度
a）DNS解析
b）HTTPS HTTPS的握手过程（对称加密，非对称加密，中间人攻击，证书...)
c）HTTP 浏览器构造HTTP请求，服务器返回HTTP响应（HTTP都有啥）
d）TCP TCP三次握手，TCP确认应答，超时重传...
e）IP IP如何管理，IP地址，IP如何进行数据转发
f） 数据链路层 以太网- 站在服务器后端开发的角度
单机架构
a）服务器如何处理HTTP请求（Spring)
b) 根据请求计算响应(业务逻辑)
c) 把响应返回给客户端（Spring）
分布式系统/微服务架构
a）网关
b) 分发给应用服务器
c) 分发过程涉及到服务发现，负载均衡
d) 应用服务器又涉及到操作数据库，操作redis,操作mq...
e) 服务器之间通过rpc进行相互调用- 站在网页前端的角度
HTTP请求是怎样在浏览器中构造的
拿到的HTTP响应怎样被浏览器解析的
如何对上述过程进一步进行优化
搭配上一些Vue这样的框架~~