https的原型

 大家每天都在用https, 今天，我们来聊聊它的原理。

 我们知道，http基于TCP协议，明文传输，不安全。https是加密传输，安全。





  直接用RSA加密，是不行的。一是因为RSA慢；二是因为RSA的公钥是公开的，坏人可能对私钥加密后的信息进行解密。

 可以考虑使用AES对称加密，速度更快，且适合对内容进行加密：



    

  但问题是：C和S两端怎样才能拥有相同的秘钥randomStr呢？可以考虑由C端生成randomStr，然后发送给S端：

看似解决了问题，但如果发送randomStr时被坏人截获，坏人就能解密C和S的通信内容。因此，上述方法还需要继续改进，比如C端用公钥pubKey对randomStr进行加密，这样只有S端的私钥priKey才能解密，中间人无可奈何：

  如何才能使C端有公钥pubKey, 而S端有私钥priKey呢？可以考虑在S端生成，然后传递给C端，逻辑如下：





 这种方案可行，S端给C端返回公钥pubKey时，不怕泄露公钥。然而，坏人还是可以从中作恶的。坏人可以自己生成新的公私钥，欺骗C和S.  于是乎，C还以为是在跟S通信， S还以为是在跟C通信，其实，他们的通信内容，已经被坏人劫持了，逻辑如下：





  这里的问题在于：C要确认接收到的公钥确实是S的公钥，而不是其他人的公钥，这是个难题。

  网上的买家要卖家先发货，卖家要买家先给钱，谁都不信任彼此，无法交易。解决信任问题还是要依赖于第三方，比如淘宝。

  同理，在https场景中，S端必须要想办法证明自己就是自己，可以找第三方CA机构来做认证，这样C才能确保自己拿到的公钥确实是S的公钥，逻辑图如下：





 如此一来，C端就可以验证获取的pubKey确实来源于S端，而不是中间的坏人H. S端每年要向CA认证机构支付认证费用，过期后要续费，否则，服务S无法正常工作，浏览器C也访问不了网站。



  http不安全，需要使用https, 任何不使用https的网站都是流氓网站。https的本质是加密传输，它需要解决一系列的秘钥管理问题。

  https很简单，关键在于理解其背后的思路，这些思路可以指导我们设计更加安全的系统。另外，https也是笔试和面试的常考点。