对公钥加密就行了。 

　　每一个使用 HTTPS 的服务器都必须去专门的证书机构注册一个证书，证书中存储了用权威机构私钥加密的公钥。这样客户端用权威机构的公钥解密就可以了。 

　　现在 HTTPS 协议的握手阶段变成了四步： 

　　1、客户端：你好，我要发起一个 HTTPS 请求，请给我公钥。 

　　2、服务器：好的，这是我的证书，里面有加密后的公钥。 

　　3、客户端：解密成功以后告诉服务器: 这是我的 (用公钥加密后的) 对称秘钥。 

　　4、服务器：好的，我知道你的秘钥了，后续就用它传输。 

　　存在电脑里。 

　　这个公钥不用传输，会直接内置在各大操作系统(或者浏览器)的出厂设置里。之所以不把每个服务器的公钥内置在电脑里，一方面是因为服务器太多，存不过来。另一方面操作系统也不信任你，凭什么你说你这个就是百度/淘宝的证书呢？ 

　　所以各个公司要先去权威机构认证，申请证书，然后操作系统只会存储权威机构的公钥。因为权威机构数量有限，所以操作系统厂商相对来说容易管理。如果这个权威机构不够权威，XJB 发证书，就会取消他的资格，比如可怜的沃通 

　　将信息 hash 值随着信息一起传递。 

　　我们都知道哈希算法的特点，它可以压缩数据，如果从函数角度来看，不管多复杂的数据(定义域可以非常大)经过哈希算法都会得到一个值，而且这个值处在某个特定(远小于定义域的范围)值域内。相同数据的哈希结果一定相同，不相同数据的哈希结果一般不同，不过也有小概率会重复，这叫哈希冲突。 

　　为了确保原始证书没有被篡改，我们可以在传递证书的同时传递证书的哈希值。由于第三者无法解析数据，只能 XJB 改，那么修改后的数据在解密后，就不可能通过哈希。 

　　比如说公钥就是之前的例子 Hello，我们假设哈希算法是获取字符串的最后一个字符，那么 Hello 的哈希值就是 o，所以加密字符串是 Ifmmpp。虽然公钥已知，每个人都可以解密，解密完也可以篡改，但是因为没有私钥， 所以无法正确的加密。所以它再返回给客户端的数据是无效数据，用公钥解析后会得到乱码。即使攻击者通过多次尝试碰巧能够解析，也无法通过哈希校验。 

　　影响肯定有，但是可以接受。 

　　首先，HTTPS 肯定会更慢一点，时间主要花费在两组 SSL 之间的耗时和证书的读取验证上，对称算法的加解密时间几乎可以忽略不计。 

　　而且如果不是首次握手，后续的请求并不需要完整的握手过程。客户端可以把上次的加密情况直接发送给服务器从而快速恢复，具体细节可以参考 图解SSL/TLS协议。 

　　除此以外，SSL 握手的时间并不是只能用来传递加密信息，还可以承担起客户端和服务器沟通 HTTP2 兼容情况的任务。因此从 HTTPS 切换到 HTTP2.0 不会有任何性能上的开销，反倒是得益于 HTTP2.0 的多路复用等技术，后续可以节约大量时间。