详析中间人问题

详析中间人问题

正常情况

中间人

如何解决呢？
加证书
证书也有公钥和私钥

具体步骤如下：
1.服务器生成非对称密钥对
私钥和公钥的生成：服务器使用非对称加密算法（如RSA、ECDSA）生成一对密钥，包括一个私钥和一个公钥。私钥在服务器上保密存储，用于解密信息和签名；公钥可以安全地公开。
2. 获取数字证书
创建证书签名请求（CSR）：服务器创建一个CSR，其中包含服务器的公钥、服务器的域名、组织信息等。CSR通常使用服务器的私钥进行签名，以证明服务器拥有这个私钥。
提交CSR到证书颁发机构（CA）：服务器将CSR发送给CA。CA验证服务器的身份信息，如通过域名验证、组织验证等。
CA签发证书：验证成功后，CA使用其私钥对服务器的公钥和其他信息进行签名，生成数字证书。这个证书包括服务器的公钥、服务器的信息、CA的信息和CA的数字签名。
3. 客户端与服务器的通信
开始通信并获取证书：客户端（如Web浏览器）发起HTTPS请求，服务器在TLS握手过程中将其数字证书发送给客户端。
4. 客户端验证证书
验证证书的签名：客户端使用已知的CA公钥（客户端内置了信任的CA列表，即根证书存储）来验证证书上的签名。
检查证书的有效性：包括证书的域名是否匹配请求的域名、证书是否过期、证书是否被撤销（通过OCSP或CRL）。
建立信任：如果证书验证成功，客户端信任该证书和其中的公钥。
5. 加密密钥交换
生成对称密钥：客户端生成一个临时的对称密钥（会话密钥）用于本次通信的加密。
使用公钥加密对称密钥：客户端使用服务器的公钥（从证书中获取）加密这个对称密钥，并将加密后的对称密钥发送给服务器。
6. 服务器解密对称密钥
使用私钥解密：服务器收到加密的对称密钥后，使用其私钥对其进行解密，获取对称密钥。
7. 加密通信
使用对称密钥加密数据：服务器和客户端现在共享一个对称密钥，用这个密钥加密双方之间的通信数据，确保数据传输的安全性。

中间人能不能获取证书里的服务器公钥呢？为什么
能！并且它可以替换证书里的服务器公钥，但是没用！
为啥呢，因为证书里面有个叫签名的玩意，这个签名是个哈希值，这个哈希值根据证书里面所有的内容生成的，一旦中间人把服务器的公钥换成自己仿造的公钥，这个签名就得跟着变，因为服务器的公钥也在签名里，然后这个签名是用来验证证书的真实性的，客户端有一个表，存着所有可信任的证书机构，这个签名一旦改变了，就跟客户端相应的证书机构对不上了，所以客户端就认为它不安全了。

因此中间人就算拿到了服务器的公钥，也不能篡改，然后客户端拿着服务器的公钥传输对称密钥的时候，中间人也解密不了，因为私钥在服务器那里

证书的私钥用来给这个签名进行加密的，公钥用来给这个签名进行解密，然后在客户端验证身份的用公钥来验证

也就是说，不管中间人用证书做什么幺蛾子，只要最后在客户端那里的验证通不过，就无法拿到数据

中间人就算真的修改了数据，也无法生成签名，因为签名是根据私钥来加密的，中间人拿不到私钥，因此如果真的生成了签名，客户端也无法拿到证书的公钥来验证这个假签名