通常在进行网络通信时，我们除了希望这个过程快速以外，安全问题也是我们首要考虑的.在传输一些敏感数据的时候，我们并不希望在通信的过程中被泄露。但是 HTTP 作为互联网通信协议，天生具有“明文”的特点，整个传输过程完全透明，任何人都能在链路中截获、修改或者伪造请求/响应报文，数据具有不可靠性。

这对于网络购物、网上银行、证券交易等需要高度信任的应用场景来说是非常致命的。对于安全性要求不那么高的新闻、视频、搜索等网站来说，由于互联网上的恶意用户、恶意代理越来越多，也很容易遭到“流量劫持”的攻击，在页面里强行嵌入广告，或者分流用户，导致各种利益损失。此外，对于普通用户的个人信息、密码等敏感信息被窃取，可能会威胁人身和财产安全。所以，通信的安全性至关重要！

那么怎么样才算得上是安全的互联网通信呢？

• 机密性（Secrecy/Confidentiality）：指对数据的“保密”，只能由可信的人访问，对其他人是不可见的“秘密”，简单来说就是不能让不相关的人看到不该看的东西。
• 完整性（Integrity）：是指数据在传输过程中没有被窜改，不多也不少，“完完整整”地保持着原状。
• 身份认证（Authentication）：指确认对方的真实身份，也就是“证明你真的是你”，保证消息只能发送给可信的人。
• 不可否认（Non-repudiation/Undeniable）：不能否认已经发生过的行为，不能“说话不算数”“耍赖皮”。 只有同时具有机密性、完整性、身份认证、不可否认这四个特性，才能保证传输的过程是安全的。

一、什么是 HTTPS

HTTPS（Hypertext Transfer Protocol Secure， 安全超文本传输协议） 是一种互联网通信协议，可保护用户计算机与网站之间传输的数据的完整性和机密性。在 HTTPS 中，通信协议使用 TLS（Transport Layer Security）或之前的 SSL(Secure Socket Layer) 进行加密，所以该协议也被称为 HTTP over TLS 或 HTTP over SSL。

HTTPS 并不是独立于 HTTP 协议的，而是在 HTTP 与 TCP 层之间加⼊了 SSL/TLS 协议，使其满足上述安全特性。通常也称：HTTPS 是 HTTP 协议的安全版本

HTTPS 由 RFC 2818  （2000 年 5 月）指定，默认使用端口 443 ，URL 以 https:// 开头（即：协议名改为 https）

HTTPS 在保护处理或传输敏感数据的网站方面发挥着重要作用，包括由在线银行服务、电子邮件提供商、在线零售商、医疗保健提供商等处理的数据。简而言之，任何需要登录凭证或涉及金融交易的网站都应使用 HTTPS 来确保用户、交易和数据的安全。

为什么会出现 HTTPS

虽然 HTTP 在很多方面已经表现得很优秀了，但是仍存在以下缺点：

• 通信使用明文（未加密），内容可能会被窃听 为什么说 HTTP 中明文传输是个缺点，是因为 HTTP 基于 TCP/IP 协议，按 TCP/IP 协议族的工作机制，通信内容在所有的通信线路上都有可能遭到窥视。通信线路上的某些网络设备、光缆、计算机等都不可能是个人的私有物，所以不排除某个环节遭到恶意窥视行为。

即使经过加密处理的通信，仍是会被窥视到通信内容的。只是通信如果经过加密，窥视者可能就无法破解报文信息的含义。

• 无法证明报文的完整性，可能已遭篡改 由于 HTTP 协议无法保证通信的报文完整性，因此，在请求或响应发出之后直到对方接收之前这段时间内，即使请求或响应的内容遭到篡改，也没有办法获知，导致接收的内容可能有误。

简单来说，就 HTTP 协议无法保证服务器接收到的请求和客户端发送的请求一致，也无法保证客户端接收到的响应于服务器发送的响应一致。所以有时候也称完整性为一致性。

例如，从某个网站上下载内容，HTTP 协议无法保证客户端下载的文件和服务器上存放的文件一致。文件内容在传输的过程中可能会被篡改成其他内容，即使内容发生改变，客户端也无所察觉。像这样在请求或响应传输途中，遭到攻击者拦截并篡改内容的攻击称为中间人攻击（Man-in-the-Middle attack，MITM）。

• 不验证通信双方的身份，可能会遭遇伪装 HTTP 协议中的请求和响应不会对通信方进行确认。任何人都可以发起请求，服务器只要接收到请求，不管对方是谁都会返回一个响应（没有被同源策略限制的情况下）。不确认通信方，可能会存在以下隐患：
• 无法确定请求发送至目标的 Web 服务器是否是按真实意图返回响应的那台服务器。可能是已经伪装的 Web 服务器。
• 无法确定响应返回到的客户端是否是按真实意图接收响应的那个客户端。可能是已经伪装的客户端。
• 无法确定正在通信的对方是否具备访问权限。因为某些 Web 服务器上保存着重要的信息，只想发给特定的客户端。
• 无法判断请求是来自何方
• 即使是无意义的请求也会全部接收。无法阻止海量请求下的 DoS 攻击（Denial of Service，拒绝服务攻击）

针对于上述 HTTP 存在的缺点，HTTPS 为 HTTP 协议添加了加密、数据完整性 和 身份验证

1. 加密 - 对所交换的数据进行加密，使其免受窥探。这意味着，当用户浏览某个网站时，没有人能够“窥听”其会话内容，也无法跟踪其在多个网页上的活动，或窃取其信息。
2. 数据完整性 - 只要数据在传输期间被修改或损坏（无论有意或无意），都会被检测出来。
3. 身份验证 - 证明用户是在与目标网站进行通信，从而保护用户免遭中间人攻击并建立用户信任，进而带来其他商业效益。

二、HTTPS 如何解决 HTTP 中的隐患

2.1 混合加密机制 —— 解决明文传输问题

（1）共享密钥加密

对称加密 也称共享密钥加密，指在加密和解密时使用相同的密钥，或是使用两个可以简单地相互推算的密钥。在大多数的对称算法中，加密密钥和解密密钥是相同的。它要求发送方和接收方在安全通信之前，商定一个密钥。对称算法的安全性依赖于密钥，泄漏密钥就意味着任何人都可以对他们发送或接收的消息解密，所以密钥的保密性对通信的安全性至关重要。要求双方获取相同的密钥是对称密钥加密的主要缺点之一。

（2）非对称加密

非对称加密 也成公开密钥加密，它需要两个密钥，一个是公开密钥，另一个是私有密钥；公钥用作加密，私钥则用作解密。使用公钥把明文加密后所得的密文，只能用相对应的私钥才能解密并得到原本的明文，最初用来加密的公钥不能用作解密。由于加密和解密需要两个不同的密钥，故被称为非对称加密。

公钥可以公开，可任意向外发布；私钥不可以公开，必须由用户自行严格秘密保管，绝不透过任何途径向任何人提供，也不会透露给被信任的要通信的另一方。

虽然非对称加密解决了“密钥交换”的问题，但因为它们都是基于复杂的数学难题，运算速度很慢

（3）混合加密

HTTPS 采用 对称加密 和 非对称加密 结合的混合加密方式：

• 在通信建立前采用 非对称加密 的方式交换 会话密钥， 后续不再使用非对称加密。
• 在通信过程中全部使用 对称加密 的方式加密明文数据

在通信刚开始的时候使用非对称算法，比如 RSA、ECDHE，首先解决密钥交换的问题。（注意：这里非对称加密的对象是会话密钥）然后用随机数产生对称算法使用的“会话密钥”（session key），再用公钥加密。因为会话密钥很短，通常只有 16 字节或 32 字节，所以慢一点也无所谓。对方拿到密文后用私钥解密，取出会话密钥。这样，双方就实现了对称密钥的安全交换，后续就不再使用非对称加密，全都使用对称加密。

即：使用非对称加密方式加密对称加密的密钥，使用对称加密方式加密传输的明文数据。

2.2 摘要算法 —— 保证数据完整性

实现完整性的手段主要是摘要算法（Digest Algorithm），也就是常说的散列函数、哈希函数（Hash Function）。摘要算法能够为数据生成独一无二的指纹 ，用于校验数据的完整性， 即把任意长度的数据“压缩”成固定长度、而且独一无二的“摘要”字符串，就好像是给这段数据生成了一个数字“指纹”

目前常用的摘要算法是 SHA-2 ,SHA-2 实际上是一系列摘要算法的统称，总共有 6 种，常用的有 SHA224、SHA256、SHA384，分别能够生成 28 字节、32 字节、48 字节的摘要。

通常：

• 客户端在发送明⽂之前会通过摘要算法算出明⽂的「指纹」
• 发送的时候把「指纹 + 明⽂」⼀同加密成密⽂后，发送给服务器
• 服务器解密后，⽤相同的摘要算法算出发送过来的明⽂，通过⽐较客户端携带的「指纹」和当前算出的「指纹」做⽐较，若「指纹」相同，说明数据是完整的。

2.3 身份验证

加密算法保证了传输的机密性，摘要算法保证了数据的完整性，通信过程看起来似乎已经很安全了。但这只保证了传输的数据的安全性，并不能保证通信双方的正确性。例如，黑客可以伪装成网站窃取你的私人信息，也能伪装成你，向网站发送支付、转账等信息。解决这种问题的方法就是对通信双方进行身份验证。

（1）数字签名

数字签名与非对称加密相反，使用 私钥加密、公钥解密。但又因为非对称加密效率太低，所以私钥只加密原文的摘要，这样运算量就小的多，而且得到的数字签名也很小，方便保管和传输。

签名和公钥一样完全公开，任何人都可以获取。但这个签名只有用私钥对应的公钥才能解开，拿到摘要后，再比对原文验证完整性，就可以像签署文件一样证明消息确实是你发的。这两个行为也有专用术语，叫做 “签名” 和 “验签”。

只要你和网站互相交换公钥，就可以用“签名”和“验签”来确认消息的真实性，因为私钥保密，黑客不能伪造签名，就能够保证通信双方的身份。

例如，客户端要发送一个消息“你好”，首先使用摘要算法生成消息的摘要，然后使用私钥对摘要进行加密，得到数字签名，服务器收到后，先用客户端的公钥验签，确认身份（因为客户端的公钥只能解密客户端私钥加密的摘要），服务器确认身份正确后才会进行响应。

（2）数字证书 和 数字证书认证机构（CA）

使用非对称加密方式还存在一些问题，通常，客户端先向服务器端索要公钥，然后⽤公钥加密信息，服务器收到密⽂后，⽤⾃⼰的私钥解密。那么如何保证公钥不被篡改和信任度？可能在传输的过程中，真正的公钥已经被攻击者替换了。

这⾥可以借助第三⽅权威机构 CA （Certificate Authority, 数字证书认证机构）为服务器的公钥颁发数字证书。数字证书认证机构的业务流程通常如下：

• 服务器的运营人员向 CA 提出公钥的申请，CA 在判定申请者的身份后，回对已申请的公钥进行数字签名，然后分配这个已签名的公钥，并将该公钥放入数字证书后绑定在一起。
• 服务器将这份由 CA 颁发的 数字证书发送给客户端（这里必须安全发送给客户端）
• 收到证书的客户端可以使用 CA 的公开密钥，对数字证书上的数字签名进行验证，若验证通过说明服务器的公钥是值得信赖的

简而言之，就是 数字证书认证机构用自己的私钥对需要认证的人（或组织机构）的公钥施加数字签名并生成证书，数字证书的本质就是对公钥施加数字签名。

知名的 CA 全世界就那么几家，比如 DigiCert、VeriSign、Entrust、Let’s Encrypt 等，它们签发的证书分 DV、OV、EV 三种，区别在于可信程度。DV 是最低的，只是域名级别的可信，背后是谁不知道。EV 是最高的，经过了法律和审计的严格核查，可以证明网站拥有者的身份（在浏览器地址栏会显示出公司的名字，例如 Apple、GitHub 的网站）。

不过，CA 怎么证明自己呢？

这还是信任链的问题。小一点的 CA 可以让大 CA 签名认证，但链条的最后，也就是Root CA，就只能自己证明自己了，这个就叫“自签名证书”（Self-Signed Certificate）或者“根证书”（Root Certificate）。你必须相信，否则整个证书信任链就走不下去了。

（3）证书体系的弱点

如果 CA 失误或者被欺骗，签发了错误的证书，虽然证书是真的，可它代表的网站却是假的。

还有一种更危险的情况，CA 被黑客攻陷，或者 CA 有恶意，因为它（即根证书）是信任的源头，整个信任链里的所有证书也就都不可信了。

针对第一种，开发出了 CRL（证书吊销列表，Certificate revocation list）和 OCSP（在线证书状态协议，Online Certificate Status Protocol），及时废止有问题的证书。

对于第二种，因为涉及的证书太多，就只能操作系统或者浏览器从根上“下狠手”了，撤销对 CA 的信任，列入“黑名单”，这样它颁发的所有证书就都会被认为是不安全的

三、HTTPS 的安全通信机制

在 HTTP 协议中，客户端和服务器通过三次握手建立连接后，就可以开始发送请求和响应数据了。但是 HTTPS 协议中，在这两个步骤之间会多一次“握手”过程，在 TCP 上建立安全连接。

3.1 什么是 TLS 协议

TLS（Transport Layer Protocol，安全传输层协议） 及其前身 SSL（Secure Socket Layer，安全套接层） 是一种安全协议，用于在两个通信应用程序之间提供保密性和数据完整性。该协议由两层组成： TLS 记录协议（TLS Record） 和 TLS 握手协议（TLS Handshake）。较低的层为 TLS 记录协议，位于某个可靠的传输协议（例如 TCP）上面。

（1）TLS 记录协议（Record Protocol）：

TLS 记录协议提供的连接安全性具有两个基本特性：

• 私有 ―― 对称加密用以数据加密（DES 、RC4 等）。对称加密所产生的密钥对每个连接都是唯一的，且此密钥基于另一个协议（如握手协议）协商。记录协议也可以不加密使用。

• 可靠 ―― 信息传输包括使用密钥的 MAC 进行信息完整性检查。安全哈希功能（ SHA、MD5 等）用于 MAC 计算。记录协议在没有 MAC 的情况下也能操作，但一般只能用于这种模式，即有另一个协议正在使用记录协议传输协商安全参数。

TLS 记录协议用于封装各种高层协议。作为这种封装协议之一的握手协议允许服务器与客户机在应用程序协议传输和接收其第一个数据字节前彼此之间相互认证，协商加密算法和加密密钥。

（2）TLS 握手协议（Handshake Protocol）

TLS 握手协议提供的连接安全具有三个基本属性：

• 可以使用非对称的，或公共密钥的密码术来认证对等方的身份。该认证是可选的，但至少需要一个结点方。
• 共享加密密钥的协商是安全的。对偷窃者来说协商加密是难以获得的。此外经过认证过的连接不能获得加密，即使是进入连接中间的攻击者也不能。
• 协商是可靠的。没有经过通信方成员的检测，任何攻击者都不能修改通信协商。

SSL 是 TLS 的前身，因为在实验过程中 SSL 出现了问题，所以废弃了，后来 RFC 统一标准命名为 TLS。有关 SSL/TLS 的发展历程，这里暂时不赘述了。

3.2 HTTPS 通信步骤

SSL/TLS 协议基本流程：

• 客户端向服务器索要并验证服务器的公钥。
• 双⽅协商⽣产「会话秘钥」。
• 双⽅采⽤「会话秘钥」进行加密通信。

如上图， SSL/TLS 协议建立的详细流程为：

• 步骤1：TCP 连接建立之后，首先，客户端会向服务器发送 ClientHello 报文开始 SSL/TLS 通信，报文中包含：
  • 客户端支持的 SSL/TLS 协议版本
  • 客户端产生的随机数（Client Random），用于后续产生会话密钥
  • 客户端支持的密码套件列表，例如：RSA加密算法
• 步骤2：服务器接收到客户端的请求后，会向客户端响应 ServerHello 报文。服务器响应的内容如下：
  • 确认 SSL/TLS 协议版本，如果浏览器不支持，则关闭加密通信
  • 服务器产生的随机数（Server Random）
  • 确认密码套件列表
• 步骤3：之后服务器发送 Certificate 报文，报文中包含服务器的数字证书
• 步骤4：最后服务器发送 Server Hello Done 报文通知客户端最初阶段的 TLS 握手协商部分结束
• 步骤5：客户端接收到服务器的响应后，首先通过浏览器或者操作系统中的 CA 公钥，确认服务器数字证书的真实性，如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后用它加密报文，向服务器发送 Client Key Exchange 报文，报文中包含一个随机数（pre-master key），用于服务器公钥加密。（该报文已经使用服务器公钥加密）
• 步骤6：接着客户端会继续发送 Change Cipher Spec，该报文会告诉服务器在此之后的通信都采用会话密钥加密。（会话密钥：Client Random + Server Random + pre-master key）
• 步骤7：客户端发送 Finished 报文。该报文包含连接至今全部报文的整体校验值，这次握手协商是否能够成功，要以服务器是否能够正确解密该报文为判定标准
• 步骤8：服务器收到客户端的第三个随机数（ pre-master key ）之后，通过协商的加密算法，计算出本次通信的会话秘钥。然后向客户端发送 Change Cipher Spec 报文，表示后续通信都会使用会话密钥加密。
• 步骤9：服务器发送 Finished 报文。表示服务器的握手阶段已经结束，这一项同时把之前所有内容发生的数据做个摘要，用来供客户端校验。
• 步骤10：服务器和客户端的 Finished 报文交换完毕之后，TLS 连接建立完成。客户端和服务器进入加密通信。仍然是通过HTTP协议进行通信，但是通信内容使用会话密钥加密。

以上步骤中，客户端或服务器发送消息的时候会附加一种称为 MAC（Message Authentication Code） 的报文摘要。MAC 能够校验报文是否遭到篡改，从而保证数据完整性。

目前 TLS 已经发展到1.3版本，会与以上步骤有所不同。

四、HTTPS 存在的问题

HTTPS 最大的问题就是处理速度会变慢：

• 通信慢：因为 HTTPS 除了 TCP 连接、HTTP 请求/响应以外，还需要进行 TLS 通信，因此整体上处理的通信量不可避免会增加。
• 处理速度慢：HTTPS 中必须进行加密处理，在服务器和客户端都需要进行加密和解密的运算处理，因此比起 HTTP 会消耗更多服务器和客户端的硬件资源，导致负载增强。

对于 HTTPS 通信慢的问题可以从软件优化、硬件优化、协议优化、证书优化、会话复用等角度去考虑。

以上就是对 HTTPS 协议的一些简单介绍了。

参考
[1] 图解网络
[2] 《图解HTTP协议》
[3] 透视 HTTP 协议