一、对称加密算法：
加密和解密用的是同一个**
但是面临的问题是：**传递问题—**双方必须得知道啊， 但是**又无法通过网络发送
二、RSA : 非对称加密
有一对儿钥匙， 一个是保密的，称为私钥，另外一个是公开的，称为公钥。
更有意思的是，用私钥加密的数据，只有对应的公钥才能解密；用公钥加密的数据， 只有对应的私钥才能解密。
有了这两个漂亮的特性， 当张大胖给Bill发消息的时候， 就可以先用Bill的公钥去加密（反正Bill的公钥是公开的，地球人都知道）， 等到消息被Bill 收到后， 他就可以用自己的私钥去解密（只有Bill才能解开，私钥是保密的 ）
但是面临的问题是：RSA的加密和解密慢，比之前的对称**算法要慢上百倍
三、非对称加密+对称加密
Step1：我生成一个对称加密算法的**， 用RSA的方式安全发给你
Step2：我们随后就不用RSA了， 只用这个**，利用对称加密算法来通信
此方法：既解决了**的传递问题， 又解决了RSA速度慢的问题。
但面临的问题是：公钥的分发
四、CA的引入
但是怎么安全地分发公钥呢？一定得有个办法声明这个公钥确实是Bill的， 而不是别人的。
怎么声明呢？
张大胖突然想到： 现实中有公证处，它提供的公证材料大家都信任，那在网络世界也可以建立一个这样的具备公信力的认证中心， 这个中心给大家颁发一个证书， 用于证明一个人的身份。
这个证书里除了包含一个人的基本信息之外，还有包括最关键的一环：这个人的公钥！
这样以来我拿到证书就可以安全地取到公钥了 ！ 完美！
可是Bill 马上泼了一盆冷水：证书怎么安全传输？ 要是证书传递的过程中被篡改了怎么办？
张大胖心里不由地咒骂起来： 我操， 这简直就是鸡生蛋，蛋生鸡的问题啊。
天无绝人之路， 张大胖很快就找到了突破口： 数字签名。
简单来讲是这样的， Bill可以把他的公钥和个人信息用一个Hash算法生成一个消息摘要， 这个Hash算法有个极好的特性，只要输入数据有一点点变化，那生成的消息摘要就会有巨变，这样就可以防止别人修改原始内容。
可是作为攻击者的中间人笑了： “虽然我没办法改公钥，但是我可以把整个原始信息都替换了， 生成一个新的消息摘要， 你不还是辨别不出来？”
张大胖说你别得意的太早 ， 我们会让有公信力的认证中心（简称CA）用它的私钥对消息摘要加密，形成数字签名：
这还不算， 还把原始信息和数据签名合并， 形成一个全新的东西，叫做“数字证书”。
张大胖接着说：当Bill把他的证书发给我的时候， 我就用同样的Hash 算法， 再次生成消息摘要，然后用CA的公钥对数字签名解密， 得到CA创建的消息摘要， 两者一比，就知道有没有人篡改了！
如果没人篡改， 我就可以安全的拿到Bill的公钥喽，有了公钥， 后序的加密工作就可以开始了。
虽然很费劲， 但是为了防范你们这些偷窥者，实在是没办法啊。
中间人恶狠狠地说： “算你小子狠！ 等着吧，我还有别的招。 对了，我且问你， 你这个CA的公钥怎么拿到？ 难道不怕我在你传输ＣＡ公钥的时候发起中间人攻击吗？ 如果我成功的伪装成了ＣＡ，你这一套体系彻底玩完。”
张大胖语塞了，折腾了半天，又回到了公钥安全传输的问题！
不过转念一想，想解决鸡生蛋，蛋生鸡的问题必须得打破这个怪圈才行，我必须得信任ＣＡ，并且通过安全的的方式获取他们的公钥，这样才能把游戏玩下去。
（公众号码农翻身注：这些ＣＡ本身也有证书来证明自己的身份，并且ＣＡ的信用是像树一样分级的，高层的ＣＡ给底层的ＣＡ做信用背书，而操作系统／浏览器中会内置一些顶层的ＣＡ的证书，相当于你自动信任了他们。 这些顶层的ＣＡ证书一定得安全地放入操作系统／浏览器当中，否则世界大乱。）
五、https
前面已经介绍了https的原理， 你把张大胖替换成浏览器， 把Bill 替换成某个网站就行了。
一个简化的（例如下图没有包含Pre-Master Secret）https流程图是这样的， 如果你理解了前面的原理，这张图就变得非常简单：
参考文章：一个故事讲完https