中间人攻击问题解析就和下图一样接下来我是用简单的语言进行阐述不想看语言的可以看下面的图。客户端向服务器发送请求的时候去找服务器要服务器的公钥的时候被入侵的设备就可以趁机拿到服务器给的公钥然后给客户端返回黑客的公钥这时候公钥就被黑客给替换了接下来黑客就可以使用自己的私钥对客户端发来的请求进行解密用服务器的公钥进行加密他自己的信息这时候的网络通信就被黑客给入侵了。这样就会导致我们使用非对称加密的方法也被黑客给破解。既然非对称密钥无法解决问题人们就引入了证书来证明当前信息传递的正确性。证书的申请服务器去向第三方认证机构申请证书第三方给服务器颁发证书证书的内容是证书的颁发机构是XXX证书的有效期是XXX服务器的公钥是XXX服务器的拥有者域名是XXX证书的数字签名是XXX证书只是证书它只是传递信息主要传递的是服务器的公钥服务器要告诉客户端使用服务器公钥进行加密因为黑客是拿到服务器的私钥的概率是很小的所以如果客户端使用正确的服务器公钥进行加密就可以很大概率避免信息被黑客给解密窃取。那证书上有服务器的公钥那黑客是不是也可以去修改这个公钥是可以去修改这个公钥。但是修改完公钥就会和证书的数字签名对不上因为我们拿到这个证书的时候我们也会使用第三方的公钥对数字签名进行解密得到一个校验和1然后对证书的其他内容使用和证书的机构的算法进行计算的到 校验和2此时对比两个校验和是否一致不一致就说明中间被修改了。为什么修改证书的内容就和证书的数字签名不一致1. 用到的算法HTTPS 证书数字签名流程1. 对证书原文做哈希算法主流SHA-256算出哈希值校验和2. 证书机构CA用自身私钥加密这个哈希值生成数字签名3. 客户端拿到证书后◦ 用CA公钥解密签名还原出原始哈希值◦ 客户端本地用相同哈希算法重新计算证书内容的哈希值◦ 对比两个哈希值一致则证书合法。2. 黑客为什么改不了内容1. 哈希不可逆强碰撞难度哈希算法SHA256是单向函数只能原文算哈希无法用哈希反推原文现代安全哈希几乎无法人为构造两份不同内容、哈希完全相同碰撞攻击成本极高现实不可行。2. 公钥无法伪造私钥签名CA 公钥只能解密签名不能重新加密/生成签名。黑客没有 CA 私钥篡改证书内容后新内容的哈希值和原签名解密出的哈希必然不一致校验直接失败。3. 篡改内容 → 本地重算哈希改变 → 与解密出的哈希不匹配客户端直接判定证书无效、中断连接。3. 数字签名是否固定随内容动态改变不是固定值• 原文只要一个字节改动哈希值就会彻底变化对应的数字签名也会完全不同• 同一份内容签名固定内容一变签名立刻改变。总结证书就保证了服务器传递服务器公钥的正确性解决了中间人攻击的问题。就是解决了黑客冒充服务器公钥来获取数据这个途径。断开连接四次挥手因为 ACK 是内核控制返回的内核收到 FIN第一时间返回 ACK和我们应用程序代码无关第二个 FIN 是代码中调用 socket.close 才会触发的进程结束也可以触发所以第二个 FIN 和 ACK 的时机可能不是同一个时机。三次握手一定是客户端发起 syn (第一次握手一定是客户端开头的)四次握手客户端和服务器都可以主动发起FIN(就看谁先调用 close)在发送 FIN 的时候谁发起的谁就会进入 TIME_WAIT 时间等待谁是被动发起的就会进入 CLOSE_WAIT 状态
