面试必问https原理--全流程探究

RAMemories

已于 2023-03-24 19:32:20 修改

阅读量191

点赞数 1

文章标签： https 网络协议 http

于 2023-03-24 19:09:10 首次发布

本文链接：https://blog.csdn.net/wayupwayup/article/details/129756689

版权

文章目录

前置知识：
加密理解
流程缺陷：
https解决办法：
补充：CA公钥如何被客户端拿到？
- 信任锚点

前置知识：

首先清楚

https=http+TLS/SSL（应用层协议，只会在两端出现，数据在网络中总是被加密的）

加密方式：

对称加密（一把密钥）和非对称加密（一公钥，一私钥）
非对称加密：可以用公钥加密，但只能用私钥解密，反之亦然（RSA就是经典的非对称加密）
一般而言，公钥对外公开，私钥必须私有保存

加密理解

此节仅仅探讨–如何防止文本中的内容被篡改，以及识别到是否被篡改？

现在有文本T，对T使用hash散列算法(md5算法或者别的)来形成固定长度的唯一字符序列，如果文本的内容有一点变化，都会形成差异巨大的hash结果 — *固定长度的唯一字符序列就被称为数据摘要或数据指纹·
紧接着，通过加密算法（一般是非对称的）对刚才形成的数据摘要再次加密，得到的字符串序列被称为数字签名：发送端发送时会发送文本t以及t生成的数字签名：接收端收到数据以后，需要确认数据是否被篡改，接收方需要进行校验！

校验方式：从原始数据中将文本内容和数据签名分出来，然后对原始文本T采用和发送端相同的hash散列算法形成数据摘要，然后根据解密算法将数字签名解为数据摘要，对比两份数据摘要，校验完成

流程缺陷：

接收端如何知道发送端采用的是什么hash散列算法？
接收端如何知道对应解密算法？

针对缺陷，我们需要首先确定https对数据的加密机制，首先就是如何选择加密算法类型

选择对称加密，C端发送数据用密钥X加密，S端用X解密，那么S端如何得知密钥X？

预装在机器上或下载密钥：成本太高且不安全，后者直接是悖论
协商，通信期间协商密钥（但第一条消息密钥是明文发送，直接是不安全的）
因此协商密钥采用对称加密是根本不可能的

选择非对称加密协商秘钥
起初，服务端S拥有公钥G,私钥G_

C端发起请求，服务端将公钥G给予C端，C端使用G对数据K加密，然后将数据K发送给S端，只有S端具有私钥G_，仅仅只有S端可以进行解密(即使被他人拿到也没有任何作用)，S端收到数据后使用私钥G_解密，拿到数据K
使用此方案，我们总能保证从C端到S端的单向的安全! 而S想要给C安全地发送数据，是没有任何办法的，倘若用私钥G_加密发送，那就是纯纯的掩耳盗铃。

至此，发现只有一对公钥和私钥是不够的，需要CS两端各自都有一对密钥，在通信阶段两端交换各自的公钥，就一定能保证一来回双向的数据安全吗？
还不够！

缺陷一：非对称加密算法十分耗时（对文本量大的内容的加密解密算法等计算非常费时，仅是这一点，这种方案就不可能被采纳）
缺陷二：依旧存在被非法窃取的风险（交换公钥，你怎么知道这个公钥不是第三者的篡改的？）

https解决办法：

解决缺陷一：
实际上https采用非对称+对称方案，相比于非对称，对称加密比较节省时间
通信开始阶段使用非对称加密（仅需要S端有一对非对称密钥即可）保证对称密钥的安全交换，数据传输阶段使用刚才非对称加密协商得到的密钥进行数据传输

解决缺陷二：
解决其它问题后，最后需要解决的问题就是，客户端C如何验证S端发来的公钥确实是S端想要发给我们的（没有被中间人篡改的）
这个公钥可以被任何一个人拿到，如果中间人将密钥替换为自己的公钥然后发送给客户端，客户端用此公钥加密后发回服务端，中间人再将发回的数据使用自己的私钥解密，拿到客户端和服务端通信的对称密钥，再把它用服务端密钥加密返回给服务端，神不知鬼不觉完成了狸猫换太子
如何解决？
网络当中因此出现了CA证书机构（权威且拥有CA自己的一对公钥和私钥算法，下文我将其称之为CA_G,CA_P）
只要一个服务商经过权威机构认证，该机构就是合法的，企业拿着自己的一系列信息去向CA机构申请证书，我所谓一系列信息中尤为重要的是：企业基本信息、企业服务域名、企业服务的公钥；这些信息本质都是文本信息

CA机构在确定了机构的合法和正规性以后开始制作证书：

首先将企业上述文本信息进行hash散列（使用一些算法）形成数据摘要，然后采用私钥算法CA_P对此摘要进行加密，形成此企业的数字签名

没错，CA使用私钥加密，就是和你打明牌，中间人即使能够使用CA公钥来对此解密然后修改，也无法再次形成数字签名，因为只有CA能够形成数字签名！你修改以后使用别的私钥加密的签名，客户端是不识别的，客户端只使用CA公钥解密！同时如果中间人修改证书其它文本内容，客户端也很轻松可以校验出篡改；

将企业信息文本内容和hash散列算法以及刚才形成的企业数字签名合并之后就形成了CA证书，然后将此证书颁发给企业

迫不及待，有了CA证书以后，请求流程如下：

客户端发起常规请求，服务端将证书信息返回给客户端（中间人能过截取此证书，但倘若修改就会被客户端采用数字签名校验出！）
客户端通过信任锚点验证服务器证书的真实性（方法就是经典的校验，用CA公钥对数字签名解密，然后使用证书中的哈希散列算法对文本内容形成摘要，对比两份摘要）

补充：CA公钥如何被客户端拿到？

客户端通过操作系统或浏览器内置的信任锚点（Trust Anchor）来获取CA机构的公钥。信任锚点是一组已知的、受信任的根证书，它们被内置在操作系统或浏览器中，用于验证其他证书的真实性。当客户端与服务器建立HTTPS连接时，服务器会将自己的数字证书发送给客户端。客户端会使用内置的信任锚点来验证服务器证书的真实性，在信任锚点中就能得到CA机构的公钥。

信任锚点

浏览器中内置的信任锚点（Trust Anchor）是一组根证书，用于验证SSL/TLS加密通信中的数字证书。当浏览器访问一个使用SSL/TLS加密的网站时，它会检查该网站的数字证书是否由信任锚点中的任何一个证书颁发机构（CA）签发。如果数字证书由信任锚点中的某个CA签发，浏览器会确认该网站的身份，并建立安全连接。信任锚点的作用是确保数字证书的真实性和有效性，从而保护用户的隐私和安全。