计算机网络--HTTPS和加密

项目中如果是内网请求，经常会用到http请求；但是一旦请求经过公网，则我们会要求请求使用https，因为担心请求走出机房后，被网络上的黑客嗅探导致信息泄露。那么既然要防止网络上的黑客嗅探我们的数据，那么https肯定拥有很重要的一个能力--加密。

那么，“HTTPS是什么？”

维基百科对HTTPS的解释是：

超文本传输安全协议（英语：HyperText Transfer Protocol Secure，缩写：HTTPS；常称为HTTP over TLS、HTTP over SSL或HTTP Secure）是一种通过计算机网络进行安全通信的传输协议。HTTPS经由HTTP进行通信，但利用SSL/TLS来加密数据包。HTTPS开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。这个协议由网景公司（Netscape）在1994年首次提出，随后扩展到互联网上。

抓重点：HTTPS=HTTP over SSL/TLS，也就是说，HTTPS在传输层TCP和应用层HTTP之间，多走了一层SSL/TLS。

由此可见，TLS/SSL是HTTPS的核心！ 那么，这个TLS/SSL又是什么呢？文章How to use SSL/TLS to Secure Your Communications: The Basics指出：

The SSL/TLS protocol functions between two layers of the OSI Presentation layer. The handshake and record layers operate over TCP/IP to encrypt data received directly from the Application layer.

SSL/TLS协议作用在传输层和应用层之间，对应用层数据进行加密传输。

SSL和TLS都是加密协议。SSL，全称Secure Socket Layer，在1994年由网景公司（Netscape）最早提出1.0版本；TLS，全称Transport Layer Security，则是1999年基于SSL3.0版本上改进而来的。官方建议弃用SSL而保留和采用TLS，但是由于历史原因，SSL仍然存在，而且很多人已经习惯SSL这个名词，因此现在索性就叫成SSL/TLS。
SSL/TLS的发展史，可以阅读文章《SSL/TLS发展历史和SSLv3.0协议详解》；关于两者的异同，推荐阅读文章《SSL vs. TLS - What’s the Difference?》。

再来，“HTTPS为什么？”

肯定有不少同学不假思索：“当然是HTTP不安全，HTTPS安全，所以选择HTTPS呗！”那么，HTTPS比HTTP“好”在哪里？

维基百科上对HTTP的解释如下：

设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。
HTTP的发展是由蒂姆·伯纳斯-李于1989年在欧洲核子研究组织（CERN）所发起。HTTP的标准制定由万维网协会（World Wide Web Consortium，W3C）和互联网工程任务组（Internet Engineering Task Force，IETF）进行协调，最终发布了一系列的RFC，其中最著名的是1999年6月公布的 RFC 2616，定义了HTTP协议中现今广泛使用的一个版本——HTTP 1.1。

HTTP协议是为了传输网页超文本（文本、图像、多媒体资源），以及规范客户端和服务器端之间互相请求资源的方法的应用层协议。在1989年最早推出了HTTP 0.9版本，而1999年公布的HTTP 1.1是到目前（2020年）仍旧广泛使用的版本（引自《HTTP协议几个版本的比较》）。

但是这个HTTP 1.1版本存在一个很大的问题-明文传输（Plaintext/Clear Text），这个问题在互联网时代的今天是致命的，一旦数据在公共网络中被第三方截获，其通信内容轻而易举地就被窃取了。

因此，HTTPS应运而生，它被公认的三大优势有：

1. 数据加密，防窃听
2. 身份验证，防冒充
3. 完整性校验，防篡改

再插一句题外话：2015年推出的HTTP 2在HTTP 1.1的基础上有很大改进，其中一点就是HTTPS。对HTTP 2有兴趣的同学推荐阅读《HTTP/2 中的常见问题》、《OPINION - HTTP versus HTTPS versus HTTP/2》。

灵魂三问最后一问，“HTTPS怎么做？”

本文接下来将从HTTPS的3个优势展开说明，即：

• 数据加密，即HTTPS是怎么进行数据加密的，将介绍HTTPS中的对称加密和非对称加密
• 身份验证，即HTTPS是怎么让客户端相信“发给我数据的服务端是我想要的服务器”，将介绍HTTPS的CA和证书
• 完整性校验，即HTTPS是怎么做数据完整性校验以防止被篡改，将介绍HTTPS的哈希

最后，为了整篇文章的完整性，还会增加以下几个内容：

• HTTPS流程，即客户端和服务器端HTTPS通信全过程
• 实际问题，记录了笔者在实战中遇到HTTPS相关问题

I. 数据加密：HTTPS的对称加密和非对称加密

相信不少同学会说：“对称加密和非对称加密有什么好讲的？前者只有一把密钥做加解密；后者有两把密钥，公钥和私钥，互为加解密，公钥给对方，私钥自己用。HTTPS两者都有。好了，这章可以结束啦。”

三个问题：

1. HTTPS为什么同时要有对称加密和非堆成加密两种加密方式？
2. HTTPS对称加密的密钥（本文称为SK，下同）如何产生和传输？
3. HTTPS的有几套非对称加密？目的是什么？是否可以省略？

好，一个问题一个问题来。

问题1：HTTPS为什么同时要有对称加密和非对称加密两种加密方式？

默认各位同学已经知晓对称加密和非对称加密（了解基本原理即可），不清楚的同学推荐阅读知乎文章-《对称加密与非对称加密》，文章最后指出了这两个加密方式的优缺点，原文如下：

（1） 对称加密加密与解密使用的是同样的密钥，所以速度快，但由于需要将密钥在网络传输，所以安全性不高。
（2） 非对称加密使用了一对密钥，公钥与私钥，所以安全性高，但加密与解密速度慢。

那么解决办法有吗？有，文章随后说道：

（3） 解决的办法是将对称加密的密钥使用非对称加密的公钥进行加密，然后发送出去，接收方使用私钥进行解密得到对称加密的密钥，然后双方可以使用对称加密来进行沟通。

确实，HTTPS（最开始）就是这么做的！其思路大致如下：

1). 首先一定要明确HTTPS既有对称加密，又有非对称加密。-> 2). 由于对称加密性能高速度快，因此在传输数据时（也就是对话内容）采用对称加密。-> 3). 但是对称加密的密钥SK，既没办法预先设置（密钥不可能只有一把，服务器端维护大量密钥也不具备可行性），因此只能选择在对话前通过网络协商出一把新的SK。-> 4). 为了确保SK的传输安全，使用非对称加密来协商SK。

HTTPS的这种设计同时兼顾了安全和效率，赞叹先驱们的智慧！

问题2：HTTPS对称加密的密钥SK如何产生和传输？

通过第一个问题，我们知道了HTTPS分为2个过程：

1. 协商对称加密密钥SK的非对称加密阶段，称为TLS握手阶段。
2. 使用SK对数据（对话内容）进行对称加密的阶段，称为数据通信阶段。

过程2数据通信阶段：发送端首先用密钥SK对通信内容进行对称加密，接着通过网络传输出去；对端收到数据后，用SK先将数据解密，于是就得到了通信内容。这里笔者有一个问题尚未求证：在数据传输过程中，是否会对通信数据进行哈希以确保其不被篡改？姑且记一笔。

过程1TLS握手阶段：协商密钥SK。网上关于这个知识点的文章有很多，然而一些已经过时，一些则不全。就协商密钥SK这块，笔者推荐《扫盲 HTTPS 和 SSL/TLS 协议[3]：密钥交换（密钥协商）算法及其原理》和《密钥协商机制》。本文直接扔出结论，HTTPS协商对称加密密钥SK的办法有很多种，介绍3种较为常见的办法：

1. 基于非对称加密算法
2. 基于专用密钥交换算法，常见有DH、ECDH等
3. 基于共享的secret，常见有PSK，SRP等

方法1. 基于非对称加密算法

维基百科对于非对称加密算法的解释：

公开密钥密码学（英语：Public-key cryptography）也称非对称式密码学（英语：Asymmetric cryptography）是密码学的一种算法，它需要两个密钥，一个是公开密钥，另一个是私有密钥；一个用作加密，另一个则用作解密。使用其中一个密钥把明文加密后所得的密文，只能用相对应的另一个密钥才能解密得到原本的明文；甚至连最初用来加密的密钥也不能用作解密。由于加密和解密需要两个不同的密钥，故被称为非对称加密；不同于加密和解密都使用同一个密钥的对称加密。虽然两个密钥在数学上相关，但如果知道了其中一个，并不能凭此计算出另外一个；因此其中一个可以公开，称为公钥，任意向外发布；不公开的密钥为私钥，必须由用户自行严格秘密保管，绝不透过任何途径向任何人提供，也不会透露给被信任的要通信的另一方。

非对称加密RSA协商密钥的办法，是HTTPS（严格说是SSL/TLS协议）最早提出的办法之一，其过程如下：

1. 客户端给服务端发送请求；
2. 服务端返回客户端自己的公钥PuK；
3. 客户端产生本次对话的对称密钥SK，并用PuK进行加密得到SK_Enc后传给服务端；
4. 服务端收到SK_Enc后用自己的私钥PrK解密得到SK；若成功，则返回客户端OK，否则终止对话。
5. 接下来，客户端和服务端的对话均用SK加密后传输。

方法2：基于专用密钥交换算法
方法1是被大部分人熟知的，但是存在一个问题：如果服务端的私钥PrK泄露了，那么HTTPS所做的加密也就不安全了。
因此，就有了密钥交换算法（有说法是keyless方法）。方法原理笔者没有深究（数学功底有限，看到大量的公式证明还是会烦…），DH和ECDH协商密钥算法大致过程如下：

ECDH算法中的A和B，在有的材料中也被称为PreMaster-Secret。最终协商得到的密钥SK也被称为Master Secret，也被称为Session Key。

直接给出结论：ECDH比DH算法更快，有说法是10倍；而且ECDH比DH更难破解，可行性更好。推荐阅读《Elliptic Curve Cryptography: ECDH and ECDSA》、《完全吃透 TLS/SSL》更进一步了解DH和ECDH算法。

方法3：基于共享的secret
这类做法就是在客户端和服务端预设好对称加密密钥，握手阶段只需要传递类似钥匙id即可。代表算法有PSK。

问题3：HTTPS的有几套非对称加密？目的是什么？是否可以省略？

直接给出答案：2套非对称加密。
第一套用于协商对称加密密钥SK（问题2一直在讨论的内容）；第二套用于数字证书签名加密（接下来一章会详细讨论CA证书）。这两者的区别是：前者是服务器端（如果是双向验证的话，客户端也会有一套非对称加密公私钥）产生的。私钥在服务端上；后者是CA机构产生的，私钥在CA机构那边。
并且，这2套都不可以省略。（这个说法略不严谨，但是在实际操作中，确实都不建议省略。）