HTTP 和 HTTPS 协议原理

友情链接：HTTP 协议【网络基础/应用层】

1. HTTP 的优点

  • 简单：HTTP 是一种文本协议，易于理解和实现。HTTP 的请求和响应都由起始行、首部字段和可选的消息主体组成，每个部分都有明确的语法规则。HTTP 的方法、状态码和首部字段都有标准化的定义，方便开发者遵循。
  • 灵活：HTTP 是一种无状态协议，即每个请求和响应都是独立的，不依赖于之前或之后的交互。这使得 HTTP 可以支持多种类型的资源，如 HTML、图片、视频、音频等，也可以支持多种类型的客户端，如浏览器、手机、物联网设备等。HTTP 还可以通过扩展首部字段或使用其他协议（如 HTTPS、WebSocket）来增加新的功能或安全性。
  • 通用：HTTP 是一种广泛使用的协议，几乎所有的网站和应用都基于 HTTP 进行通信。HTTP 也是一种开放的协议，任何人都可以参与其发展和改进。HTTP 的标准由 IETF（互联网工程任务组）和 W3C（万维网联盟）制定和维护，经过了多年的演进和更新，目前最新的版本是 HTTP/2。

2. HTTP 的缺点

HTTP 协议是无状态的，即每次请求都是独立的，服务器不会保存客户端的任何信息。HTTP 协议也是明文的，即请求和响应的内容都是未加密的，任何人都可以在网络上截获并查看。

这样就导致了 HTTP 协议的几个缺点：

  • 通信使用明文（不加密），内容可能会被窃听：由于数据是明文传输的，任何人都可以知道用户访问了哪些网站，浏览了哪些内容，甚至分析出用户的喜好、习惯等个人信息，这些信息可能被用于商业利益或其他目的，侵犯了用户的隐私权。
  • 不验证通信方的身份，因此有可能遭遇伪装：由于服务器不会保存客户端的状态，客户端每次请求都需要提供身份信息，如 Cookie 或 Session，这些信息也可能被攻击者截获或伪造，导致身份认证失败或被冒充。
  • 无法证明报文的完整性，所以有可能已遭篡改：由于数据是明文传输的，攻击者可以轻易地获取用户的敏感信息，如账号、密码、银行卡号等，或者篡改数据内容，造成用户或网站的损失。

除此之外， HTTP 还有效率低下这一大问题： HTTP 是一种基于文本的协议，虽然易于理解和实现，但也带来了一些效率方面的问题。例如，HTTP 的首部字段往往包含了大量的冗余信息，增加了数据传输的负担；HTTP 的请求和响应往往需要遵循严格的顺序，导致了队头阻塞（head-of-line blocking）问题；HTTP 的消息主体往往没有进行压缩或二进制编码，导致了数据量过大或解析速度过慢等问题。这些问题在 HTTP/2 中使用了首部压缩（header compression）、流优先级（stream priority）和二进制帧（binary frame）等技术得到了解决，提高了数据传输和处理的效率。

明文可能会被窃听

由于 HTTP 本身不具备加密的功能，所以也无法做到对通信整体（使用 HTTP 协议通信的请求和响应的内容）进行加密。即，HTTP 报文使用明文（指未经过加密的报文）方式发送。

所谓互联网，是由能连通到全世界的网络组成的。无论世界哪个角落的服务器在和客户端通信时，在此通信线路上的某些网络设备、光缆、计算机等都不可能是个人的私有物，所以不排除某个环节中会遭到恶意窥视行为。 即使已经过加密处理的通信，也会被窥视到通信内容，这点和未加密的通信是相同的。只是说如果通信经过加密，就有可能让人无法破解报文信息的含义，但加密处理后的报文信息本身还是会被看到的。

例如使用抓包工具就能很方便地获取包含在 HTTP 请求和响应报文中的用户隐私信息，例如：

image.png image.png

通信方可能被伪装

HTTP 协议中的请求和响应不会对通信方进行确认。HTTP 协议对请求者来之不拒，任何人都可以发起请求，只要服务端接收到请求不论对方是谁都会返回一个响应（前提是对方不在黑名单中）。

HTTP 协议的实现本身非常简单，因此不确认通信方，会存在以下各种隐患：

  • 无法确定请求发送至目标的 Web 服务器是否是按真实意图返回响应的那台服务器。有可能是已伪装的 Web 服务器。
  • 无法确定响应返回到的客户端是否是按真实意图接收响应的那个客户端。有可能是已伪装的客户端。
  • 无法确定正在通信的对方是否具备访问权限。因为某些 Web 服务器上保存着重要的信息，只想发给特定用户通信的权限。
  • 无法判定请求是来自何方、出自谁手。
  • 即使是无意义的请求也会照单全收。无法阻止海量请求下的 DoS 攻击（Denial of Service，拒绝服务攻击）。

报文可能被篡改

作为一个通信协议，保证通信报文的完整性是基本要求（总是丢件的邮局会倒闭的很快），所谓“完整性”指的是信息的准确性，也就是接收者接收到报文时，要和发出者发出时完全一致，否则报文可能就是被篡改了（排除其他客观原因）。

HTTP 协议无法证明通信报文的完整性，因此，在请求或响应送出之后直到对方接收之前的这段时间内，即使请求或响应的内容遭到篡改，也没有办法获悉。所谓“无法证明”，是因为报文的发出者只管发出报文，而接收方只管接收报文，因此不论是报文的接收方还是发出方，都无法知晓报文最终或最初是什么样的。

Image00139.jpg

比如，从某个 Web 网站上下载内容，是无法确定客户端下载的文件和服务器上存放的文件是否前后一致的。文件内容在传输途中可能已经被篡改为其他的内容。即使内容真的已改变，作为接收方的客户端和作为发出方的服务端都是觉察不到的。

像这样，请求或响应在传输途中，遭攻击者拦截并篡改内容的攻击称为中间人攻击（Man-in-the-Middle attack，MITM）。

Image00140.jpg

2.1 弥补 HTTP 的缺点（概述）

加密明文

要防止数据被窃听，就要进行加密处理。加密的对象可以是：

  • 通信
  • 内容
通信加密

HTTP 协议中没有加密机制，但可以通过和 SSL（Secure Socket Layer，安全套接层）或 TLS（Transport Layer Security，安全层传输协议）的组合使用，加密 HTTP 的通信内容。

用 SSL 建立安全通信线路之后，就可以在这条线路上进行 HTTP 通信了。与 SSL 组合使用的 HTTP 被称为 HTTPS（HTTP Secure，超文本传输安全协议）或 HTTP over SSL。

内容加密

由于 HTTP 协议中没有加密机制，那么就对 HTTP 协议传输的内容本身加密。即把 HTTP 报文里所含的内容进行加密处理。

在这种情况下，客户端需要对 HTTP 报文进行加密处理后再发送请求。

Image00136.jpg

诚然，为了做到有效的内容加密，前提是要求客户端和服务器同时具备加密和解密机制。主要应用在 Web 服务中。有一点必须引起注意，由于该方式不同于 SSL 或 TLS 将整个通信线路加密处理，所以内容仍有被篡改的风险。

验证通信方

HTTP 协议对请求来之不拒，那么过滤掉不合理的请求就显得十分必要了，这可以通过验证请求者的证书来做到。虽然使用 HTTP 协议无法确定通信方，但如果使用 SSL 则可以。SSL 不仅提供加密处理，而且还使用了一种被称为证书的手段，可用于确定方。

证书由值得信任的第三方机构颁发，用以证明服务器和客户端是实际存在的。另外，伪造证书从技术角度来说是异常困难的一件事。所以只要能够确认通信方（服务器或客户端）持有的证书，即可判断通信方的真实意图。

Image00138.jpg

通过使用证书，以证明通信方就是意料中的服务器。这对使用者个人来讲，也减少了个人信息泄露的危险性。证书就像政府颁发的说明一样，具有权威性，前提是这个机构是绝对权威的。通俗地说，服务器或客户端想要获取证书，都是要法人“实名制”的。在网络上只要实名制，人们就会听话很多：)。

报文完整性校验

在计算机中，任意一个文件都能通过某种哈希算法得到它的哈希值，HTTPS 使用的就是这种方法，即服务端和客户端都会验证报文发出前和接收后的哈希值，只要保证了哈希算法的正确性，就能校验报文发送前与接收后的哈希值来间接校验报文的完整性。

不同算法有各自的特点，在网络通信中的适用程度也不同，这部分将在后续介绍。

3. HTTPS 协议

HTTPS 并不是一种全新的应用层协议，而是 HTTP 的安全版本（HTTP Secure），上文已经介绍了 HTTPS 是从哪几方面弥补 HTTP 的缺点，下面将对这三个手段展开叙述。

HTTP + 加密 + 认证 + 完整性校验 = HTTPS：

Image00142.jpg

为了体系地认识 HTTPS 协议，首先介绍以下内容的框架：

  1. 上文介绍了 HTTP 的三大缺点，以及解决问题的切入点。而 SSL/TLS 协议就是解决这三大问题的而设计的。
  2. 简要介绍 SSL/TLS 协议是什么，然后介绍 SSL/TLS 协议的基本加密思想（暂不涉及具体算法）。注意：HTTPS 因为 SSL/TLS 协议才具有了安全性。
  3. [重点 （是理解第 4 点的前提）] 介绍 SSL/TLS 协议的加密流程。
  4. [重点] 结合第 3 点总结 HTTPS 的通信过程。

3.1 SSL/TLS 协议概述

  • SSL（安全套接层）是一种安全协议，最初由网景公司（Netscape）开发，用于在客户端和服务器端之间建立加密的通信通道。SSL 有 1.0，2.0 和 3.0 三个版本，但只有 3.0 版本被广泛使用。
  • TLS（传输层安全）是一种安全协议，基于 SSL 3.0 版本设计，由 IETF（互联网工程任务组）标准化，并发布了 1.0，1.1，1.2 和 1.3 四个版本。TLS 可以看作是 SSL 的后续版本（但并不意味着 SSL 被完全废除），也是目前最常用的安全协议。

TLS 协议是 SSL 协议的后续版本，有更高的安全性和更好的兼容性。TLS 支持更多的加密算法和扩展功能，并且可以降级到 SSL 版本来适应不同的场景。因此在不涉及具体细节的情况下（事实上它们通信的过程基本相同），SSL/TLS 协议和 TLS 协议是等价的。

通常，HTTP 运行在 TCP 之上，它直接和 TCP 通信。当使用 SSL 时，则演变成先和 SSL 通信，再由 SSL 和 TCP 通信了。简言之，所谓 HTTPS，其实就是身披 SSL 协议这层外壳的 HTTP。

Image00144.jpg

在采用 SSL/TLS 后，HTTP 就拥有了 HTTPS 的加密、证书和完整性保护这些功能。

3.2 加密机制

SSL 采用一种叫做公开密钥（yuè）加密（Public-key cryptography）的加密处理方式。近代的加密方法中加密算法是公开的，而密钥却是保密的。通过这种方式得以保持加密方法的安全性。

加密和解密都会用到密钥。没有密钥就无法对密码解密，反过来说，任何人只要持有密钥就能解密了。如果密钥被攻击者获得，那加密也就失去了意义。

对称加密

加密和解密同用一个密钥的方式称为共享密钥加密（Common key crypto system），也被叫做对称密钥加密。

Image00145.jpg

以共享密钥方式加密时必须将密钥也发给对方。可问题是究竟怎样才能安全地转交？在互联网上转发密钥时，密钥本身也是报文的一部分，如果通信被监听那么密钥就可会落入攻击者之手，同时也就失去了加密的意义。另外还得设法安全地保管接收到的密钥。

Image00146.jpg
  • 优点：
    • 加密速度快，适合对大量数据进行加密。例如，在文件压缩软件中，用户可以设置一个密码来对压缩文件进行加密，这样就可以防止其他人随意打开或修改文件。
  • 缺点：
    • 双方都必须事先约定好加密规则。密钥的数目难于管理。因为对于每一个合作者都需要使用不同的密钥，很难适应开放互联网中的大量的合作者交流。无法适用于陌生的网络的环境，双方都必须是可信任的才可进行。
    • 密钥的管理和分发比较困难，如果密钥在传输过程中被窃取或泄露，那么加密数据就会被破解。例如，在无线网络中，如果攻击者能够截获网络中传输的对称密钥，那么他就可以解密网络中的所有数据。

对称加密最大的问题在于加密的前提是通信方都知晓加密规则，但事实上在网络上的服务器和客户端很难做到这一点，就好像我们每次出门都会遇到不同的人，想要在通信之前将加密规则告知对方，这本身就是一种未经加密的通信，显然对称加密在原理上合理，但不可取。

非对称加密

公开密钥加密使用一对非对称的密钥。一把叫做私有密钥（private key），另一把叫做公开密钥（public key）。顾名思义，私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得。

使用公开密钥加密方式，发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走。

另外，要想根据密文和公开密钥，恢复到信息原文是异常困难的，因为解密过程就是在对离散对数进行求值，这并非轻而易举就能办到。因此以现在的技术从成本上可以认为这些哈希算法都是不可逆的。

Image00147.jpg
  • 优点：
    • 可以避免密钥的传输和泄露问题，提高了安全性。例如，在电子邮件中，用户可以使用收件人的公钥来对邮件内容进行加密，然后发送给收件人，收件人再使用自己的私钥来解密邮件内容，这样就可以保证邮件内容只有收件人能够看到。
  • 缺点：
    • 加密速度慢，不适合对大量数据进行加密。常见的非对称加密算法有 RSA、ECC 等。

混合加密

对称加密和非对称加密通常可以结合使用，以发挥各自的优势。在上面的介绍中我们知道公钥加密的缺点是计算量大，即使采用混合加密，也要尽可能以更小的服务器资源占用来保证同等的安全性。对此，SSL/TLS 协议的解决办法是：

  • 每一次对话（session），客户端和服务器端都生成一个"对话密钥"（session key），用它来加密信息。由于"对话密钥"是对称加密，所以运算速度非常快，而服务器公钥只用于加密"对话密钥"本身，这样就减少了加密运算的消耗时间。
  • 加密过程：客户端和服务器之间首先使用非对称加密来交换一个随机生成的对称密钥，然后使用这个对称密钥来进行后续的数据传输。这样既保证了数据传输的效率，又保证了数据传输的安全性。

HTTPS 充分利用两者各自的优势，将多种方法组合起来用于通信。在交换密钥环节使用公开密钥加密方式，之后的建立通信交换报文阶段则使用共享密钥加密方式。

Image00148.jpg

总结：

  • SSL/TLS 协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。

加密机制的安全性可以用算法保证，但问题在于公开密钥加密方式还是存在一些问题的。那就是无法证明公开密钥本身就是货真价实的公开密钥。比如，正准备和某台服务器建立公开密钥加密方式下的通信时，如何证明收到的公开密钥就是原本预想的那台服务器发行的公开密钥。或许在公开密钥传输途中，真正的公开密钥已经被攻击者替换掉了。

这就需要证明公开密钥正确性的证书来帮忙了。

3.3 数字签名与数字证书

由数字证书认证机构（CA，Certificate Authority）和其相关机关颁发的公开密钥证书可以证明公开密钥正确性。证书是数字签名的技术基础保障，也是网上实体身份的证明，能够证明某一实体的身份及其公钥的合法性，证明该实体与公钥二者之间的匹配关系。

数字证书认证机构处于客户端与服务器双方都可信赖的第三方机构的立场上。数字证书认证机构的业务流程是：

  1. 首先，服务器的运营人员向数字证书认证机构提出公开密钥的申请。
  2. 数字证书认证机构在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公钥证书后绑定在一起。

服务器会将这份由数字证书认证机构颁发的公钥证书发送给客户端，以进行公开密钥加密方式通信。公钥证书也可叫做数字证书或直接称为证书。

接到证书的客户端可使用数字证书认证机构的公开密钥，对那张证书上的数字签名进行验证，一旦验证通过，客户端便可明确两件事：一，认证服务器的公开密钥的是真实有效的数字证书认证机构。二，服务器的公开密钥是值得信赖的。

此处认证机关的公开密钥必须安全地转交给客户端。使用通信方式时，如何安全转交是一件很困难的事。 这个问题类似对称加密，让我们回到通信协议（Protocol）加密的本质：通信方按照实现约定的规则通信，那么前提是通信方在通信之前就已经知晓了规则。好在这些公钥都可以内置在浏览器中，相当于客户端默认具备了通信的前提。

  • 多数浏览器开发商发布版本时，会事先在内部植入常用认证机关的公开密钥。 image.png

例如可以在浏览器查看某个网站的证书（一般通过 HTTPS 通信时，网址框旁边会有一个🔐的标志）：

image.png

证书的一个作用是证明作为通信一方的服务器是否规范（证明公开密钥正确性），除此之外：

  • 证书可以确认对方服务器背后运营的企业是否真实存在。
  • 证书可以证明服务器正在通信的对方始终是预料之内的客户端，其作用跟服务器证书如出一辙。

数字签名和数字证书的关系可以简单地概括为：

  • 数字签名是使用数字证书与信息加密技术、用于鉴别电子数据信息的技术，可通俗理解为加盖在电子文件上的“数字指纹”。
  • 数字证书是由权威公证的第三方认证机构（即 CA，Certificate Authority）负责签发和管理的、个人或企业的网络数字身份证明。
  • 数字签名是用数字证书对电子文件签名后在电子文件上保留的签署结果，用以证明签署人的签署意愿。
  • 数字证书是数字签名的基础，数字签名是数字证书的一种应用结果。

阮一峰：数字签名是什么？

3.4 HTTPS 的通信过程

HTTPS 因 SSL/TLS 协议而具有了安全性，在了解 HTTPS 通信过程之前，首先要了解 SSL/TLS 协议的通信过程。

SSL/TLS 通信过程

SSL/TLS 协议的基本过程：

  1. 握手阶段（Handshake）：
    1. 客户端向服务器端索要并验证公钥。
    2. 双方协商生成"对话密钥"。
  2. 双方采用"对话密钥"进行加密通信。

值得注意的是，握手阶段以明文通信。

握手阶段

下面介绍"握手阶段"的具体过程：

image.png

RSA 加密算法是一种非对称加密算法，在公开密钥加密和电子商业中被广泛使用。RSA 是由 Ron Rivest、Adi Shamir 和 Leonard Adleman 一起提出的。

在 HTTPS 协议中，包括 4 次 TLS 握手。

客户端发出请求（ClientHello）

首先，客户端（通常是浏览器）先向服务器发出加密通信的请求，称之为 ClientHello 请求。

客户端请求主要向服务器提供以下信息：

  • 支持的协议版本，比如 TLS 1.0 版。
  • 一个客户端生成的随机数 Client Random，稍后用于生成"对话密钥"。
  • 支持的加密方法，比如 RSA 公钥加密。
  • 支持的压缩方法。

这里需要注意的是，客户端发送的信息中不包括服务器的域名。也就是说，理论上服务器只能包含一个网站，否则会分不清应该向客户端提供哪一个网站的数字证书。这就是通常一台服务器只能有一张数字证书的原因。

诸如 “ClientHello” 这样的字符串是一种握手消息，它映射了客户端与服务器之间通信之前的准备步骤。

服务器响应（SeverHello）

服务器收到客户端请求后，向客户端发出回应，称之为 SeverHello 响应。

服务器响应主要包含以下内容：

  • 确认使用的加密通信协议版本，比如 TLS 1.0 版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
  • 一个服务器生成的随机数 Server Random，稍后用于生成"对话密钥"。
  • 从客户端支持的加密算法中选择一种双方都支持的加密算法，比如 RSA 公钥加密。用于后面的会话密钥生成。
  • 服务器证书。
客户端回应

客户端收到服务器回应以后，首先使用 CA 的公钥验证服务器证书。如果解密失败，说明证书不符合要求，会向用户显示警告，但访问与否取决于用户。

客户端回应包含以下内容：

  • 一个随机数。该随机数 Pre-master Secret 用服务器公钥加密，防止被窃听。
  • 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
  • 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的 hash 值，用来供服务器校验（即摘要校验）。

摘要：通信协议中的摘要是一种用于验证数据完整性和身份认证的技术，通常由单向散列函数（如 MD5，SHA-1 等）生成。对数据进行摘要，就是用哈希算法对数据求哈希值。

需要注意的是，客户端和服务器通过两次单向的会话，使得它们都同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的"会话密钥"（Master Secret）。

从效果上看，这三个随机数通过算法形成了一个很"随机"的随机数，即"会话密钥"。“随机性"是先进的加密算法不可或缺的一部分，更是保证后续通信时数据安全性的保障。

要用三个随机数来生成"会话密钥"的原因是：

增加安全性和随机性。如果只用一个或两个随机数，那么会话密钥就可能被猜测或重复，导致通信被窃听或篡改。使用三个随机数，可以保证会话密钥的生成过程是双方共同参与的，而且每次通信都会产生不同的会话密钥，从而提高了保密性和完整性。一个伪随机可能完全不随机，可是三个伪随机就十分接近随机了。

服务器最后的回应

服务器生成本次会话所用的"会话密钥"后，向客户端最后发送下面信息：

  1. 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
  2. 服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的 hash 值，用来供客户端校验。

至此，SSL/TLS 协议的握手阶段结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的 HTTP 协议，只不过用"会话密钥"加密内容。

HTTPS 通信过程

HTTPS 协议通信的过程大部分是 SSL/TLS 协议通信的过程。

  • 客户端向服务器发起 HTTPS 请求，即通过 URL 中的 https:// 来指定使用 SSL/TLS 协议。
  • 服务器收到请求后，会返回一个 SSL/TLS 证书给客户端。证书中包含了服务器的公钥、证书颁发机构（CA）的信息、证书有效期等。
  • 客户端收到证书后，会验证证书的合法性，如证书是否过期、是否被篡改、是否由可信任的 CA 颁发等。如果验证通过，客户端会生成一个随机数作为对称加密的密钥，并用服务器的公钥加密后发送给服务器；如果验证失败，客户端会给出警告信息，用户可以选择继续或中断访问。
  • 服务器收到客户端发送的密文后，用自己的私钥解密，得到对称加密的密钥。至此，客户端和服务器之间就建立了一个对称加密的通道。
  • 客户端和服务器之后就可以通过这个对称加密的通道来传输数据，数据在发送前会用对称加密的密钥进行加密，接收后再进行解密，保证了数据的安全性。

下面是一个 HTTPS 通信的例子：

image.png
  1. 客户端向服务端发起请求：
    • 客户端通过发送 Client Hello 报文开始 SSL/TLS 通信。报文中包含客户端支持的 SSL 的指定版本、加密组件（Cipher Suite）列表（所使用的加密算法及密钥长度等）。
  2. 服务器向客户端发送数字证书和响应报文：
    • 服务器可进行 SSL/TLS 通信时，会以 Server Hello 报文作为应答。和客户端一样，在报文中包含 SSL/TLS 版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。
    • 之后服务器发送 Certificate 报文。报文中包含公开密钥证书。
    • 最后服务器发送 Server Hello Done 报文通知客户端，最初阶段的 SSL/TLS 握手协商部分结束。
  3. 客户端验证数字证书：
    • SSL/TLS 第一次握手结束之后，客户端以 Client Key Exchange 报文作为回应。报文中包含通信加密中使用的一种被称为 Pre-master secret 的随机密码串。该报文已用第二步中的公开密钥进行加密。
    • 接着客户端继续发送 Change Cipher Spec 报文。该报文会提示服务器，在此报文之后的通信会采用 Pre-master secret 密钥加密。
  4. 服务器得到会话密钥：
    • 客户端发送 Finished 报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。
    • 服务器同样发送 Change Cipher Spec 报文。
    • 服务器同样发送 Finished 报文。
    • 服务器和客户端的 Finished 报文交换完毕之后，SSL/TLS 连接就算建立完成。当然，通信会受到 SSL/TLS 的保护。
  5. 客户端与服务端进行加密会话：
  • 从此处开始进行应用层协议的通信，即发送 HTTP 请求。
  • 应用层协议通信，即发送 HTTP 响应。
  1. 最后由客户端断开连接。

值得注意的是，「Change Cipher Spec」之前传输的 TLS 握手数据都是明文，之后都是对称密钥加密的密文。

可见，就通信过程而言，HTTPS = HTTP + SSL/TLS（S）。

HTTPS 的优缺点

优点

  • 可以对数据进行加密和身份验证，保护用户的隐私和安全。
  • 可以防止中间人攻击，避免数据被窃听或篡改。
  • 可以提高网站的信誉和排名，增加用户的信任和访问量。
  • 可以支持更多的功能和扩展，如 HTTP/2，WebRTC，Service 等。

缺点

  • 需要购买和维护数字证书，增加网站的成本和复杂度。
  • 需要消耗更多的服务器资源和网络带宽，降低网站的性能和速度。
  • 需要适配不同的浏览器和操作系统，解决兼容性和更新问题。
  • 可能影响一些缓存和优化策略，如 CDN，SPDY 等。

其中，对于服务器而言最大的缺点就是效率问题，HTTPS 比 HTTP 要慢 2 到 100 倍。“慢"分两种：

  • 通信慢。
  • 由于大量消耗 CPU 及内存等资源，导致处理速度变慢。

除去和 TCP 连接、发送 HTTP 请求 • 响应以外，还必须进行 SSL 通信，因此整体上处理通信量不可避免会增加。

另一点是 SSL 必须进行加密处理。在服务器和客户端都需要进行加密和解密的运算处理。因此从结果上讲，比起 HTTP 会更多地消耗服务器和客户端的硬件资源，导致负载增强。

这个问题没有根本性解决方案，毕竟目前还没有一个以更低成本实现的安全通信协议，通常情况下，如果是非敏感信息则使用 HTTP 通信，只有在包含个人信息等敏感数据时，才利用 HTTPS 加密通信。

因此有时我们访问一些网站时（尤其是用爱发电的个人网站），浏览器经常会告警，毕竟证书一年要几百元。

参考资料

  • 《图解 HTTP》 本文中的许多插图和概念阐述都引用于本书，一图胜千言，十分推荐初学者学习，可以使用工具 calibre 阅读。
  • 小林 coding：HTTPS RSA 握手解析 在学习过程中发现的宝藏博客，图文并茂，知识维度也很广，十分推荐。在最后一小节中的两图都引用自此博客。