https秘钥交互

最新推荐文章于 2025-06-20 22:40:59 发布

转载最新推荐文章于 2025-06-20 22:40:59 发布 · 808 阅读

2 ·

CC 4.0 BY-SA版权

原文链接：https://juejin.im/post/5b84150cf265da43445f6af6

文章标签：

#数据结构与算法 #网络

https和http的区别

http是超文本传输协议，信息是明文传输，https则是具有安全性的SSL加密传输协议
http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443
http的连接很简单，是无状态的；HTTPS协议是由SSL（现在是TLS）+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

进行TLS握手前的TCP 三次握手必不可少，这里描述的场景假设已经完成了 TCP 三次握手：
1.“往”、由客户端在一个类型为 Client Hello 的 TLS 握手包中携带客户端运行的TLS 协议版本，支持的密钥交换算法集合（加密套件列表）发送至服务器端
2.“返”、服务器在一个类型 Server Hello 的 TLS 握手包中携带选取的特定密钥交换算法，在类型为 Certificate 的 TLS 握手包中携带自己的数字证书公钥（或层级信任关系的证书链），以及一个类型为 Server Hello Done 的 TLS 握手包发送给客户端，客户端遍历本地文件系统中的所有已导入的 CA（证书颁发机构）证书，尝试验证服务器的证书确实由其声称的那个 CA 机构所签发，如果验证失败，则提示用户该服务器证书不可信，并询问是否“手动”设置信任关系，或者拒绝，如果验证成功，不向用户显示任何信息。
3.“往”、客户端用先前与服务器协商的密钥交换算法（通常为对称加密算法，如果为 RSA 则为非对称加密算法）生成一个随机密钥，它将用于两者会话的“钥匙”，然后客户端再用服务器的证书公钥来加密这个会话钥匙，并通过 Change Cipher Spec Protocol（变更密码通知协议），在一个类型为 Client Key Exchange 的 TLS 握手包中携带，发送至服务器端。
4.“返”、服务器收到后，用自己的证书私钥，解开这个会话钥匙（公钥加密私钥解密），如果解密失败，说明客户端的身份不可信（可能是一个中间人截获与原来的客户端通信后，伪造的，但是由于该中间人无法伪造最先两者使用的协商协议，因此服务器端也就不能用私钥解开伪造的会话密钥）如果服务器端解密成功，则说明客户端是合法的，服务器在类型为 Change Cipher Spec Protocol 的 TLS 记录层中包含 Finished 握手包，返回给客户端，表明客户端的身份通过验证；

客户端收到通知后（解密 Finished 握手包后），开始用协商好的会话钥匙（客户端在第二次“往”中发送的随机密钥，此刻不需要再用服务器公钥加密，前面加密的目的在于验证客户端的身份）来加密并发送 HTTP 请求；服务器用相同的会话钥匙解密并读取 HTTP 请求，加密并返回 HTTP 响应，浏览器用会话钥匙解密并读取 HTTP 响应。。。如此反复，构成完整的 HTTPS 通信流量。

身份认证（CA数字证书）

证书由公钥、证书主体、数字签名等内容组成，在客户端发起SSL请求后，服务端会将数字证书发给客户端，客户端会对证书进行验证，并获取用于秘钥交换的非对称密钥。
数字证书验证：
申请者拿到CA的证书并部署在网站服务器端，那浏览器发起握手接收到证书后，如何确认这个证书就是CA签发的呢？怎样避免第三方伪造这个证书？答案就是数字签名（digital signature）。数字签名是证书的防伪标签，目前使用最广泛的SHA-RSA（SHA用于哈希算法，RSA用于非对称加密算法）数字签名的制作和验证过程如下：

数字签名的签发。首先是使用哈希函数对待签名内容进行安全哈希，生成消息摘要，然后使用CA自己的私钥对消息摘要进行加密。
数字签名的校验。使用CA的公钥解密签名，然后使用相同的签名函数对待签名证书内容进行签名并和服务端数字签名里的签名内容进行比较，如果相同就认为校验成功。
复制代码

https协议就是http+ssl协议，如下图所示为其连接过程：

中间人劫持攻击

预防中间人攻击：
这种攻击，我们可以加上身份认证：这个时候就要引入CA证书。数字证书中包括的主要内容有：证书拥有者的个人信息、证书拥有者的公钥、公钥的有效期、颁发数字证书的CA、CA的数字签名等。所以网上双方经过相互验证数字证书后，不用再担心对方身份的真伪，可以放心地与对方进行交流或授予相应的资源访问权限。
服务器端把公钥交个CA证书，CA证书再包装一层。然后再发给客户端，这个包装一层的意思是：保证这个证书是我（服务器）给你（客户端的），其他人拿到了也没有用

最后，你可能会想既然非对称加密可以那么安全，为什么我们不直接用它来加密信息，而是用来加密对称加密的密钥呢？

这是因为非对称加密的密码对生成和加密的消耗时间比较长，为了节省双方的计算时间，通常只用它来交换密钥，而非直接用来传输数据（具体的可看上文非对称加密的缺点）。

AFNetworking证书验证：

转载于:https://juejin.im/post/5b84150cf265da43445f6af6