来呀，跟你聊透https这玩意儿 ~

大家好， 最近自己玩一个项目，要考虑安全方面的问题，需要设计一套比较安全的私有通信协议，打算借鉴https的思路，于是就好好研究了一下https.

今天，我们来聊一聊https的来龙去脉。https其实就是http + ssl，接下来，我们从最简单的明文通信模型开始，逐渐来理解https的设计思路。

一. AES对称加密

我们知道，tcp提供的是端到端的透明传输，而http是基于tcp的。直接用http明文传输是不安全的，所以需要进行加密处理。

你肯定听说过著名的RSA非对称加密，那直接用RSA加密，行不行呢？当然不好！一是因为RSA慢；二是因为RSA的公钥是公开的，坏人可能对私钥加密后的信息进行解密。

此时，可以考虑使用AES对称加密，加解密的速度更快，是最常用的加密算法之一，来看看加解密的图示：

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

二. RSA非对称加密

看似解决了问题，但如果发送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也访问不了网站。大家在实际开发中，可能会遇到https证书过期的问题，导致没法提供服务，需要提前重视。

https不难，关键在于理解其背后的思路，这些思路可以指导我们设计更加安全的系统。

https也是面试的常客，千万别在这些基础问题上歇菜。今天先聊这么多，咱们明天见。