网络协议 13 - HTTPS 协议：加密路上无尽头

系列文章传送门：

1. 网络协议 1 - 概述
2. 网络协议 2 - IP 是怎么来，又是怎么没的？
3. 网络协议 3 - 从物理层到 MAC 层
4. 网络协议 4 - 交换机与 VLAN：办公室太复杂，我要回学校
5. 网络协议 5 - ICMP 与 ping：投石问路的侦察兵
6. 网络协议 6 - 路由协议：敢问路在何方？
7. 网络协议 7 - UDP 协议：性善碰到城会玩
8. 网络协议 8 - TCP 协议（上）：性恶就要套路深
9. 网络协议 9 - TCP协议（下）：聪明反被聪明误
10. 网络协议 10 - Socket 编程（上）：实践是检验真理的惟一标准
11. 网络协议 11 - Socket 编程（下）：眼见为实耳听为虚
12. 网络协议 12 - HTTP 协议：经常使用而不简单

---

    以前说了 HTTP 协议的各类问题，可是它仍是陪伴着互联网、陪伴着咱们走过了将近二十年的风风雨雨。如今有不少新的协议尝试去取代它，来解决性能、效率等问题，但它还还能靠着“多年的情分”活的滋润。然而，近些年，由于致命的安全问题，它不得不升级成 HTTPS 了。

    就拿咱们叫外卖来讲，咱们点外卖的数据包被黑客截获，而后在服务器回复你以前给你回复一个假消息：“好啊，你该付款了，把银行卡号、密码拿来。”，这时若是你真的把卡号和密码发给他，那你的钱包就真的危险了。

    为了解决这些问题，咱们给 HTTP 引入了加密，变成了 HTTPS。你们千万不要觉得 HTTPS 是个新的协议，它实际上就是：

HTTPS = HTTP + SSL 层

    这里的 SSL 层的主要工做就是加密。加密方式通常分为两种：对称加密和非对称加密。

    这两种加密算法，对称加密要比非对称加密的效率要高不少，性能也好不少，因此交互的场景下多用对称加密。

对称加密

    在对称加密算法中，加密和解密的密钥是相同的。也就是说，加密和解密使用的是同一个密钥。所以，使用者必定要作好保密功能，不能让第三方知道。

    假设叫外卖的你和第三方约定了一个密钥 A，你发送请求的时候用 A 进行加密，外卖网站也用 A 进行解密，这样就算黑客截获了大家的请求，可是没有正确的密钥，仍是破解不了。

    看起来很好的解决了黑客的问题。可是这里又引入了一个问题，你和外卖网站怎么来约定这个密钥呢？若是这个密钥在互联网上传输，就必须还得用 B 密钥来加密，不然被黑客获取到 A，大家的交互仍是不安全，并且，大家又怎么约定 B 呢？因此，只能经过线下传输。

    线下传输的话，看过《肖申克的救赎》的博友应该知道，安迪越狱前给瑞德约定了一个地点，让他去那里拿一个信封，里面写着他的住处。

    那咱们和外卖网站也能够用这样的骚操做，偷偷约定时间地点，它给你一个纸条，上面写着大家两个的密钥，而后就用这个密钥在互联网定外卖。

    打住打住，上面这个操做想一想都难以想象，若是最初的互联网是这样发展的话，那相信确定活不久。

    相信你也发现了，只有对称加密，就会陷入密钥安全问题的死循环里，这时候，就须要非对称加密了。

非对称加密

    在非对称加密中 ，加密和解密过程当中使用两个不相同的密钥。一个是公开的公钥，另外一个是谁都不给的私钥。公钥加密的信息，只有私钥才能解密，而私钥加密的信息，也只有公钥才能解密。

    放到外面上面的叫外卖过程当中，非对称加密的私钥由外卖网站保存，不会再网上传输，这样就保证了私钥的私密性。与之对应的公钥是能够在互联网上随意传播的，只要外卖网站把这个公钥给你，大家就能够安全的互通了。

    仍是来看咱们点外卖的过程。咱们用公钥加密，说“我要豆浆加油条”。黑客在中间截获了这个数据包，可是他没有私钥，无法解密数据，所以能够顺利到达外卖网站。而外卖网站用私钥把这个报文解出来，而后回复，“我知道了，你付款吧，给我卡号和密码”。

    整个过程好像很安全，不再怕黑客了。可是，先别太乐观，你的银行卡是安全了，可是外卖网站可仍是有危险的。黑客有外卖网站的公钥，能够模拟发送“我要定外卖”这个信息。

    为了解决这个问题，看来一对公钥私钥是不够的，客户端也须要有本身的公钥和私钥，而且客户端也要把本身的公钥给外卖网站。

    这样，客户端给外卖网站发送信息的时候，用外卖网站的公钥加密，而外卖网站给客户端发送消息的时候，使用客户端的公钥。这样就算有黑客企图模拟客户端获取一些信息，或者半路截获回复信息，可是因为它没有私钥，这些信息它仍是打不开。

    说了那么多，相信你也发现了，非对称加密也会有一样的问题，如何将不对称加密的公钥给对方？这时有两种可行方式，一种是放在一个公网的地址上，让对方下载，另外一种就是在创建链接的时候传给对方。

    这两种方法也有相同的问题。做为普通网民，你怎么鉴别别人给你的公钥是对方的，而不是被黑客冒充的？要知道，每一个人都是能够建立本身的公钥和私钥的，建立过程以下：

# bash
// 建立私钥：
openssl genrsa -out httpsprivate.key 1024

// 根据私钥获取公钥
openssl rsa -in httpsprivate.key -pubout -out httpspublic.pem

HTTPS 证书

    能够看到，经过工具，咱们能够很容易的建立公钥和私钥，那么黑客也是能够建立的，我们怎么知道外卖网站传过来的公钥是否是真的就是外卖网站的呢？这时候，就须要第三方机构来当这个中间人了。

    这就像咱们的户口本同样，每一个人均可以打印出来，说是真的户口本，可是去使用的时候，人家就只认有公安局盖章的户口本。这个由权威部门颁发的称为**证书（Certificate）。

    HTTPS 证书里面应该有如下内容：

• 公钥：这是最重要的；
• 全部者：说明证书是属于谁的，就像户口本上的姓名和身份证号，来证实这个户口本是你的；
• 证书发布机构：看看你的户口本上有没有某某公安局的字样？
• 证书有效时间：这个和我们身份证有效期是一个意思。

    说完了证书的内容，就到了下一步，怎么获取证书？这就像家里添了个小公举，去哪里上户口呢？恐怕你们都知道去公安局。与之对应的，HTTPS 也有专门负责派发证书的机构，这个机构咱们称为 CA（Certificate Authrity）。而证书则能够经过下面这个命令生成：

openssl req -key httpsprivate.key -new -out httpscertificate.req

    将这个请求发给 CA，CA 会给这个证书“盖”一个章，咱们称为签名算法。这个签名用到 CA 的私钥进行签发，来保证签名不被伪造。

    签名算法大概是这样工做的：通常是对信息作一个 Hash 计算，获得一个 Hash 值，这个过程是不可逆的，也就是说没法经过 Hash 值还原回原来的信息内容。再把信息发出时，把上面获得的 Hash 加密后，做为一个签名和信息一块儿发出去。CA 给整数签名的命令是：

openssl x509 -req -in httpscertificate.req -CA cacertificate-pem -CAkey caprivate.key

    这个命令会返回 Signature ok，而 httpscertificate.pem 就是签名过的整数。CA 用本身的私钥给外卖网站的公钥签名，这就至关于给外卖网站背书，造成了外卖网站的证书。咱们能够经过下面这个命令查看证书内容：

openssl x509 -in httpscertificate.pem -noout -text

    证书会显示如下内容：

• lssuer：证书颁发者；
• Subject：证书颁发给谁；
• Validity：证书期限；
• Public-key：公钥内容；
• Sinature Algorithm：签名算法

    经过这种方式，咱们访问外卖网站时，获得的再也不是一个公钥，而是一个整数。这个证书里有发布机构 CA，你只要经过这个 CA 的公钥去解密外卖网站证书的签名，解密成功，Hash 对的上，就说明外卖网站的公钥是真实可信的。

    上述整个过程当中，都有一个前提，CA 是可信的。可是，咱们又怎么肯定 CA 的公钥就是对的呢？这就像有的人在偏远农村搞了个假公安局同样（应该没人这么干吧），咱们怎么知道公安局是否是假的呢？而后咱们就会想到，我去县公安局确认下当地公安局的信息不就行了。没错，CA 也是这么干的。

    CA 的公钥也须要更牛的 CA 给它签名，而后造成 CA 的公钥。要想知道某个 CA 的证书是否可靠，要看 CA 的上级证书的公钥能不能解开这个 CA 的签名。这样追根溯源，直到全球皆知的几大著名 CA，咱们称为Root CA，作最后的背书。正是经过这种层层授信背书的形式，保证了非对称加密模式的争吵运转。

    除此以外，还有一种证书， 称为Self-Signed Certificate，就是本身给本身签名。这个就给人一种“我就是我，不同的烟火，你爱信不信”的感受，有兴趣的博友能够自行搜索了解。

HTTPS 的工做模式

    上面说了对称加密和非对称加密的原理，咱们知道了非对称加密在性能上远不如对称加密，那在 HTTP 中，可否将二者结合起来呢？例如，公钥私钥主要用于传输对称加密的密钥，而真正的双方大数据量的通讯都是经过对称加密进行。

    是的，HTTPS 协议的思路就是这样的。以下图：

    图比较长，整个过程最后的目标是生成在后续通讯过程当中使用的对称密钥，以及约定使用的加密算法。总体过程以下：

1. 客户端明文发送 TLS 版本信息、加密套件候选列表、压缩算法候选列表等信息，另外还会发送一个随机数，在协商对称密钥的时候使用（你好，我想定外卖，但你要保密我点了什么。这是个人加密套路列表，还有一个随机数 A，你留着）；
2. 服务器返回 Server Hello 消息，告诉客户端，服务器选择使用的协议版本、加密套件、压缩算法等，还有一个随机数 B，用于后续进行密钥协商（你好，保密没问题，就按套路 2 来吧，我也给你一个随机数 B，你留着）；
3. 服务器给客户端证书；
4. 客户端从本身信任的 CA 仓库中，拿 CA 的证书里面的公钥去解密服务器传来的证书。解密成功，说明外卖网站是可信的。这个解密过程，客户端可能胡不断往上追溯 CA、CA 的 CA、CA 的 CA 的 CA，直到一个授信的 CA 为止；
5. 证书验证可信后，客户端会计算产生随机数字 Pre-master，发送Client Key Exchange，用证书中的公钥加密，再发给服务器；

    到此时，不管是客户端仍是服务端，都有了三个随机数，分别是：A、B、Pre-master。经过这三个随机数，客户端和服务端能够产生相同的对称密钥。

    约定好对称密钥和加密算法，就能够用对称加密的形式进行加密通讯了，后续的通讯除了多了一步密钥校验的过程，HTTP 协议里的那些过程都不会少。

    不过上面的过程当中只包含了 HTTPS 的单向认证，也就是客户端验证服务端的证书，这也是最多见的场景。不过在更加严格要求通讯安全的状况下，也能够启用双向认证，双方互相验证证书。

    经过上面的整个过程，咱们能够看出，HTTPS 协议并非一个新的协议，它只是 HTTP 协议与一些加密算法的组合，用来保证通讯的安全。

    虽然上面介绍的非对称加密方式，在如今看来是完美不可解的，但将来谁知道呢？正所谓“道高一尺魔高一丈”，加密安全路上永无尽头。

小结

• 加密分对称加密和非对称加密。对称加密效率高，但存在密钥传输的问题；非对称加密能够解决密钥传输的问题，但效率较低。
• 非对称加密须要经过证书和权威机构来验证公钥的合法性。
• HTTPS 是综合了对称加密和非对称加密算法的 HTTP 协议。既保证了传输安全，也保证了传输效率。

参考：

1. 百度百科 - htps 词条；
2. 刘超 - 趣谈网络协议系列课；