服务器: 好的，我知道你的秘钥了，后续就用它传输。
Q5: 那公钥怎么传输
你好像还是没有解决鸡生蛋，蛋生鸡的问题。你说客户端发送请求时要用公钥加密对称秘钥，那公钥怎么传输呢？
BS: 对公钥加密就行了。。。
每一个使用 HTTPS 的服务器都必须去专门的证书机构注册一个证书，证书中存储了用权威机构私钥加密的公钥。这样客户端用权威机构的公钥解密就可以了。
现在 HTTPS 协议的握手阶段变成了四步:
1、客户端: 你好，我要发起一个 HTTPS 请求，请给我公钥
2、服务器: 好的，这是我的证书，里面有加密后的公钥
3、客户端: 解密成功以后告诉服务器: 这是我的 (用公钥加密后的) 对称秘钥。
4、服务器: 好的，我知道你的秘钥了，后续就用它传输。
Q6: 你在逗我么。。。。
那权威机构的公钥又怎么传输？
BS: 存在电脑里
这个公钥不用传输，会直接内置在各大操作系统(或者浏览器)的出厂设置里。之所以不把每个服务器的公钥内置在电脑里，一方面是因为服务器太多，存不过来。另一方面操作系统也不信任你，凭什么你说你这个就是百度/淘宝的证书呢？
所以各个公司要先去权威机构认证，申请证书，然后操作系统只会存储权威机构的公钥。因为权威机构数量有限，所以操作系统厂商相对来说容易管理。如果这个权威机构不够权威，XJB 发证书，就会取消他的资格，比如可怜的沃通。。。。
Q7: 怎么知道证书有没有被篡改？
你说服务器第一次会返回证书，也就是加密以后的公钥，那我怎么知道这个证书是可靠的？
BS: 将信息 hash 值随着信息一起传递
我们都知道哈希算法的特点，它可以压缩数据，如果从函数角度来看，不管多复杂的数据(定义域可以非常大)经过哈希算法都会得到一个值，而且这个值处在某个特定(远小于定义域的范围)值域内。相同数据的哈希结果一定相同，不相同数据的哈希结果一般不同，不过也有小概率会重复，这叫哈希冲突。
为了确保原始证书没有被篡改，我们可以在传递证书的同时传递证书的哈希值。由于第三者无法解析数据，只能 XJB 改，那么修改后的数据在解密后，就不可能通过哈希。
比如说公钥就是之前的例子 Hello，我们假设哈希算法是获取字符串的最后一个字符，那么 Hello 的哈希值就是 o，所以加密字符串是 Ifmmpp。虽然公钥已知，每个人都可以解密，解密完也可以篡改，但是因为没有私钥， 所以无法正确的加密。所以它再返回给客户端的数据是无效数据，用公钥解析后会得到乱码。即使攻击者通过多次尝试碰巧能够解析，也无法通过哈希校验。
Q8: 这样可以防止第三方冒充服务器么
BS: 也许可以
首先真正的服务器下发的内容，无法被别人篡改。他们有权威机构的公钥，所以可以解密，但是因为没有私钥，所以解密以后的信息无法加密。没有加密或者错误加密的信息被客户端用公钥解密以后，必然无法通过哈希校验。
但是，如果你一开始请求的就不是真的服务器，而是一个攻击者，此时的他完全有机会进行中间人攻击。我们知道第一次握手的时候服务器会下发用于证明自己身份的证书，这个证书会用预设在设备上的公钥来解密。所以要么是经过认证的证书用权威机构的私钥加密，再用权威机构解密，要么是用非权威机构的私钥加密，然后找不到公钥解密。
所以如果不小心安装过非权威机构的根证书，比如黑客提供的恶意证书，这时候设备上就多了一个预设的公钥，那么用恶意私钥加密的证书就能被正常解析出来。所以千万不要随便装根证书，这等于是为那些恶意证书留了一扇门。
当然，凡是都有两面性。我们知道 Charles 可以调试 HTTPS 通信，它的原理就是需要用户安装 Charles 的根证书，然后我们的请求会被代理到 Charles 服务器，它下发的 Charles 证书才能被正确解析。另一方面，Charles 会作为客户端，从真正的服务器哪里拿到正确的 https 证书并用于后续通信。幸好 Charles 不是流氓软件，或者它的私钥一旦泄露，对用户都会造成很大的影响。
-
无相关信息