• HTTP：HyperText Transfer Protocol 超文本传输协议

• HTTPS：Hypertext Transfer Protocol Secure 超文本传输安全协议

• TLS：位于 HTTP 和 TCP 之间的协议，其内部有 TLS 握手协议、TLS 记录协议

• HTTPS 经由 HTTP 进行通信，但利用 TLS 来保证安全，即 HTTPS = HTTP + TLS

HTTP和HTTPS的区别？

端口 ：HTTP 的 URL由“http://”起始且默认使用端口 80，而 HTTPS 的 URL 由“https://”起始且默认使用端口 443。

安全性和资源消耗： HTTP 协议运行在 TCP 之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS 是运行在 SSL/TLS 之上的 HTTP 协议，SSL/TLS 运行在 TCP 之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS 高 ，但是 HTTPS 比 HTTP 耗费更多服务器资源。

• 对称加密：密钥只有一个，加密解密为同一个密码，且加解密速度快，典型的对称加密算法有DES、AES等；

• 非对称加密：密钥成对出现（且根据公钥无法推知私钥，根据私钥也无法推知公钥），加密解密使用不同密钥（公钥加密需要私钥解密，私钥加密需要公钥解密），相对对称加密速度较慢，典型的非对称加密算法有RSA、DSA等。

HTTP的安全性问题

HTTP 有以下安全性问题：

• ①使用明文进行通信，内容可能会被窃听；

• ②不验证通信方的身份，通信方的身份有可能遭遇伪装；

• ③无法证明报文的完整性，报文有可能遭篡改。

HTTPS 并不是新协议，而是让 HTTP 先和 SSL（Secure Sockets Layer）通信，再由 SSL 和 TCP 通信，也就是说 HTTPS 使用了隧道进行通信。

通过使用 SSL，HTTPS 具有了加密（防窃听）、认证（防伪装）和完整性保护（防篡改）。

HTTP + 加密 + 认证 + 完整性保护 = HTTPS

以下看看 HTTPS 是如何解决加密、认证与完整性保护的问题。

加密

对称密钥加密

对称密钥加密（Symmetric-Key Encryption），加密和解密使用同一密钥。

• 优点：运算速度快；

• 缺点：无法安全地将密钥传输给通信方。

常用的对称加密算法：AES、3DES。

非对称密钥加密

非对称密钥加密，又称公开密钥加密（Public-Key Encryption），加密和解密使用不同的密钥。

非对称加密一般有两种密钥，公钥和私钥，公钥一般用于加密，私钥一般用于解密。

常用的非对称加密算法：RSA（安全基于大质数的分解难度）、ECC、SM2 等。

公开密钥所有人都可以获得，通信发送方获得接收方的公开密钥之后，就可以使用公开密钥进行加密，接收方收到通信内容后使用私有密钥解密。

非对称密钥除了用来加密，还可以用来进行签名。因为私有密钥无法被其他人获取，因此通信发送方使用其

私有密钥进行签名，通信接收方使用发送方的公开密钥对签名进行解密，就能判断这个签名是否正确。

• 优点：可以更安全地将公开密钥传输给通信发送方；

• 缺点：运算速度慢，消耗更多的资源。

HTTPS的加密方式

HTTPS 采用混合的加密机制，在交换密钥环节使用非对称加密（公开密钥）方式，之后建立通信交换报文阶段（普通数据）则使用对称加密（共享密钥加密）方式。

数据通信时需要用到一个对称加密的密钥，但是直接发过去是不安全的，所以使用非对称加密的方式将需要得对称加密密钥发送过去。

一个非常好懂的加密流程图。

上述的流程还差一步，就是服务器发送公钥给客户端的时候，也会一起发送 CA 数字签名给客户端用于认证。（下面详述）

使用自己的私钥对自己所认可的消息生成一个该消息专属的签名，这就是数字签名，表明我承认该消息来自自己。注意：私钥用于加签，公钥用于解签，每个人都可以解签，查看消息的归属人公钥密码也叫非对称密码，由公钥和私钥组成，它是最开始是为了解决秘钥的配送传输安全问题，即，我们不配送私钥，只配送公钥，私钥由本人保管。它与数字签名相反，公钥密码的私钥用于解密、公钥用于加密，每个人都可以用别人的公钥加密，但只有对应的私钥才能解开密文client：明文 + 公钥 = 密文server：密文 + 私钥 = 明文

注意：公钥用于加密，私钥用于解密，只有私钥的归属者，才能查看消息的真正内容

认证

当服务器接收到客户端发来的请求时，会向客户端发送服务器自己的公钥，但是黑客有可能中途篡改公钥，将其改成黑客自己的，所以有个问题，客户端怎么信赖这个公钥是自己想要访问的服务器的公钥而不是黑客的呢？所以客户端也需要对服务器发送过来的公钥认证其合法性。 这时候就需要用到数字证书。

通过使用 证书 来对通信方进行认证。

数字证书认证机构（CA，Certificate Authority）是客户端与服务器双方都可信赖的第三方机构。

如何认证？

① 首先阿里需要将自己的公钥发送给 CA 机构进行公钥申请，如果通过，则 CA 机构（CA 机构自己也有公钥和私钥）则利用其私钥对阿里的公钥进行非对称加密，这就是加密后的明文（数字签名）。加密完之后，得到的密文再加上证书的过期时间、颁发给、颁发者等信息，就组成了数字证书。（数字证书就是数字签名加上各种附加信息）

② 用户浏览器向阿里发起 HTTPS 连接请求，阿里会将其公钥 + 数字证书发送给客户端。

③ 客户端首先需要对接收到的公钥进行验证，以确保公钥是真实的且没有被人篡改。不论什么平台，设备的操作系统中都会内置 100 多个全球公认的 CA 的公钥。所以客户端使用 CA 机构的公钥对数字证书中的数字签名进行认证：

• 首先客户端会用设备中内置的 CA 的公钥尝试解密数字证书，如果所有内置的 CA 的公钥都无法解密该数字证书，说明该数字证书不是由一个全球知名的 CA 签发的，这样客户端就无法信任该服务器的数字证书。

• 如果有一个 CA 的公钥能够成功解密该数字证书，说明该数字证书就是由该 CA 的私钥签发的，因为被私钥加密的密文只能被与其成对的公钥解密。

• 除此之外，还需要检查客户端当前访问的服务器的域名是与数字证书中提供的“颁发给”这一项吻合，还要检查数字证书是否过期等。

只有通过认证之后才能继续后面的加密与通信步骤。

进行 HTTPS 通信时，服务器会把CA 证书发送给客户端。客户端取得其中的公开密钥之后，先使用数字签名进行验证，如果验证通过，就可以开始通信了。

下图很有趣！

证书：全称公钥证书（Public-Key Certificate, PKC）,里面保存着归属者的基本信息，以及证书过期时间、归属者的公钥，并由认证机构（Certification Authority, CA）施加数字签名，表明，某个认证机构认定该公钥的确属于此人。

想象这个场景：你想在支付宝页面交易，你需要支付宝的公钥进行加密通信，于是你从百度上搜索关键字“支付宝公钥”，你获得了支什宝的公钥，这个时候，支什宝通过中间人攻击，让你访问到了他们支什宝的页面，最后你在这个支什宝页面完美的使用了支什宝的公钥完成了与支什宝的交易。

在上面的场景中，你可以理解支付宝证书就是由支付宝的公钥、和给支付宝颁发证书的企业的数字签名组成。任何人都可以给自己或别人的公钥添加自己的数字签名，表明：我拿我的尊严担保，我的公钥/别人的公钥是真的，至于信不信那是另一回事了。

密码	作用	组成
消息认证码	确认消息的完整、并对消息的来源认证	共享秘钥+消息的散列值
数字签名	对消息的散列值签名	公钥+私钥+消息的散列值
公钥密码	解决秘钥的配送问题	公钥+私钥+消息
证书	解决公钥的归属问题	公钥密码中的公钥+数字签名

完整性保护

SSL 提供一种叫做 MAC 的报文摘要功能来进行完整性保护。

HTTP 也提供了 MD5 报文摘要功能，但不是安全的。例如报文内容被篡改之后，同时重新计算 MD5 的值，通信接收方是无法意识到发生了篡改。

HTTPS 的报文摘要功能之所以安全，是因为它结合了加密和认证这两个操作。试想一下，加密之后的报文，遭到篡改之后，也很难重新计算报文摘要，因为无法轻易获取明文。

HTTPS通信流程总结

服务器端的公钥和私钥，用来进行非对称加密。

客户端生成的随机密钥，用来进行对称加密。

一个 HTTPS 请求实际上包含了两次 HTTP 传输，可以细分为 8 步。

1.客户端向服务器发起 HTTPS 请求，连接到服务器的 443 端口。

2.服务器端有一个密钥对，即公钥和私钥，是用来进行非对称加密使用的，服务器端保存着私钥，不能将其泄露，公钥可以发送给任何人。

3.服务器将自己的公钥发送给客户端。

4.客户端收到服务器端的公钥之后，会对公钥进行检查，验证其合法性，如果发现发现公钥有问题，那么 HTTPS 传输就无法继续。严格的说，这里应该是验证服务器发送的数字证书的合法性，关于客户端如何验证数字证书的合法性，上文已经说明。如果公钥合格，那么客户端会生成一个随机值，这个随机值就是用于进行对称加密的密钥，我们将该密钥称之为 client key，即客户端密钥，这样在概念上和服务器端的密钥容易进行区分。然后用服务器的公钥对客户端密钥进行非对称加密，这样客户端密钥就变成密文了，至此，HTTPS 中的第一次 HTTP 请求结束。

5.客户端会发起 HTTPS 中的第二个 HTTP 请求，将加密之后的客户端密钥发送给服务器。

6.服务器接收到客户端发来的密文之后，会用自己的私钥对其进行非对称解密，解密之后的明文就是客户端密钥，然后用客户端密钥对数据进行对称加密，这样数据就变成了密文。

7.然后服务器将加密后的密文发送给客户端。

8.客户端收到服务器发送来的密文，用客户端密钥对其进行对称解密，得到服务器发送的数据。这样 HTTPS 中的第二个 HTTP 请求结束，整个 HTTPS 传输完成。

HTTPS的缺点

• 因为需要进行加密解密等过程，对 CPU 的额外开销较大，因此速度会更慢；

• 需要支付证书授权的高额费用。

SSL与TLS

概述

TLS/SSL是一种加密通道的规范。

• SSL：（Secure Socket Layer） 安全套接层，于 1994 年由网景公司设计，并于 1995 年发布了 3.0 版本。

• TLS：（Transport Layer Security）传输层安全性协议，是 IETF 在 SSL3.0 的基础上设计的协议。

故以下全部使用 TLS 来表示。TLS 是一系列密码工具的框架，作为框架，它也是非常的灵活，体现在每个工具套件它都可以替换，即：客户端与服务端之间协商密码套件，从而更难的被攻破，例如使用不同方式的对称密码，或者公钥密码、数字签名生成方式、单向散列函数技术的替换等。

在发送方，SSL 接收应用层的数据，对数据进行加密，然后把加了密的数据送往 TCP 套接字。在接收方，SSL 从 TCP 套接字读取数据，解密后把数据交给应用层。

TLS 1.0是IETF（Internet Engineering Task Force，Internet工程任务组）制定的一种新的协议，它建立在SSL 3.0协议规范之上，是SSL 3.0的后续版本，可以理解为SSL 3.1，它是写入了 RFC 的。该协议由两层组成： TLS 记录协议（TLS Record）和 TLS 握手协议（TLS Handshake）。较低的层为 TLS 记录协议，位于某个可靠的传输协议（例如 TCP）上面。

SSL/TLS 握手流程

SSL/TLS 握手是为了安全地协商出一份对称加密的秘钥，这个过程很有意思，下面我们一起来了解一下。

（1）client hello

握手第一步是客户端向服务端发送 Client Hello 消息，这个消息里包含了一个客户端生成的随机数 Random1、客户端支持的加密套件（Support Ciphers）和 SSL Version 等信息。

（2）server hello

第二步是服务端向客户端发送 Server Hello 消息，这个消息会从 Client Hello 传过来的 Support Ciphers 里确定一份加密套件，这个套件决定了后续加密和生成摘要时具体使用哪些算法，另外还会生成一份随机数 Random2。注意，至此客户端和服务端都拥有了两个随机数（Random1+ Random2），这两个随机数会在后续生成对称秘钥时用到。

（3）server certificate

这一步是服务端将自己的证书下发给客户端，让客户端验证自己的身份，客户端验证通过后取出证书中的公钥。

（4）Server Hello Done

Server Hello Done 通知客户端 Server Hello 过程结束。

（5）Client Key Exchange

上面客户端根据服务器传来的公钥生成了 PreMaster Key，Client Key Exchange 就是将这个 key 传给服务端，服务端再用自己的私钥解出这个 PreMaster Key 得到客户端生成的 Random3。至此，客户端和服务端都拥有 Random1 + Random2 + Random3，两边再根据同样的算法就可以生成一份秘钥，握手结束后的应用层数据都是使用这个秘钥进行对称加密。

为什么要使用三个随机数呢？这是因为 SSL/TLS 握手过程的数据都是明文传输的，并且多个随机数种子来生成秘钥不容易被暴力破解出来。

（6）Change Cipher Spec(Client)

这一步是客户端通知服务端后面再发送的消息都会使用前面协商出来的秘钥加密了，是一条事件消息。

（7）Finished(Client)

客户端发送Finished报文。该报文包含连接至今全部报文的整理校验值。这次握手协议是否能成功，要以服务器是否能够正确解密该报文作为判定标准。

（8）Change Cipher Spec(Server)

服务器同样发送Change Cipher Spec报文给客户端

（9）Finished(Server)

服务器同样发送Finished报文给客户端

（10-11）Application Data

到这里，双方已安全地协商出了同一份秘钥，所有的应用层数据都会用这个秘钥加密后再通过 TCP 进行可靠传输。

（12）Alert：warning, close notify

最后由客户端断开连接。断开连接时，发送close_notify报文。上图做了一些省略，在这步之后再发送一种叫做MAC（Message Authentication Code）的报文摘要。MAC能够查知报文是否遭到篡改，从而保护报文的完整性。

（*）demand client certificate

Certificate Request 是服务端要求客户端上报证书，这一步是可选的，对于安全性要求高的场景会用到。

（*）check server certificate

客户端收到服务端传来的证书后，先从 CA 验证该证书的合法性，验证通过后取出证书中的服务端公钥，再生成一个随机数 Random3，再用服务端公钥非对称加密 Random3 生成 PreMaster Key。

RSA

RSA 是一种公钥密码算法，我们简单的走一遍它的加密解密过程加密算法：密文 = (明文^E) mod N，其中公钥为{E, N}，即”求明文的 E 次方的对 N 的余数“解密算法：明文 = (密文^D) mod N，其中秘钥为{D, N}，即”求密文的 D 次方的对 N 的余数“例：我们已知公钥为{5, 323}，私钥为{29, 323}，明文为 300，请写出加密和解密的过程：加密：密文 = 123 ^ 5 mod 323 = 225解密：明文 = 225 ^ 29 mod 323 = [[(225 ^ 5) mod 323] * [(225 ^ 5) mod 323] * [(225 ^ 5) mod 323] * [(225 ^ 5) mod 323] * [(225 ^ 5) mod 323] * [(225 ^ 4) mod 323]] mod 323 = (4 * 4 * 4 * 4 * 4 * 290) mod 323 = 123