共计 1382 个字符，预计需要花费 4 分钟才能阅读完成。
大家都晓得 https。是 http 协定上多加了一层 SSL 协定进行加密的，只晓得它平安确不理解它为什么平安，那明天就来简略说一下：
HTTP：
首先 http 是不平安的，明文传输数据，容易被黑客抓包抓到，那么怎么办呢？须要对数据进行加密，那如何进行加密？
对称加密：
在客户端发送数据之前，服务器就生成的 密钥 传输给客户端，在之后客户端发送数据的时候应用该 密钥 进行加密。之后客户端与服务端的数据传输就应用该 密钥 进行加解密。那这样带来的问题就是 密钥 自身也是 明文传输 的，那黑客也同样能劫取到 密钥 ，而后应用 密钥 对用户的数据进行 解密 ，那和明文传输有什么别离？( 黑客：哈哈，你这不是逗我呢)接下来引入另一个配角“非对称加密”
非对称加密
加密的办法还是须要传输密钥 ，可问题出在了 如何将密钥平安传输到服务器 。而后就呈现了 公钥和私钥 这种货色，我叫他 “阴阳钥 ”, 并且让客户端和服务器都领有两把钥匙，一把钥匙是公开的(公钥)，一把钥匙是私密的（私钥）。两把钥匙，用公钥加密的数据，必须对应的私钥能力解密。相同，用私钥加密的数据，必须是对应的公钥能力解密。
在传输数据的时候客户端先发送本人的 公钥 给服务器，而后服务器应用该 公钥 对数据 进行加密 。客户端收到当前再用本人的 私钥 进行 解密 。相同客户端向服务器传输也是一样。这下终于能保证数据的平安传输了。可是又呈现了另外一个辣手的问题： 加密的速度慢了很多倍。这可怎么办？几个程序员探讨了半天 联合了两种形式：”对称加密 + 非对称加密“
对称加密 + 非对称加密
应用非对称加密的形式来加密“密钥”，而后应用对称加密的形式来加密传输的数据。
具体流程：服务器先明文发送 本人的公钥 给客户端，而后客户端在发送数据前会 生成一把密钥 并且应用服务端的 公钥来加密 。如此一来，这把加密后的 密钥 就只能服务器来解密。相同，客户端也有本人的”阴阳钥“，服务器用客户端的公钥来加密，客户端用本人的私钥来解密。这就达到了平安传输数据的目标。以上说得可能有点绕，要弄懂公钥、私钥、密钥之间的关系。可这真的平安吗？(黑客：有两下子，然而我用本人做的公钥 假冒 服务器的公钥发给你进行 坑骗，那我就失去你的密钥，仍然在我掌控之中哈哈)
几个程序员有点懵，然而冷静下来思考发现存在的问题就是 无奈保障公钥的起源是否真是服务器。通过几天的探讨，推出了一种新的形式：数字证书。
数字证书
首先成立了一个有公信力的认证核心（CA）值得信赖的第三者：服务器在一开始就须要向 CA 申请证书（下载一个证书到服务器上）。当然客户端收到服务端的证书会存储在本地(有个容器专门存储证书)。
当在服务器给客户端 传输公钥的过程中 ， 会把公钥和服务器的个人信息通过本人的 hash 算法生成信息摘要 。为了避免被人调换，服务器会用 CA 的私钥 对摘要进行加密造成”数字签名 “，最初把没进行 hash 算法生成的公钥及 个人信息与这个加密后的数字签名合并在一起 ，就造成了所谓的 数字证书。
在客户端收到 数字证书 后，就会用去本地证书列表里找适合的公钥来对证书外面的 数字签名 进行 解密 以及 hash 算法失去 信息摘要 ，而后 把数字证书外面的摘要和里面的摘要进行比照 ，如果一样，就证实这个起源肯定是服务器。这样就能安心的应用服务器的公钥进行加密了，保障了公钥的安全性。( 黑客：蹩脚，解不开数字签名，假冒不了，可恶的第三者)
对于服务端搭建 https 及主动跳转 https 的内容能够关注我的其余文章。
