一、什么是https

答曰：https是安全的HTTP。HTTP协议中的内容都是明文传输，HTTPS的目的是将这些内容加密，确保信息传输安全。最后一个字母“S”指的是SSL/TLS协议，它位于HTTP协议与TCP/IP协议中间。

二、信息传输安全是什么意思

答曰：信息传输的安全有以下三个方面：

1、只有自己能看懂，即使第三方拿到数据也看不懂这些信息的真实含义。

2、第三方虽然看不懂数据，但可以 XJB 改，因此客户端和服务器必须有能力判断数据是否被修改过。

3、客户端必须避免中间人攻击，即除了真正的服务器，任何第三方都无法冒充服务器。

很遗憾：目前的HTTP协议一点都做不到。

三、怎么加密信息

答曰：使用对称加密技术。对称加密可以理解为对原始数据的可逆变换。比如 Hello 可以变换成 Ifmmp，规则就是每个字母变成它在字母表上的后一个字母，这里的秘钥就是 1，另一方拿到 Ifmmp 就可以还原成原来的信息 Hello 了。

有对称加密，自然就有非对称加密。它的思想很简单，计算两个质数的乘积很容易，但反过来分解成两个质数的乘积就很难，要经过极为复杂的运算。非对称加密有两个秘钥，一个是公钥，一个是私钥。公钥加密的内容只有私钥可以解密，私钥加密的内容只有公钥可以解密。一般我们把服务器自己留着，不对外公布的密钥称为私钥，所有人都可以获取的称为公钥。

四、对称密钥怎么传输

服务器直接返回明文的对称加密密钥是不是不安全。如果有监听者拿到这个密钥，不就知道客户端和服务器后续的通信内容了么？

答曰：正因为这样，所以不能明文传递对称秘钥，而且也不能用一个新的对称加密算法来加密原来的对称秘钥，否则新的对称秘钥同样无法传输，这就是鸡生蛋、蛋生鸡的悖论。

于是引入了非对称加密的方式，非对称加密的特性决定了服务器用私钥加密的内容并不是真正的加密，因为公钥所有人都有，所以服务器的密文能被所有人解析。但私钥只掌握在服务器手上，这就带来了两个巨大的优势:

1、服务器下发的内容不可能被伪造，因为别人都没有私钥，所以无法加密。强行加密的后果是客户端用公钥无法解开。

2、任何人用公钥加密的内容都是绝对安全的，因为私钥只有服务器有，也就是只有真正的服务器可以看到被加密的原文。

所以传输对称秘钥的问题就迎刃而解了: 秘钥不是由服务器下发，而是由客户端生成并且主动告诉服务器。

五、公钥怎么传输

客户端发送请求时要用公钥加密对称秘钥，那公钥怎么传输呢？

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

那么问题又来了，权威机构的公钥又怎么传输呢？

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

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

六、怎么知道证书有没有被篡改？

服务器第一次会返回证书，也就是加密以后的公钥，怎么知道这个证书是可靠的？

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

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

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

七、HTTPS 握手会影响性能吗

TCP已有三次握手，再加上 HTTPS 的四次握手，会不会影响性能？

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

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

而且如果不是首次握手，后续的请求并不需要完整的握手过程。客户端可以把上次的加密情况直接发送给服务器从而快速恢复。

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

如果把 HTTPS2.0 当做目标，那么 HTTPS 的性能损耗就更小了，远远比不上它带来的安全性提升。