HTTPS为什么安全，流程？
文章目录
-
- HTTPS为什么安全，流程？
-
- 对称、非对称混合加密
- 证书认证和完整性校验
- 流程
HTTPS为什么安全，流程？
对称、非对称混合加密
首先，我们先来看HTTP为什么不安全。
HTTP没有对通信内容进行加密，是明文传输，信息可能会被劫持、篡改等，相当于在互联网上裸奔，所以是不安全的。
那么HTTPS主要就是为了解决这个问题，而解决这个问题肯定要对传输的明文进行加密，让其他人看不懂才行。
现代加密方式无非两种：
- 对称加密
- 非对称加密
对称还是不对称，这是一个问题。
对称快，非对称慢，而且不适用，为什么不适用，我就要用非对称加密会怎样？
没问题，试试就逝世。
假如我们对明文进行非对称加密，由客户端公钥加密，服务器私钥解密，私钥也只有服务器有，好，客户端对服务器发送信息是没问题的。
但是，当服务器用私钥加密给客户端传递信息的时候，客户端用公钥解密，而公钥是透明的，可以理解为所有人都知道，这时谁都可以用公钥解密，那么服务器对客户端传递信息没有起到加密的作用，毫无疑问这是失败的。
考虑到通信问题和效率问题，我们还是用对称加密来加密双方之间传递的信息吧。
现在，客户端生成了一个用于对称加密的秘钥，准备给服务器，这样客户端和服务器就能用这个秘钥愉快的通信了。
然而事情似乎没有这么简单，客户端如何把对称秘钥以密文的形式传递给服务器？这不是一个悖论吗，我们要解决的就是这个问题诶？
思考一下，卧槽CUP烧了。。
但是，诶？刚才非对称加密客户端对服务器单方面通信是安全的吧？
头好痒，不会要长脑子了吧？(挠挠挠挠
那咱们只用非对称加密传递对称加密的秘钥，通信的内容还是对称加密的方式，这样不就可以了？
好来看看这个流程，服务器下发一个非对称加密的公钥给客户端，客户端拿到后，连夜生成了一个对称加密的秘钥，然后用这个服务器给的非对称加密的公钥加密自己生产的对称加密的秘钥，再发回给服务器。
服务器拿到这个对称加密的秘钥后，就能与客户端暗行苟且之事了。
嘿嘿嘿。。。
但是，这样似乎还有问题：
- 客户端如何证明服务器给的非对称加密的公钥就是这个服务器的？中间如果被劫持或者替换，不就相当于客户端从一开始跟对面聊天的对象，从玉洁冰清白富美突然变成了200多斤的黑胖？这谁顶得住。
- 还有一个问题，假如一台量子计算机或者某个奇迹事件，在0.1秒把对称加密给破解了，并且知道了对称秘钥，然后他就可以篡改消息，你发给白富美的玫瑰花变成了一坨稀粑粑？
证书认证和完整性校验
先来解决非对称加密的公钥，就是客户端访问的服务器生成的，而不是被别人篡改后的。
这个通过技术手段似乎无法解决了，至少服务器本身不能证明它就是它，解决这个问题得靠社会工程学。
怎么办，既然我不能证明我，那我就找别人(某个绝对权威机构)来帮我证明。
服务器苦苦生成的非对称加密公钥没客户端认，它只好把这个公钥放进可以代表自己的证书里，请权威机构签个字，帮忙证明这个证书就是服务器的。
当服务器终于拿到这个被权威机构签名的证书后，啪一下很快啊，直接把它甩给了客户端。
这样就完美证明公钥就是服务器的，但是证书就不可能被篡改吗，如何保证证书完整性？
客户端一脸懵逼地打开证书，发现里面有几个东西：
陈年旧袜、破洞苦茶子、老坛酸菜。。
诶呸呸呸，大致包含下面这几个，当然还有其他字段(证书基本信息等统一用证书内容表示)：
- 证书内容(有效期、版本号、机构信息、等等)
- 数字签名(证书摘要被权威机构非对称加密后的产物)
- 生成摘要的hash算法
- 解密数字签名的公钥
- 当然还有服务器自己的公钥(用于传递对称密钥的那个公钥)
那么是如何保证证书完整性，不被篡改的呢，答案呼之欲出了：
证书摘要是对证书内容的hash，而数字签名是对证书摘要的进行非对称加密的密文，客户端拿到后，再通过证书里的权威机构的公钥进行解密，得到摘要，再自己做一次hash看看和摘要是不是一致的，不一致说明有内鬼、终止交易。
至此，对称加密、非对称加密、摘要算法一共被使用了几次？
- 对称加密：1次，用于服务器和客户端双方的通信加密。
- 非对称加密：至少2次，加密证书的摘要，还有加密对称加密的秘钥。
- 摘要算法：至少2次，用于验证客户端服务器消息完整性校验和证书完整性校验。
至此，撒花。HTTPS中的S是涩Q瑞提(security)安全的意思。
HTTPS = HTTP + 加密通信 + 完整性校验 + 权威认证
这一系列骚操作就是SSL/TLS。
流程
再总结一下HTTPS通信的流程：
- 客户端发起https请求
- 服务端收到请求后，下发一个由权威机构签名认证过的证书给客户端
- 客户端校验证书完整性有效性，没问题自己生成一个对称密钥，用证书里面的公钥对该秘钥加密，发回给服务器。
- 服务器收到加密过的对称密钥用自己的非对称加密的私钥进行解密，得到对称加密的秘钥
- 双方用对称加密的秘钥进行加密通信，并使用消息摘要算法校验消息的完整性。
还不清楚就问问chatGPT吧。
- 客户端向服务器发起 HTTPS 请求。这个请求的 URL 以 “https” 开头，而不是 “http”。
- 服务器返回数字证书。数字证书通常包含服务器的公钥和一些附加信息，如证书颁发机构和证书的有效期等。
- 客户端验证数字证书的有效性，如果证书无效或过期，或者颁发机构不受信任，则连接将被终止。
- 如果数字证书是有效的，客户端将生成一个随机的密钥，用于对数据进行加密和解密。
- 客户端使用服务器的公钥来加密密钥，并将加密后的密钥发送给服务器。
- 服务器使用自己的私钥来解密客户端发送的密钥，并使用该密钥对数据进行加密和解密。
- 之后，服务器和客户端之间的通信将使用对称加密算法进行加密和解密，以保证通信的机密性。
- 在加密过程中，服务器和客户端还会使用消息摘要算法对数据进行完整性校验和认证，以保证通信的完整性。
- 通信结束后，客户端和服务器都可以关闭连接，也可以保持连接，以便进行更多的请求和响应。