下面来聊聊与安全相关的 HTTPS、SSL、TLS，我们曾经谈到过 HTTP 的一些缺点，其中的无状态在加入 Cookie 后得到了解决，而另两个缺点——明文 和 不安全 仅凭 HTTP 自身是无力解决的，需要引入新的 HTTPS 协议。
为什么要有 HTTPS？
简单的回答是 因为 HTTP 不安全，由于 HTTP 天生明文的特点，整个传输过程完全透明，任何人都能够在链路中截获、修改或者伪造请求 / 响应报文，数据不具有可信性。比如，上面说过的代理服务，它作为 HTTP 通信的中间人，在数据上下行的时候可以添加或删除部分头字段，也可以使用黑白名单过滤 body 里的关键字，甚至直接发送虚假的请求、响应，而浏览器和源服务器都没有办法判断报文的真伪。
这对于网络购物、网上银行、证券交易等需要高度信任的应用场景来说是非常致命的。如果没有基本的安全保护，使用互联网进行各种电子商务、电子政务就根本无从谈起。对于安全性要求不那么高的新闻、视频、搜索等网站来说，由于互联网上的恶意用户、恶意代理越来越多，也很容易遭到流量劫持的攻击，在页面里强行嵌入广告，或者分流用户，导致各种利益损失。对于普通网民来说，HTTP 不安全的隐患就更大了，上网的记录会被轻易截获，网站是否真实也无法验证，黑客可以伪装成银行网站，盗取真实姓名、密码、银行卡等敏感信息，威胁人身安全和财产安全。总的来说，今天的互联网已经不再是早期的田园牧歌时代，而是进入了黑暗森林状态。上网的时候必须步步为营、处处小心，否则就会被不知道埋伏在哪里的黑客所猎杀。
什么是安全？
既然 HTTP 不安全，那什么样的通信过程才是安全的呢？
通常认为，如果通信过程具备了四个特性，就可以认为是安全的，这四个特性是：机密性、完整性，身份认证和不可否认。
机密性（Secrecy/Confidentiality）是指对数据的保密，只能由可信的人访问，对其他人是不可见的秘密，简单来说就是不能让不相关的人看到不该看的东西。比如小明和小红私下聊天，但隔墙有耳，被小强在旁边的房间里全偷听到了，这就是没有机密性。抓包工具 Wireshark 实际上也是利用了 HTTP 的这个特点，捕获了传输过程中的所有数据。
完整性（Integrity，也叫一致性）是指数据在传输过程中没有被窜改，不多也不少，完完整整地保持着原状。机密性虽然可以让数据成为秘密，但不能防止黑客对数据的修改，黑客可以替换数据，调整数据的顺序，或者增加、删除部分数据，破坏通信过程。比如，小明给小红写了张纸条：明天公园见。小强把公园划掉，模仿小明的笔迹把这句话改成了明天广场见。小红收到后无法验证完整性，信以为真，第二天的约会就告吹了。
身份认证（Authentication）是指确认对方的真实身份，也就是 "证明你真的是你"，保证消息只能发送给可信的人。如果通信时另一方是假冒的网站，那么数据再保密也没有用，黑客完全可以使用冒充的身份套出各种信息，加密和没加密一样。比如，小明给小红写了封情书：我喜欢你，但不留心发给了小强。小强将错就错，假冒小红回复了一个白日做梦，小明不知道这其实是小强的话，误以为是小红的，后果可想而知。
第四个特性是不可否认（Non-repudiation/Undeniable），也叫不可抵赖，意思是不能否认已经发生过的行为，不能说话不算数、耍赖皮。使用前三个特性，可以解决安全通信的大部分问题，但如果缺了不可否认，那通信的事务真实性就得不到保证，有可能出现老赖。比如，小明借了小红一千元，没写借条，第二天矢口否认，小红也确实拿不出借钱的证据，只能认倒霉。另一种情况是小明借钱后还了小红，但没写收条，小红于是不承认小明还钱的事，说根本没还，要小明再掏出一千元。
所以，只有同时具备了机密性、完整性、身份认证、不可否认这四个特性，通信双方的利益才能有保障，才能算得上是真正的安全。
什么是 HTTPS？
说到这里，终于轮到今天的主角 HTTPS 出场了，它为 HTTP 增加了刚才所说的四大安全特性。
HTTPS 其实是一个非常简单的协议，RFC 文档很小，只有短短的 7 页，里面规定了新的协议名 https，默认端口号 443，至于其他的什么请求 - 响应模式、报文结构、请求方法、URI、头字段、连接管理等等都完全沿用 HTTP，没有任何新的东西。也就是说，除了协议名 http 和端口号 80 这两点不同，HTTPS 协议在语法、语义上和 HTTP 完全一样，优缺点也照单全收（当然要除去明文和不安全）。
你可能要问了，既然没有新东西，HTTPS 凭什么就能做到机密性、完整性这些安全特性呢？秘密就在于 HTTPS 名字里的 S，它把 HTTP 下层的传输协议由 TCP/IP 换成了 SSL/TLS，由 HTTP over TCP/IP 变成了 HTTP over SSL/TLS，让 HTTP 运行在了安全的 SSL/TLS 协议上，收发报文不再使用 Socket API，而是调用专门的安全接口。
所以说，HTTPS 本身并没有什么惊世骇俗的本事，全是靠着后面的 SSL/TLS 撑腰，只要学会了 SSL/TLS，HTTPS 自然就手到擒来。
SSL/TLS
现在我们就来看看 SSL/TLS，它到底是个什么来历。SSL 即安全套接层（Secure Sockets Layer），在 OSI 模型中处于第 5 层（会话层），由网景公司于 1994 年发明，有 v2 和 v3 两个版本，而 v1 因为有严重的缺陷从未公开过。
SSL 发展到 v3 时已经证明了它自身是一个非常好的安全通信协议，于是互联网工程组 IETF 在 1999 年把它改名为 TLS（传输层安全，Transport Layer Security），正式标准化，版本号从 1.0 重新算起，所以 TLS1.0 实际上就是 SSLv3.1。到今天 TLS 已经发展出了三个版本，分别是 2006 年的 1.1、2008 年的 1.2 和 2018 的 1.3，每个新版本都紧跟密码学的发展和互联网的现状，持续强化安全和性能，已经成为了信息安全领域中的权威标准。
TLS 由记录协议、握手协议、警告协议、变更密码规范协议、扩展协议等几个子协议组成，综合使用了对称加密、非对称加密、身份认证等许多密码学前沿技术。浏览器和服务器在使用 TLS 建立连接时需要选择一组恰当的加密算法来实现安全通信，这些算法的组合被称为密码套件（cipher suite，也叫加密套件）。
那么 SSL/TLS 协议是如何保证通信是安全的呢？
混合加密 的方式实现信息的 机密性，解决了窃听的风险摘要算法 的方式来实现 完整性，它能够为数据生成独一无二的「指纹」，指纹用于校验数据的完整性，解决了篡改的风险将服务器公钥放入到 数字证书 中，解决了冒充的风险
1. 混合加密
通混合加密的方式可以保证信息的机密性，解决了窃听的风险。
HTTPS 采用的是对称加密和非对称加密结合的「混合加密」方式：
在通信建立前采用非对称加密的方式交换「会话秘钥」，后续就不再使用非对称加密在通信过程中全部使用 对称加密 的「会话秘钥」的方式加密明文数据
采用「混合加密」的方式的原因：
对称加密只使用一个密钥，运算速度快，密钥必须保密，无法做到安全的密钥交换非对称加密使用两个密钥：公钥和私钥，公钥可以任意分发而私钥保密，解决了密钥交换问题但速度慢
2. 摘要算法
摘要算法 用来实现完整性，能够为数据生成独一无二的「指纹」，用于校验数据的完整性，解决了篡改的风险。
客户端在发送明文之前会通过摘要算法算出明文的「指纹」，发送的时候把「指纹 + 明文」一同 加密成密文后，发送给服务器，服务器解密后，用相同的摘要算法算出发送过来的明文，通过比较客户端携带的「指纹」和当前算出的「指纹」做比较，若「指纹」相同，说明数据是完整的。
3. 数字证书
客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。这就存在些问题，如何保证公钥不被篡改和信任度？所以这里就需要借助第三方权威机构 CA（数字证书认证机构），将服务器公钥放在数字证书（由数字证书认证机构颁发）中，只要证书是可信的，公钥就是可信的。
通过数字证书的方式保证服务器公钥的身份，解决冒充的风险。
OpenSSL
说到 TLS，就不能不谈到 OpenSSL，它是一个著名的开源密码学程序库和工具包，几乎支持所有公开的加密算法和协议，已经成为了事实上的标准，许多应用软件都会使用它作为底层库来实现 TLS 功能，包括常用的 Web 服务器 Apache、Nginx 等。
OpenSSL 是从另一个开源库 SSLeay 发展出来的，曾经考虑命名为 OpenTLS，但当时（1998 年）TLS 还未正式确立，而 SSL 早已广为人知，所以最终使用了 OpenSSL 的名字。OpenSSL 目前有三个主要的分支，1.0.2 和 1.1.0 都将在今年（2019）年底不再维护，最新的长期支持版本是 1.1.1，我们的实验环境使用的 OpenSSL 是 1.1.0j。由于 OpenSSL 是开源的，所以它还有一些代码分支，比如 Google 的 BoringSSL、OpenBSD 的 LibreSSL，这些分支在 OpenSSL 的基础上删除了一些老旧代码，也增加了一些新特性，虽然背后有 大金主，但离取代 OpenSSL 还差得很远。
HTTPS 是如何建立连接的？其间交互了什么？
SSL/TLS 协议基本流程：
客户端向服务器索要并验证服务器的公钥双方协商生产「会话秘钥」双方采用「会话秘钥」进行加密通信
前两步也就是 SSL/TLS 的建立过程，也就是握手阶段。SSL/TLS 的「握手阶段」涉及四次通信，可见下图：
SSL/TLS 协议建立的详细流程：
1. ClientHello
首先，由客户端向服务器发起加密通信请求，也就是 ClientHello 请求。在这一步，客户端主要向服务器发送以下信息：
客户端支持的 SSL/TLS 协议版本，如 TLS 1.2 版本。客户端生产的随机数（Client Random），后面用于生产「会话秘钥」。客户端支持的密码套件列表，如 RSA 加密算法。
2. ServerHello
服务器收到客户端请求后，向客户端发出响应，也就是 SeverHello。服务器回应的内容有如下内容：
确认 SSL/ TLS 协议版本，如果浏览器不支持，则关闭加密通信。服务器生产的随机数（Server Random），后面用于生产「会话秘钥」。确认的密码套件列表，如 RSA 加密算法。服务器的数字证书。
3. 客户端回应
客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性。如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息：
一个随机数（pre-master key）。该随机数会被服务器公钥加密。加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供服务端校验。
上面第一项的随机数是整个握手阶段的第三个随机数，这样服务器和客户端就同时有三个随机数，接着就用双方协商的加密算法，各自生成本次通信的「会话秘钥」。
4. 服务器的最后回应
服务器收到客户端的第三个随机数（pre-master key）之后，通过协商的加密算法，计算出本次通信的「会话秘钥」。然后，向客户端发生最后的信息：
加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供客户端校验。
至此，整个 SSL/TLS 的握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的 HTTP 协议，只不过用「会话秘钥」加密内容。
所以 HTTPS 连接大致上可以划分为两个部分：第一个是建立连接时的非对称加密握手，第二个是握手后的对称加密报文传输。
也正因为 HTTPS 比 HTTP 增加了一个 TLS 握手的步骤，这个步骤最长可以花费两个消息往返，也就是 2-RTT；以及产生用于密钥交换的临时公私钥对（ECDHE）、验证证书时访问 CA 获取 CRL 或者 OCSP、非对称加密解密处理 Pre-Master，导致 HTTPS 会比 HTTP 要慢一些，因为 HTTPS 为了保证安全要做一些额外的工作。但这些情况已经是过去式了，现在已经有了很多行之有效的 HTTPS 优化手段，运用得好可以把连接的额外耗时降低到几十毫秒甚至是零，比如：硬件优化、软件优化、协议优化、证书优化、会话复用、预共享密钥等等。
HTTP 与 HTTPS 有哪些区别？
HTTP 是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS 则解决 HTTP 不安全的缺陷，在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输。HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。HTTP 的端口号是 80，HTTPS 的端口号是 443。HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。
