本文由 ELab 技术团队分享，原题“探秘 HTTPS”，有订正和改变。
1、引言
对于 IM 开发者来说，IM 里最罕用的通信技术就是 Socket 长连贯和 HTTP 短连贯（通常一个支流 im 会是这两种通信伎俩的联合）。从通信安全的角度来说，Socket 长连贯的安全性，就是基于 SSL/TLS 加密的 TCP 协定来实现的（比方微信的 mmtls，见《微信新一代通信安全解决方案：基于 TLS1.3 的 MMTLS 详解》）；而对于 HTTP 短连贯的安全性，也就是 HTTPS 了。
到底什么是 HTTPS？为什么要用 HTTPS？明天就借此机会，跟大家一起深刻学习一下 HTTPS 的相干常识，包含 HTTP 的倒退历程、HTTP 遇到的问题、对称与非对称加密算法、数字签名、第三方证书颁发机构等概念。
学习交换：
- 挪动端 IM 开发入门文章：《新手入门一篇就够：从零开发挪动端 IM》
- 开源 IM 框架源码：https://github.com/JackJiang2…
（本文已同步公布于：http://www.52im.net/thread-38…）
2、系列文章
本文是 IM 通信平安常识系列文章中的第 9 篇，此系列总目录如下：
《即时通讯平安篇（一）：正确地了解和应用 Android 端加密算法》
《即时通讯平安篇（二）：探讨组合加密算法在 IM 中的利用》
《即时通讯平安篇（三）：罕用加解密算法与通信平安解说》
《即时通讯平安篇（四）：实例剖析 Android 中密钥硬编码的危险》
《即时通讯平安篇（五）：对称加密技术在 Android 平台上的利用实际》
《即时通讯平安篇（六）：非对称加密技术的原理与利用实际》
《即时通讯平安篇（七）：如果这样来了解 HTTPS 原理，一篇就够了》
《即时通讯平安篇（八）：你晓得，HTTPS 用的是对称加密还是非对称加密？》
《即时通讯平安篇（九）：为什么要用 HTTPS？深入浅出，探密短连贯的安全性》（* 本文）
3、写在后面
说到 HTTPS，那就得回到 HTTP 协定。
对于 HTTP 协定，大家必定都熟得不能再熟了。那么 HTTPS 和 HTTP 的区别大家理解吗？
对于这个经典的面试题，大部分人会这么答复：
1）HTTPS 比 HTTP 多了一个 S(Secure)：也就是说 HTTPS 是平安版的 HTTP；
2）端口号不同：HTTP 应用 80 端口，HTTPS 应用 443 端口；
3）加密算法：HTTPS 用的是非对称加密算法。
下面的答复能给几分？等看完本文咱们能够再回头来看下这个答复。
那么，HTTPS 是如何实现平安的短连贯数据传输呢？想彻底搞明确这个问题，还是要从 HTTP 的倒退历程说起 ……
4、HTTP 协定回顾
4.1 根底常识
HTTP 是 Hypertext Transfer Protocal 的缩写，中文全称是超文本传输协定（详见《深入浅出，全面了解 HTTP 协定》）。
艰深了解释就是：
1）超文本是指蕴含但不限于文本外的图片、音频、视频等多媒体资源；
2）协定是通信单方约定好的数据传输格局以及通信规定。
HTTP 是 TCP/IP 协定簇的最高层——应用层协定：
▲ 上图援用自《深入浅出，全面了解 HTTP 协定》
浏览器和服务器在应用 HTTP 协定互相传递超文本数据时，将数据放入报文体内，同时填充首部（申请头或响应头）形成残缺 HTTP 报文并交到上层传输层，之后每一层加上相应的首部（管制局部）便一层层的下发，最终由物理层将二进制数据以电信号的模式发送进来。
HTTP 的申请如下图所示：
▲ 上图援用自《深入浅出，全面了解 HTTP 协定》
HTTP 报文构造如下：
4.2 倒退历程
HTTP 的倒退历程如下：
由 HTTP 的倒退历程来看，最开始版本的 HTTP(HTTP1.0)在每次建设 TCP 连贯后只能发动一次 HTTP 申请，申请结束就开释 TCP 连贯。
咱们都晓得 TCP 连贯的建设须要通过三次握手的过程，而每次发送 HTTP 申请都须要从新建设 TCP 连贯，毫无疑问是很低效的。所以 HTTP1.1 改善了这一点，应用长连贯的机制，也就是“一次 TCP 连贯，N 次 HTTP 申请”。
HTTP 协定的长连贯和短连贯，本质上是 TCP 协定的长连贯和短连贯。
在应用长连贯的状况下，当一个网页关上实现后，客户端和服务器之间用于传输 HTTP 数据的 TCP 连贯不会敞开，客户端再次拜访这个服务器时，会持续应用这一条曾经建设的连贯。Keep-Alive 不会永恒放弃连贯，它有一个放弃工夫，能够在不同的服务器软件（如 Apache）中设定这个工夫。实现长连贯须要客户端和服务端都反对长连贯。
PS：对于 IM 开发者来说，为了与 Socket 长连贯通道辨别，通常认为 HTTP 就是“短连贯”（尽管这个“短连贯”不肯定真的“短”）。
HTTP1.0 若要开启长连贯，须要加上 Connection: keep-alive 申请头。无关 HTTP 协定的具体倒退历程可浏览《一文读懂 HTTP 协定的历史演变和设计思路》一文。
4.3 平安问题
随着 HTTP 越来越宽泛的应用，HTTP 的安全性问题也逐步裸露。
回顾一下多年前遍地都是的运营商劫持，当你拜访一个原本很失常的网页，但页面上却莫名其妙呈现了一些广告标签、跳转脚本、欺骗性的红包按钮，甚至有时候原本要下载一个文件，最初下载下来却变成了另外一个齐全不同的货色，这些都是被运营商劫持了 HTTP 明文数据的景象。
下图就是似曾相识的运营商劫持效果图：
PS：对于运营商劫持问题，能够具体浏览《全面理解挪动端 DNS 域名劫持等杂症：原理、本源、HttpDNS 解决方案等》。
HTTP 次要有以下 3 点安全性问题：
演绎一下就是：
1）数据保密性问题：因为 HTTP 无状态，而且又是明文传输，所有数据内容都在网络中裸奔，包用户括身份信息、领取账号与明码。这些敏感信息极易泄露造成安全隐患；
2）数据完整性问题：HTTP 数据包在达到目标主机前会通过很多转发设施，每一个设施节点都可能会篡改或调包信息，无奈验证数据的完整性；
3）身份校验问题：有可能蒙受中间人攻打，咱们无奈验证通信的另一方就是咱们的指标对象。
因而，为了保障数据传输的安全性，必须要对 HTTP 数据进行加密。
5、常见的加密形式
5.1 根本状况
常见的加密形式分为三种：
1）对称加密；
2）非对称加密；
3）数字摘要。
前两种适宜数据传输加密，而数字摘要不可逆的个性常被用于数字签名。
接下来，咱们逐个简要学习一下这三种常见的加密办法。
5.2 对称加密
对称加密也称为密钥加密或单向加密，就是应用同一套密钥来进行加密和解密。密钥能够了解为加密算法。
对称加密图示如下：
宽泛应用的对称加密有：
对称加密算法的优缺点和实用场景：
1）长处：算法公开、简略，加密解密容易，加密速度快，效率高；
2）毛病：相对来说不算特地平安，只有一把钥匙，密文如果被拦挡，且密钥也被劫持，那么，信息很容易被破译；
3）实用场景：加解密速度快、效率高，因而实用于大量数据的加密场景。因为如何传输密钥是较为头痛的问题，因而实用于无需进行密钥替换的场景，如外部零碎，当时就能够间接确定密钥。
PS：能够在线体验对称加密算法，链接是：http://www.jsons.cn/textencrypt/
小常识：base64 编码也属于对称加密哦！
5.3 非对称加密
非对称加密应用一对密钥（公钥和私钥）进行加密和解密。
非对称加密能够在不间接传递密钥的状况下，实现解密，具体步骤如下：
1）乙方生成两把密钥（公钥和私钥）。公钥是公开的，任何人都能够取得，私钥则是窃密的；
2）甲方获取乙方的公钥，而后用它对信息加密；
3）乙方失去加密后的信息，用私钥解密。
以最典型的非对称加密算法 RSA 为例，举个例子：
想要彻底搞懂 RSA，须要理解数论的常识，全副推导过程 RSA 加密算法。简略介绍思路：应用两个超大质数以及其乘积作为生成公钥和私钥的资料，想要从公钥推算出私钥是十分艰难的（须要对超大数因式分解为两个很大质数的乘积）。目前被破解的最长 RSA 密钥是 768 个二进制位。也就是说，长度超过 768 位的密钥，还无奈破解（至多没人公开发表）。因而能够认为，1024 位的 RSA 密钥根本平安，2048 位的密钥极其平安。
非对称加密算法的优缺点和实用场景：
1）长处：强度高、安全性强于对称加密算法、无需传递私钥导致没有密钥泄露危险；
2）毛病：计算量大、速度慢；
3）实用场景：实用于须要密钥替换的场景，如互联网利用，无奈当时约定密钥。
实际利用过程中，其实能够与对称加密算法联合：
1）利用非对称加密算法安全性较好的特点来传递对称加密算法的密钥。
2）利用对称加密算法加解密速度快的特点，进行数据内容比拟大的加密场景的加密（如 HTTPS）。
PS：对于 IM 开发者来说，《探讨组合加密算法在 IM 中的利用》一文值得一读。
5.4 如何抉择？
1）如果抉择对称加密：
HTTP 申请方应用对称算法加密数据，那么为了接管方可能解密，发送方还须要把密钥一起传递到接管方。在传递密钥的过程中还是可能受到嗅探攻打，攻击者窃取密钥后仍然能够解密从而失去发送的数据，所以这种计划不可行。
2）如果抉择非对称加密：
接管方保留私钥，把公钥传递给发送方。发送方用公钥来加密数据，接管方应用私钥解密数据。攻击者尽管不能间接获取这些数据（因为没有私钥），然而能够通过拦挡传递的公钥，而后把本人的公钥传给发送方，再用本人的私钥对发送方发送数据进行解密。
整个过程通信单方都不晓得中间人的存在，然而中间人可能取得残缺的数据信息。
3）两种加密办法的混合：
先应用非对称加密算法加密并传递对称加密的密钥，而后单方通过对称加密形式加密要发送的数据。看起来没什么问题，但事实是这样吗？
中间人仍然能够拦挡公钥的传递，并以本人的公钥作为替换，治标不治本。
想要治标，就要找到一个第三方公证人来证实公钥没有被替换，因而就引出了数字证书的概念，这也是下一节将分享的内容。
6、数字证书
6.1 CA 机构
CA 就是 Certificate Authority，即颁发数字证书的机构。
作为受信赖的第三方，CA 承当公钥体系中公钥的合法性测验的责任。
证书就是源服务器向可信赖的第三方机构申请的数据文件。这个证书除了表明这个域名是属于谁的，颁发日期等，还包含了第三方证书的私钥。
服务器将公钥放在数字证书中，只有证书是可信的，公钥就是可信的。
上面两图是飞书域名的证书中局部内容的信：
6.2 数字签名
摘要算法：个别用哈希函数来实现，能够了解成一种定长的压缩算法，它能把任意长度的数据压缩到固定长度。这好比是给数据加了一把锁，对数据有任何渺小的改变都会使摘要变得截然不同。
通常状况下：数字证书的申请人（服务器）将生成由私钥和公钥以及证书申请文件（Certificate Signing Request，CSR）组成的密钥对。CSR 是一个编码的文本文件，其中蕴含公钥和其余将蕴含在证书中的信息（例如：域名、组织、电子邮件地址等）。密钥对和 CSR 生成通常在将要装置证书的服务器上实现，并且 CSR 中蕴含的信息类型取决于证书的验证级别。与公钥不同，申请人的私钥是平安的，永远不要向 CA（或其余任何人）展现。
生成 CSR 后：申请人将其发送给 CA，CA 会验证其蕴含的信息是否正确，如果正确，则应用颁发的私钥对证书进行数字签名，而后将签名放在证书内随证书一起发送给申请人。
在 SSL 握手阶段：浏览器在收到服务器的证书后，应用 CA 的公钥进行解密，取出证书中的数据、数字签名以及服务器的公钥。如果解密胜利，则可验证服务器身份实在。之后浏览器再对数据做 Hash 运算，将后果与数字签名作比照，如果统一则能够认为内容没有收到篡改。
对称加密和非对称加密是公钥加密、私钥解密，而数字签名正好相同——是私钥加密（签名）、公钥解密（验证），如下图所示。
限于篇幅，对于数字证书的内容本文就不再赘述，想具体理解的能够浏览：
1）一文读懂 Https 的安全性原理、数字证书、单项认证、双项认证等；
2）你晓得，HTTPS 用的是对称加密还是非对称加密？；
3）如果这样来了解 HTTPS，一篇就够了。
7、为什么要应用 HTTPS
《图解 HTTP》一书中提到 HTTPS 就是身披 SSL 外壳的 HTTP。
7.1 SSL
SSL 在 1999 年被更名为 TLS。
所以说：HTTPS 并不是一项新的应用层协定，只是 HTTP 通信接口局部由 SSL 和 TLS 代替而已。
具体就是：HTTP 会先间接和 TCP 进行通信，而 HTTPS 会演变为先和 SSL 进行通信，而后再由 SSL 和 TCP 进行通信。
SSL 是一个独立的协定，不只有 HTTP 能够应用，其余应用层协定也能够应用，比方 FTP、SMTP 都能够应用 SSL 来加密。
7.2 HTTPS 申请流程
HTTPS 申请全流程如下图：
如上图所示：
1）用户在浏览器发动 HTTPS 申请，默认应用服务端的 443 端口进行连贯；
2）HTTPS 须要应用一套 CA 数字证书，证书内会附带一个服务器的公钥 Pub，而与之对应的私钥 Private 保留在服务端不公开；
3）服务端收到申请，返回配置好的蕴含公钥 Pub 的证书给客户端；
4）客户端收到证书，校验合法性，次要包含是否在有效期内、证书的域名与申请的域名是否匹配，上一级证书是否无效（递归判断，直到判断到零碎内置或浏览器配置好的根证书），如果不通过，则显示 HTTPS 正告信息，如果通过则持续；
5）客户端生成一个用于对称加密的随机 Key，并用证书内的公钥 Pub 进行加密，发送给服务端；
6）服务端收到随机 Key 的密文，应用与公钥 Pub 配对的私钥 Private 进行解密，失去客户端真正想发送的随机 Key；
7）服务端应用客户端发送过去的随机 Key 对要传输的 HTTP 数据进行对称加密，将密文返回客户端；
8）客户端应用随机 Key 对称解密密文，失去 HTTP 数据明文；
9）后续 HTTPS 申请应用之前替换好的随机 Key 进行对称加解密。
7.3 HTTPS 到底解决了什么问题
HTTPS 的确解决了 HTTP 的三个安全性问题：
1）保密性：联合非对称加密和对称加密实现保密性。用非对称加密形式加密对称加密的秘钥，再用对称加密形式加密数据；
2）完整性：通过第三方 CA 的数字签名解决完整性问题；
3）身份校验：通过第三方 CA 的数字证书验证服务器的身份。
7.4 HTTPS 优缺点
最初咱们总结一下 HTTPS 的优缺点：
能够看到：HTTPS 确实是当今平安传输 HTTP 的最优解，但他并不是完满的，仍会有破绽。
8、参考资料
[1] 深入浅出，全面了解 HTTP 协定
[2] HTTP 协定必知必会的一些常识
[3] 从数据传输层深度解密 HTTP
[4] 一文读懂 HTTP 协定的历史演变和设计思路
[5] 你晓得一个 TCP 连贯上能发动多少个 HTTP 申请吗？
[6] 如果这样来了解 HTTPS，一篇就够了
[7] 一分钟了解 HTTPS 到底解决了什么问题
[8] 你晓得，HTTPS 用的是对称加密还是非对称加密？
[9] HTTPS 时代已来，打算更新你的 HTTP 服务了吗？
[10] 一篇读懂 HTTPS：加密原理、平安逻辑、数字证书等
[11] 全面理解挪动端 DNS 域名劫持等杂症：原理、本源、HttpDNS 解决方案等
（本文已同步公布于：http://www.52im.net/thread-38…）