前言
HTTPS可以理解成HTTP + security，HTTPS解决了远程通信的安全问题。
HTTP缺陷
- 使用明文通信，意味着信息有可能被窃取
- 不验证通信方身份，意味着有有可能遭到伪装
- 无法验证报文的完整性，可能会遭到纂改（中间人攻击MITM）
原理
想象一下，上课的时候，你需要传个消息告诉你心爱的TA。但是又不想让中间传纸条的同学知道你们之间的秘密。怎么办？
对称加密和非对称加密
如果你们俩之间有过约定（对称加密），显然事情就好办得多，比如你要传AAA给TA，第一个A代表meet，第二个A代表you，第三个A代表playground，那么你直接在纸条上写AAA即可。中间帮忙传纸条的同学就算看了纸条也不知道AAA代表神马意思。要是你们之间没有过约定，又不想让中间传纸条的同学知道，这怎么办呢？聪明的你，找到了学算法的大牛，他设计出了一种算法，可以生成一个密钥对(k1, k2)，k1加密的明文，只有k2才能解开，而k2加密的明文，只有k1才能解开。
- TA先把k2传给你
- 你再使用k2进行加密传给TA
- TA再用k1进行解密
就可以知道你要传给TA信息了！完美！这就是非对称加密。
问题
上述的方法看似天衣无缝，无懈可击。然而事实并没有那么简单。因为你不知道有多少个同学参与了传纸条的过程，你也无法验证最终给到你手里的信息，是你心仪的Ta传给你的！因此，如果C想知道你们的小秘密，C可以这样做：
- 拦截TA传给你的k2，然后伪造一个k2’传给你
- 你傻傻地以为k2’就是TA给你的k2，然后使用k2’加密了信息，传给了C
- 这会Ｃ已经乐开了花，因为Ｃ已经用k1’把信息解密出来了
改进
怎么办呢？怎么办呢？上述方案的缺陷就是无法验证k2是TA发给你的。那我们能不能这样：
- TA把k2发给你和TA的铁哥们B，B能够保证k2一定是TA发的，而不是C发的。
- B再生成密钥对(k3,k4)，用k3对k2进行加密，假设密文为!@#$%^（该密文便是证书）。
当你请求与TA进行加密通信时，TA会把密文（证书）下发给你，你用k4解密密文（证书）!@#$%^，里面的k2，正是你心仪的TA想要发给你的k2！！！到这里你已经激动得泪流满面了，因为你拿到手里的就是Ta你发的k2（如果你信任B的话）。
