为什么需要 HTTPS?
我们知道 HTTP 是⼀个纯⽂本传输协议，对传输过程中的数据包不进⾏加密，是明⽂传输，那这样的话对于介于在发送端和接收端之间的任何 ⼀个节点都能知道传输的内容，这些节点可能是路由器、代理等。
⼀个⽐较常见的例⼦：⽤户完善个⼈信息。⽤户输⼊需要填写的资料，这些资料中可能包含⼀些个⼈居住地址、⼿机号码等⼀些⽐较隐私的数据
，如果采⽤的是 HTTP 协议，只需要在代理服务器上做点⼿脚就可以拿到⽤户的相关资料数据。
软性电路板HTTPS 是如何保障安全的？
HTTPS 其实是 HTTP 的升级版，被称为安全传输协议。我们知道 HTTP 是应⽤层协议，⽽在 HTTP 之下的是 TCP 传输协议，TCP 主要负责传输
数据，⽽ HTTP 定义了如何包装数据，也就是 HTTP 将包装好后的数据包打包给 TCP 让其帮忙进⾏传输。那么 HTTPS 相较于 HTTP 有哪些不⼀样
的地⽅呢？其实在 HTTP 和 TCP 之间多了⼀层加密层 SSL/TLS。
SSL 和 TLS 是类似的东西，SSL 是⼀个加密套件，对 HTTP 打包的数据进⾏加密。TLS 是 SSL 的升级版本，现在说到的 HTTPS 加密套件基本上
指的就是 TLS。
传输加密的流程
原先是 HTTP 应⽤层将数据打包给 TCP进⾏传输，现在应⽤层需要将数据先传给 SSL/TLS 进⾏加密，然后再传给 TCP。
HTTPS 怎么加密数据的？
对称加密：
指的是，加密数据和解密数据⽤的是同⼀个密钥。对称加密的优点在于加密、解密效率⽐较⾼。缺点在于发送⽅和接收⽅公⽤⼀把密钥，如果这个密钥
泄露了数据依然是不安全的。
⾮对称加密：
指的是，加密数据⽤的密钥和解密数据⽤的密钥是不⼀样的，分为公钥(Public)和私钥(Private)，公钥是公开的，相对的私钥是⾮公开的密钥，这⾥有⼀点
需要注意，公钥加密的数据可以⽤私钥解开，同样使⽤私钥加密的数据也能通过公钥解开。
⼀个关于⾮对称加密的例⼦：
假设⼩明是某个知名⽹站 ZH 的⽤户，ZH 处于安全考虑在⼩明登陆的地⽅使⽤了⾮对称加密。⼩明在输⼊帐号、密码然后点击登陆。然后浏览器通过公钥对
⼩明的帐号密码进⾏加密，并向 ZH 发送登陆请求，ZH 通过私钥对数据解密，并进⾏验证，验证通过后将⼩明的个⼈信息再次通过私钥加密，传输回浏览器，
。浏览器再使⽤公钥解密，并展⽰给⼩明。
前⾯说过公钥和私钥可以相互将对⽅加密的数据解开，⽽公钥⼜是公开的，如果中间代理获得公钥，那么可以很容易的将⼩明的数据解开，所以，⾮对称
加密只能保证单向数据传输的安全性。
这⾥有两个问题 1：如何获取公钥？ 2：数据传输仅单向安全
** 1：如何获取公钥？**
这⾥牵涉到两个⾮常重要的概念：证书、CA(证书颁发机构) 证书，可以理解为⼀个站点的⾝份证，这个⾝份证⾥⾯包含了很多信息，其中就有公钥。
当我们访问 ZH 的时候，ZH 就会把证书颁发给浏览器，告诉浏览器访问 ZH 的时候使⽤这个证书⾥⾯的公钥对数据加密，这⾥⼜会有⼀个问题，证书是哪来的这个就需要 CA 了。
CA(证书颁发机构)，⽹站在建站之初会向 CA 提交申请，当申请审核通过后，就会给⽹站颁发证书，⽤户访问⽹站的时候，⽹站将证书颁发给⽤户(其实是给到浏览器，⽤户是⽆感知的)。
到这⾥我们已经知道了证书和公钥都是怎么来的了。
** 2：数据传输仅单向安全**
上⾯我们说到通过私钥加密的数据也可以⽤公钥解开，那这样表明⽹站传给⽤户的数据也是不安全的，
这时候我们会想既然 HTTPS 也是不能完全保证数据的安
全传输，那么为什么现在对 HTTPS 的呼声也很⾼呢？因为，HTTPS 可并不是仅仅只使⽤了⾮对称加密它还结合使⽤了其他⼿段，⽐如使⽤了对称加密来确保授权、
加密传输的效率、安全性。
概括的来说，整个简化版的加密通信的流程是这样的：
1.⼩明访问 ZH，ZH 将⾃⼰的证书给到⼩明(其实是给到浏览器，⽤户在这⾥对这个过程是⽆感知的)
2.浏览器从证书中拿到 ZH 的公钥 A
3.浏览器⽣成⼀个只有⾃⼰知道的对称密钥 B，使⽤公钥 A 加密，加密的数据包含对称密钥 B，并传给 ZH(这个过程是有⼀个协商的，这⾥便于理解简化了)
球墨铸铁铸造
4.ZH 通过私钥去解密，拿到对称密钥 B
5.浏览器、ZH 之后的数据通信，都是使⽤对称密钥 B 进⾏加密
注意：对于每⼀个访问 ZH 的⽤户，⽣成的对称密钥 B 是不⼀样的，⽐如说⼩明、⼩花、⼩华可能⽣
成的就是B1、B2、B3
屋面拉条证书可能存在哪些问题？
简单的了解了 HTTPS 加密通信的流程后，我们会想如何保证证书是合法有效的呢？
证书⾮法可能会有两种情况：
1.证书是伪造的，压根不是 CA 颁发的
2.证书被篡改过，⽐如说将证书中的公钥给替换了
⽰例：
假设，⼩明登陆 ZH ⽹站，⼩明的请求先到了代理服务器上，代理服务器再将请求转发到授权服务器，假如，有⼀天代理服务器被⼊侵了，将⼩名的请求拦截了，同时，返回了⼀个⾮法的证书，然后⼩明(浏览器)相信了，那么⼩明的数据将再次不安全，那么，是通过什么机制防⽌这样的事情发⽣的呢？
我们先来看⼀下证书都包含哪些内容，这样我们就可以知道防护措施了。
证书简介
我们先看⼀下什么是数字证书和摘要，这两个是证书防伪⾮常关键的点。
数字签名与摘要：
简单的说，摘要就是对传输的内容，通过 hash 算法计算出⼀段固定长度的串，然后再通过 CA 的私钥对这段摘要加密，加密后得到的结果就是数字签名。
明⽂->通过 hash 算法->摘要->CA 私钥->数字签名
现在我们来了解⼀下证书中都包含哪些内容，证书的内容⾮常多，我们需要关注的点有⼏个：
1.证书包含了颁发证书机构的名字
2.证书本⾝的数字签名(⽤ CA 私钥⽣成)
3.证书持有者的公钥
4.证书签名⽤到的 hash 算法
有2点需要注意：
1.CA 有⾃⼰的证书，被称为 "根证书"，这个"根证书"是⽤来证明 CA ⾃⼰的，本质是⼀份普通的数字证书
2.浏览器通常会内置⼤多数主流权威的 CA 的根证书
如何辨别⾮法证书：
1.证书颁发机构是伪造的，浏览器不认识，直接认为是危险证书
2.证书颁发机构确实存在，于是根据 CA 名，到对应的内置 CA 根证书、CA 的公钥
3.⽤ CA 的公钥，对伪造的证书的数字签名解密，发现解不了，认为是危险证书
HTTPS 如何保证数据加密传输的安全机制基本上都覆盖了，细节的技术这⾥没提，⽅便于理解，这⾥还有两个问题没有解决，
1.⽹站是如何将证书给到浏览器的道路广角镜
2.上⾯我们提到浏览器会⽣成⼀个对称密钥，这个对称密钥是如何协商的
HTTPS 的数据传输流程和 HTTP 是类似的，同样包含两个阶段，握⼿，数据传输
握⼿阶段，证书下发，密钥协商(这个阶段都还是明⽂的)，数据传输是加密阶段，⽤的就是在握⼿阶段协商出来的密钥
--------------------------------------------------------------------分割线--------------------------------------------------------------
看到⼀篇⽐较不错的⽂章，写的也是⾮常简明易懂，贴出来看看
⾸先先举⼀个例⼦：
假设你坐在⼀个教室⾥⾯，你现在⾮常想把某个信息传递给教室⾥的另⼀个⼈，⼀般我们会选择传纸条。传纸条这个⽐喻相当正确，因为
这就类似互联⽹的⼀个基础协议 TCP 协议的⼯作模式。通常情况下，HTTP 协议的数据是使⽤ TCP 传输协议传输的。HTTP 指的是你在纸
条上写的你要传递的⽬的地的作为，再然后才是你想要传输的内容。途径的同学拿到纸条后根据上⾯的地址传过去就⾏了。这样要⾯临⼀个
问题：途径的同学完全知道你纸条上写的什么。
这就是 HTTP ⾯临的⼀个问题，这个问题通常情况下被叫做 "窃听"，指的是在接受⽅和发送⽅之间的任意⼀个节点这个节点可以是路由可
以是代理服务器，可以偷窥到你传输的内容。这当然也是 HTTPS 要解决的第⼀个问题。这种问题通常是通过"加密"解决的，⼀般采⽤⼀种叫
做 AES 的算法来解决的，这种算法需要⼀个密钥 KEY 来加密整个信息，加密和解密所需要使⽤的 KEY 是⼀样的，所以这种加密⼀般也叫作
对称加密。AES 在数学上保证了，只要你使⽤的 KEY ⾜够的长，破解是很难的。
我们假设这种破解⼏乎是不可能的，现在我们再次回到教室，你接着传纸条，你把地址写上了，也⽤了 AES 对传输的内容加密了。但是问
题来了，AES 有⼀个 KEY，我们怎么把 KEY 传输到⽬的呢？不然对⽅收到后没法解密啊，如果我们把 KEY 直接写在纸条上那么中间⼈也可
以解密，在现实中你可以通过⼀些其他办法来把密钥安全地传输给⽬的地，但是在互联⽹上要想这么做是很难的，毕竟这个过程会有很多节点
，所以，貌似这种⽅式也是不安全的。
我们现在来使⽤另外⼀种加密算法---⾮对称加密算法，这种算法理解起来可能会困难⼀点，这种加密指的是可以⽣成⼀对密钥(K1，K2)凡
是 K1加密的数据，K1 ⾃⾝不能解密，⽽需要 K2 才能解开；凡是 K2 加密的数据，K2 ⾃⾝不能解开，需要 K1 能解开。这种算法有很多，常激光测长仪
⽤的就是 RSA ，我们现在继续传纸条，但是传纸条之前需要先准备把接下来通讯的对称加密密钥给传输过去。于是，你使⽤ RSA ⽣成⼀对密
钥 K1，K2 ，你把K1 ⽤明⽂送了出去，途中有⼈或许会劫持，但是没有⽤，K1 加密的数据需要使⽤ K2 才能解密，⽽此时 K2 在你⾃⼰⼿⾥，
K1 到达⽬的地后，⽬的地的⼈会去准备⼀个接下来⽤于加密传输内容的对称密钥 KEY，然后使⽤ K1 把 KEY 加密了，把加密好的数据传回来
，就算途中的⼈劫持了也解不开，等到了你的⼿上你⽤⼿上的 K2 把K1 加密的 KEY 解出来，现在整个班级只有你和⽬的地有 KEY，你们就可
以使⽤ AES 算法进⾏加密传输了。
当然这个时候会有两个问题：
1：既然⾮对称加密算法那么安全为什么不直接使⽤它来加密信息呢，⽽是去加密对称加密的密钥呢？
因为⾮对称加密密钥对⽣成和加密消耗的时间⽐较长，为了节约双⽅的计算时间，通常只⽤它交换密钥，⽽⾮直接⽤来传输数据。
2：⾮对称加密是完全安全的吗？
听起来是挺安全的，但实际上，还有⼀种更恶劣的攻击是这种⽅法⽆法防范的，这就是传说中的“中间⼈攻击”。我们继续让你坐在教室⾥
传纸条，现在你和你的⽬的地途径⼀个中间⼈，他有意想要知道你们的消息。我们将你称为 A，你的⽬的地称为 B，⽽中间⼈称为 M。当你和 B
完成第⼀次密钥交换的时候，途径了 M，M 知道你要进⾏密钥交换了，它把⼩纸条扣了下来，伪装⾃⼰是 B，伪造了⼀个 KEY，然后⽤你发来的
密钥 K1 对 KEY加密返回给你，你以为你和 B 完成了密钥交换，实际上你是和 M 完成了密钥交换。同时 M 和 B 也完成了⼀次密钥交换，让 B 误
以为和你完成了密钥交换。现在，由A->B 完整的加密，变成了 A(加密链接1)->M(明⽂)->B(加密链接2)的情况了。这时候 M 依然能够知道 A 和 B
传输中的全部信息。
对于这种事，似乎很难到⼀个解决办法来解决这个问题，除⾮我们能从源头保证交换密钥的对象是安全的。这时候我们就要认识互联⽹ HTT
PS 和传纸条的微妙区别了。传纸条的时候，你和你的⽬的地的关系是对等的。⽽你访问⽹站的时候，你访问的对象通常是⼀个⽐较⼤的服务提供商，他们有充沛的资源证明他们的合法性。
这时候我们会引⼊⼀个第三⽅叫做 CA，CA 是⼀些⾮常权威的专门⽤于认证⼀个⽹站合法性的组织。服务商会向他们申请⼀个证书，使得他们
建⽴安全链接时可以带上 CA 的签名。⽽ CA 的安全性由操作系统或浏览器来认证。你的 Windows、Linux、Chrome等会默认内置⼀些 CA 证书列表，如果和你建⽴安全链接的⼈带着这些⼈的签名，那么认为这个安全连接是安全的，没有遭到中间⼈攻击。
CA 证书通常情况下是安全的，因为⼀旦某个 CA 颁发的证书被⽤于⾮法途径，浏览器和操作系统⼀般会通过更新将整个 CA 颁发过的全部证书
煎药锅视为不安全。这使得 CA 在颁发证书的时候是⽐较⼩⼼的。
所以，通过⾮对称加密 + 对称加密 + CA 认证这三个技术混合在⼀起，才使得 HTTP 的后⾯加上了⼀个 S-Security。实际上 HTTPS 的协议⽐
我这⾥描述的更加复杂⼀些，这⾥主要说的是基本的实现原理。因为其中任何⼀环稍有闪失，就会使得整个加密都将变得不安全。这也是为什么 HT TPS 的加密协议从 SSL1.0升级到SSL3.0再被 TLS1.0 取代现在被TLS1.2取代，但即使如此，你的 HTTPS 尽可能的保证了你传输的安全，但这种安全也不是绝对的，⽐如说 CA 证书被⽤于了中间⼈攻击，短期内，你的安全将陷于直接的⿇烦，直到浏览器或操作系统重新更新了 CA 列表或你⼿动调整了列表，但是⼤多数情况下还是安全的。
