一文领悟HTTPS密钥为什么这样传输

1. 客户端启动，发送请求到服务端，服务端用RSA算法生成一对公钥和私钥，我们简称为pubkey1,prikey1，将公钥pubkey1返回给客户端。

2. 客户端拿到服务端返回的公钥pubkey1后，自己用RSA算法生成一对公钥和私钥，我们简称为pubkey2,prikey2，并将公钥pubkey2通过公钥pubkey1加密，加密之后传输给服务端。

3. 此时服务端收到客户端传输的密文，用私钥prikey1进行解密，因为数据是用公钥pubkey1加密的，通过解密就可以得到客户端生成的公钥pubkey2

4. 然后自己在生成对称加密，也就是我们的AES,其实也就是相对于我们配置中的那个16的长度的加密key,生成了这个key之后我们就用公钥pubkey2进行加密，返回给客户端，因为只有客户端有pubkey2对应的私钥prikey2，只有客户端才能解密，客户端得到数据之后，用prikey2进行解密操作，得到AES的加密key,最后就用加密key进行数据传输的加密，至此整个流程结束------------------------转自某公众号

早上从某个公众号看到这个,之前学过HTTPs好几次,还是对密钥传输过程云里雾里,早上突然明白了.

首先去思考想要的效果,一般数据请求我们肯定是想从服务端----->客户端

所以为了安全,防止抓包,服务端就需要对数据进行加密,然后发给客户端...

那现在我们服务端可以选择RSA(不对称加密)或者AES(对称加密)

RSA是不对称的,有公钥和私钥,这里我们的要求是服务器发信息,所以服务器肯定只能用公钥了,那私钥怎么给客户端呢??

所以有了两次来回的传输.

先服务器自己把公钥1 给客户端,公钥1 谁拿了都没关系,私钥1 在自己手里用来解密

那客户端这时候就可以发公钥2 给服务器了,正好是我们想要的效果.

客户端用之前发的公钥1 加密 公钥2,然后传给服务器,服务端再用私钥1 解密,这样就获得相对于客户端的公钥了,这样发信息谁拿了都没关系,但是只有我们想发的客户端才有解密的能力.

 

那我选AES可以不可以呢,假设我们第一次发还是RSA(第一次肯定是要用不对称加密),第二次拿到客户端的AES时候,用AES加密发给客户端,客户端用同样的密钥解密,其实也可以.

因为安全发送的核心问题在于,双方发有效数据前先达成一个密钥协议,也就是你和我都有一个密钥(当然要安全的密钥),但是我们还没见到面怎么达成,所以有了第一次发不对称密钥的情况.

 

那如果第一次发就被抓包呢,然后抓包的人中途伪造一个密钥发给客户端,然后做中间人那问题就大了.

目前这个问题 解决办法就是发证书....先认证你这个服务端整个传输没毛病,才能安全发第一次信息.

 

所以要破解https必须抓两次包,而这个是很难的.