当我们在谈论 HTTPS 的时候，我们在谈论什么？
我觉得，这些方面必不可少——
- https 是什么？
- https 与 http 的区别
- https 设计原理
- https 密钥互换过程
https 是什么？
（此处已假设你熟悉并理解 http 协议，如不懂可以参考我另一篇文章）
https 是我们日常编程常用到的与安全有关的网络协议， https 俗称是基于 SSL/TLS 的 http 协议。
SSL/TLS 是什么呢？
可以理解为是一种安全协议，相当于网络协议的安全套接层。
那 https 协议其实就相当于是在 http 协议外面套了一层安全协议，这就是 https 协议。
为什么要套这层SSL/TLS安全协议呢？因为 http 是不安全的。
了解过web安全应该知道 http 协议是明文通信的，那么就会带来3个安全问题：
- 窃听风险：第三方可以获知通信内容
- 篡改风险：第三方可以修改通信内容
- 冒充风险：第三方可以冒充他人身份参与通信
而 https 的诞生就恰好是为了解决这3个问题的。在 tcp 层与 http 层之间加入了 SSL/TLS ，来为通信提供网络安全信道。
https 与 http 的区别
- http 是由“
http://”起始与默认使用80端口，而https的URL则是由“https://”起始与默认使用443端口 - http 是明文传输信息的，https 是加密（对称加密+非对称加密）传输信息的。
- http不是安全的，而且攻击者可以通过监听和中间人攻击等手段，获取网站帐户和敏感信息等。https 的设计可以防止前述攻击，在正确配置时是安全的
- https 需要到 CA 申请证书，http 不需要证书
暂时我能想到的区别就这么多，欢迎补充：）
https 设计原理
我在网上看到过一篇文章，采用信鸽传信的例子来形象生动的说明了 https 的设计原理。
主人公爱丽丝、鲍勃是一对情侣，马洛里是第三者，现在处在爱丽丝和鲍勃需要用信鸽传密信。
最初，爱丽丝和鲍勃是采用最简陋的通信传输方式，就是信件内容不加密也不做任何处理。这时候他们发现，他们的信件内容经常被人窃听、篡改甚至被冒充的人发信件。原来，他们的信鸽中途被马洛里偷偷抓住了，因此他们的通信其实是不可靠的。
类比过来，这大概就是 http 协议实现的过程。
后来，聪明的鲍勃将信的内容进行加密，即他们事前约定好怎么解密（如将每个字母如 a 均向后移动3位，此时变成 d）。 于是马洛里截获的就是加密过的内容，马洛里就不知道他们的通信内容了。
但是马洛里也非常聪明，他慢慢发现了信件被加密了，不知道从哪里就弄到了解密的方法，于是他们的通信方式再一次变得不可靠。
于是爱丽丝他俩又发明了新的通信方法：爱丽丝先用信鸽寄一个空的带锁的匣子给鲍勃，而且这个匣子也没有锁上，这个锁有且只有一把钥匙，这时候是在爱丽丝手上。鲍勃拿到空匣子之后将加密过的内容放入匣子中，然后锁上一并寄给爱丽丝。
这时候马洛里再截获信鸽也没有用了，因为就算他知道信件里面内容的解密方法，但是他打不开这个盒子，因为只有爱丽丝有钥匙能够打开这个装信件的匣子。这便是 https 通信中非对称加密的精髓了。
但是怎么保障这个匣子就一定是最初爱丽丝寄给鲍勃的那个匣子呢？爱丽丝决定签名标记一下盒子，这样鲍勃收到盒子的时候就可以检查签名来确定是爱丽丝送出的盒子了。
村里比较有名望的泰德给人签名，且他签过的名他一定是可以认出来的，所有人可以信任他。这就是 https 原理设计中的向 CA 申请证书，泰德就相当于是 CA 机构。
这时候爱丽丝寄的匣子可以先找泰德签名，然后鲍勃收到匣子也跟泰德确认是不是爱丽丝的匣子，最后匣子回到爱丽丝手中的时候她再跟泰德确认一遍该签名。这样就完全保证了爱丽丝、鲍勃的信鸽通信是完全可靠的。
这边是 https 协议设计的大致过程。
其中，爱丽丝-鲍勃就是我们开发中的服务端和客户端模型， 马洛里可以想象成网络黑客，匣子是公钥，匣子的钥匙是私钥，然后泰德就是证书认证机构 CA。
信件加密采用的是对称加密，寄匣子然后自己留唯一钥匙的方式采用的是非对称加密。这样他们的通信方式就兼具非对称加密的可靠性和对称加密的高效性了。
“非对称加密算法”：从数学上确保了——即使你知道某个公钥，也很难（不是不可能，是很难）根据此公钥推导出对应的私钥。
“对称加密”：只要知道了加密算法，人人都可以用这个加密算法解开经过对称加密的内容。
https 密钥互换过程
了解了https协议的设计原理，https 的通信过程就比较好理解了。唯一需要重点注意的，就是 https 密钥交换 的过程（这个很多大厂前端面试会考到哦）。
https 密钥交换过程大致如下图所示：
客户端发起HTTPS请求
这个没什么好说的，就是用户在浏览器里输入一个https网址，然后连接到server的443端口。服务端的配置
采用HTTPS协议的服务器一般会向 CA 申请一套数字证书。这套证书其实就是一对公钥和私钥，即公钥加密过的内容，只有私钥才能解密。如果觉得这不太好理解，公钥和私钥可以想象成上面例子中的那个匣子和开匣子的钥匙。传送证书
这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。客户端解析证书
这部分工作是由客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随即值（如上图的 k）。然后用证书的公钥 k2 对该随机值k进行加密 得到 k‘。就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。传送加密信息
这部分传送的是用证书加密后的随机值k’，目的就是让服务端也得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。服务端解密信息
服务端用私钥k1解密k‘后，得到了客户端传过来的随机值k(私钥)，然后把内容通过该值进行对称加密。所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。传输加密后的信息
这部分信息是服务段用私钥加密后的信息，可以在客户端被还原。客户端解密信息
客户端用之前生成的私钥解密服务端传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。
需要注意的是，客户端和服务器端双方最终采用 "对话密钥"（上图中的 k，通过双方协商生成） 进行加密通信的，而非最开始从从 CA 那里申请得到的公钥或私钥。
