ENC是什么加密算法 enc解密

文章目录

• 1.加密算法

• 1.1 对称加密

• DES
• 3DES
• AES

• 1.2 非对称加密

• RSA
• ECC
• DSA

• 1.3 非对称加密示例

• 2.消息摘要
• 3.数字签名
• 4.数字证书

• 4.1 由来
• 4.2 内容
• 4.3 编码
• 4.4 扩展名
• 4.5 申请
• 4.6 发布机构
• 4.7 数字证书解决公钥的受信问题

• 5.HTTPS

• 5.1 由来
• 5.2 通信过程
• 5.3 优点
• 5.5 缺点

• 参考文献

HTTPS 实现了安全的 HTTP 通信，其背后隐藏了太多知识，如对称加密、非对称加密、RSA、消息摘要、数字签名、数字证书等。下面让我们循序渐进，一起来了解下 HTTPS 背后的知识。

1.加密算法

加密算法一般分为两种：对称加密和非对称加密。

1.1 对称加密

对称加密算法使用的加密和解密的密钥一样，比如用秘钥 123 加密就需要用 123 解密。实际中秘钥都是普通数据在互联网传输的，这样秘钥可能会被中间人截取，导致加密被破解。其过程如下：

// 加密
E = ENC(M, K)

// 解密
M = DEC(E, K)

其中 M 是消息，K 是密钥，E 是加密后的密文，ENC() 和 DEC() 分别是加密和解密算法。

对称加密算法的特点主要有：

• 加密和解密使用同一个密钥。
• 加解密速度快，适合数据较大时使用。
• 密钥传输过程不安全，且容易被截获，密钥管理也比较麻烦。

DES

DES（Data Encryption Standard）数据加密标准，最早由 IBM 于 20 世纪 70 年代初开发。

DES 后来在 1977 年被美国国家标准局（NBS）确定为联邦资料处理标准（FIPS），并授权在非密级政府通信中使用，随后该算法在国际上广泛流传。

DES 使用 56 位的密钥对数据进行加密和解密，将数据分成 64 位的块，经过多轮置换、代换和混淆操作。然而，由于其密钥长度较短，现代计算能力和攻击方法可以轻松破解 DES。

3DES

3DES（Triple DES）是 DES 的增强版本，由 Merkle 和 Hellman 在 1981 年提出。

由于计算机运算能力的不断增强，原版 DES 密码的密钥长度变得容易被暴力破解。3DES 被设计用来提供一种相对简单的方法， 使用三次 DES 操作来提升加密强度，使用三个不同的密钥对数据进行加密、解密、再加密的操作。虽然 3DES 通过增加 DES 的密钥长度提高了安全性，但由于其多次加密的特性，性能相对较差。

AES

AES（Advanced Encryption Standard）高级加密标准，其原名为 Rijndael 加密法。

AES 由最初由比利时密码学家 Joan Daemen 和 Vincent Rijmen 于 1998 年所设计，结合两位作者的名字，以 Rijndael 为名投稿美国国家标准与技术研究院（NIST）高级加密标准的甄选流程，用来替代原先的 DES。经过 NIST 评估和选择，于 2001 年正式发布于 FIPS PUB 197，并在 2002 年成为美国联邦政府的对称加密标准。

AES 使用固定大小的块（128 位）和三种密钥长度（128 位、192 位和 256 位），支持多种加密模式（如 ECB、CBC、CFB 等），具有强大的安全性和性能。AES 在安全性和效率方面都超越了 DES 和 3DES。

1.2 非对称加密

所谓非对称指加密算法需要一对密钥，使用其中一个加密，使用另一个才能解密。把密钥分为公钥和私钥，公钥是公开的，所有人都知道，私钥是保密的，只有自己知道。

非对称加密算法有两种应用模式，加解密模式和签名验签模式。

RSA

RSA（Rivest-Shamir-Adleman） 是使用最广泛的非对称加密算法，由 Ron Rivest、Adi Shamir、Leonard Adleman 于1977 年在麻省理工学院工作时提出，RSA 是三者姓氏首字母的拼接。

它的基本原理涉及到数学中的大整数因数分解问题，即将一个大的合数（通常是一个极大数字）分解为其素数因子。RSA 算法的安全性基于这个问题的难解性，目前还没有高效的方法可以在合理的时间内分解大整数。

RSA 支持变长密钥非对称加密，需要加密的文件块的长度也是可变的。

ECC

ECC（Elliptic Curve Cryptography）椭圆曲线加密算法是由数学家 Neal Koblitz 和 Victor S. Miller 在 1985 年独立提出的非对称加密算法。

ECC 的原理基于椭圆曲线上的离散对数问题，即找到一个点的离散对数是困难的。它利用了椭圆曲线上的点运算，以实现加密和解密操作。

与 RSA 相比，ECC 提供了相同的安全性水平下更短的密钥，从而提供更高效的加解密操作。

DSA

DSA（Digital Signature Algorithm，数字签名算法）由美国国家安全局（National Security Agency，NSA）的 David W. Kravitz 博士于 1991 年提出。

DSA 是一种基于模幂运算和离散对数问题，用于数字签名的公钥密码系统。DSA 是 Schnorr 和 ElGamal 签名方案的变体。

DSA 的椭圆曲线密码学版本是 ECDSA（Elliptic Curve Digital Signature Algorithm）。

1982年，美国政府征求了关于公钥签名标准的建议。1991年8月，美国国家标准与技术研究所（National Institute of Standards and Technology，NIST）提议将 DSA 用于他们的数字签名标准（Digital Signature Standard，DSS）。最初，人们对它提出了强烈的批评，尤其是那些已经投入精力开发基于RSA密码系统的数字签名软件的软件公司。尽管如此，NIST于1994年将 DSA 作为联邦信息处理标准，编号 186（Federal Information Processing Standards，FIPS 186）。

1.3 非对称加密示例

假如接收方 B 有一对密钥：私钥（SK）和公钥（PK），其中 PK 是公开的。发送方 A 用接收方 B 的公钥 PK 对消息加密，加密过程如下：

E = ENC(M, PK)

接收方 B 收到密文后使用自己的私钥 SK 进行解密，解密过程如下：

M = ENC(E, SK)

这样，即使密文被中间人截获，由于其不知道接收方 B 的私钥无法破解密文，所以消息仍然是安全的。

反过来也是可以的，即用私钥 SK 加密，用公钥 PK 解密。即公钥和私钥都可用于加密和解密。

虽说两者都可用于加密，但是不同场景使用不同的密钥来加密。

1. 私钥用于签名，公钥用于验签。

签名和加密作用不同，签名并不是为了保密，而是为了保证这个签名是由特定的某个人签名的，而不是被其它人伪造的签名，所以私钥的私有性就适合用在签名用途上。

私钥签名后，只能由对应的公钥解密，公钥又是公开的（很多人可持有），所以这些人拿着公钥来解密，解密成功后就能判断出是持有私钥的人做的签名，验证了身份合法性。

2. 公钥用于加密，私钥用于解密。

因为公钥是公开的，很多人可以持有公钥。若用私钥加密，那所有持有公钥的人都可以进行解密，这是不安全的！

若用公钥加密，那只能由私钥解密，而私钥是私有不公开的，只能由特定的私钥持有人解密，保证的数据的安全性。

2.消息摘要

消息摘要（Message Digest）可以将消息哈希成一个长度固定的唯一值。值唯一的意思是不同的消息转换的摘要是不同的，并且同样的明文其摘要必定一致。该过程不可逆，即不能通过摘要反推明文。

常用的消息摘要算法有 MD5、SHA1、SHA256、SHA512 等。

3.数字签名

先来一个比较学术的解释。

数字签名（Digital Signature）是非对称加密与消息摘要技术的应用，用于解决消息来源受信与完整性问题。

有了 RSA，我们可以将其用于网络传输数据的加密。比如 A 要发送一封 Email 给 B，A 不想让任何其他人在传输中看到 Email 的内容，做法就是使用 B 的公钥对 Email 加密，只有 B 的私钥能够解密。

某天出意外了，有黑客冒充 A 给 B 发送 Email，并且也用 B 的公钥加密，导致 B 无法区分这封邮件是否来自 A。怎么办？此时 A 可以用自己的私钥加密 Email，那么 B 收到邮件后如果用 A 的公钥可以解密邮件，那么证明这封信肯定来自于 A。

通过这个例子，我们基本可以明白非对称加密了的作用了。

• 公钥的作用：对内容本身加密，使用私钥解密，保证内容不被其他人看到。
• 私钥的作用：加密内容摘要，使用公钥解密，如果成功证明内容的来源。
• 公钥和私钥是配对关系，公钥加密就用私钥解密，私钥加密就用公钥解密，用错的密钥尝试解密会报错。

仔细思考会发现，假设 A 用自己的私钥对 Email 加密发送，会存在下面的问题：对文件本身加密可能是个耗时过程，比如这封Email 足够大，那么私钥加密整个文件以及拿到文件后的解密无疑是巨大的开销。

使用数字签名可以解决这个问题。

1. A 先对这封 Email 执行哈希运算得到消息摘要
2. 然后 A 用自己的私钥对消息摘要加密，生成数字签名；
3. 把数字签名加在 Email 正文后面，一起发送给 B。当然，为了防止邮件被窃听，对邮件内容使用 B 的公钥进行加密，但这个不属于数字签名范畴；
4. B 收到邮件后用 A 的公钥对数字签名解密，成功则代表 Email 确实来自 A，失败说明有人冒充，此时数字签名起到了身份认证的作用；
5. B 对邮件正文通过自己的私钥解密后执行哈希运算得到摘要；
6. B 会对比第 4 步数字签名的 Hash 值和自己运算得到的 Hash 值，一致则说明邮件未被篡改。此时数字签名用于数据完整性的验证。

整个过程图示如下：

通过上面的例子可以发现数字签名是非对称密钥加密技术与数字摘要技术的实际应用，主要有两个作用：

• 对数字签名使用发送方的公钥解密，根据解密是否成功用于身份认证；
• 将解密后的消息摘要与收到的消息摘要进行比对，校验消息的完整性。

4.数字证书

4.1 由来

在了解数字签名的由来和作用后，仔细想想你会发现存在如下问题。

公钥是公开的并且可以自行导入电脑，如果有人比如 C 偷偷在 B 的电脑用自己公钥替换了 A 的公钥，然后用自己的私钥给 B 发送 Email，这时 B 收到邮件后，实际上使用的是 C 的公钥进行解密，这时 C 冒充 A 给 B 发邮件，结果 B 无法察觉。

确实会存在这种情况，这里问题的根源就在于，大家都可以生成公私钥对，无法确认公钥到底是谁的。 如果能够确定公钥是谁的就不会有这个问题了。例如如果经过某种检查，能够发现 B 获取的公钥不是 A 的就好了。

解决办法就是数字证书（Digital Certificate）。

4.2 内容

ITU-T X.509 是密码学里公钥证书的格式标准。

可能有人要问了，那么什么是 ITU-T 呢？

ITU-T 的全称是 International Telecommunication Union Telecommunication Standardization Sector，也就是国际电联电信标准化部门，主要用来协调电信和信息通信技术标准。

RFC 5280 以 ITU-T X.509 为基础，在其基础上进一步详细说明了 X.509 证书的使用和相关规则，包括证书验证、证书链构建、证书扩展等。

X.509 v3 证书内容格式如下：

Certificate  ::=  SEQUENCE  {
        tbsCertificate       TBSCertificate,
        signatureAlgorithm   AlgorithmIdentifier,
        signatureValue       BIT STRING  }

其中 TBSCertificate 表示 To Be Signed Certificate，指要被签名的证书主体，内容如下：

version：标识证书版本号的整数。
serialNumber：一个整数，表示证书颁发机构颁发的每个证书的唯一编号。
signature：证书发行机构对当前证书签名使用的算法和可选参数。 
issuer：证书的颁发者，也就是指明这个证书是哪个机构创建的。
validity：证书有效期的起始和结束时间。
subject：证书所有者，一般是个人、公司、机构的名称，或公司网站的网址等。
subjectPublicKeyInfo：证书所有者的非对称加密算法与公钥。
issuerUniqueID：发行者唯一标识符（可选）。
subjectUniqueID：证书所有者唯一标识符（可选）。
extensions：扩展信息（可选）。

证书主体外的两个字段为：

signatureAlgorithm：证书发行机构对当前证书签名使用的算法和可选参数。 
signatureValue：证书发行机构对证书的数字签名。

有几个问题需要注意一下。

（1）数字证书的数字签名是如何产生的？

其过程是对数字证书摘要使用数字证书发行者的私钥采用签名算法进行加密获得，用来保证证书的完整性和确认该证书由数字证书发行者颁发。可见，数字证书发行者除了给别人发布证书外，他自己本身也有自己的证书。

（2）证书发行机构的证书是哪里来的呢？

证书发布机构的数字证书（一般由他自己生成）在我们的操作系统刚安装好时（例如 Windows 7 等操作系统），这些证书发布机构的数字证书就已经被微软（或者其它操作系统的开发机构）安装在操作系统中了，微软等公司会根据一些权威安全机构的评估选取一些信誉很好并且通过一定的安全认证的证书发布机构，把这些证书发布机构的证书默认安装在操作系统里面，并且设置为操作系统信任的数字证书。这些证书发布机构自己持有与他自己的数字证书对应的私钥，他会用这个私钥加密所有他发布的证书的指纹作为数字签名。

（3）TBSCertificate.signature 和 signatureAlgorithm 是不是重复了？

细心的你可能会发现 TBSCertificate 中的 signature 和 TBSCertificate 外部的 signatureAlgorithm 都表示 CA 对当前数字证书签名使用的算法和可选参数。

二者的定义是相同的，均为

AlgorithmIdentifier  ::=  SEQUENCE  {
        algorithm               OBJECT IDENTIFIER,
        parameters              ANY DEFINED BY algorithm OPTIONAL
}

官方文件也规定二者是相同的。至于为何要出现两次，RFC 6211 给出了一个简要的解释：

In an algorithm substitution attack, the attacker changes either the algorithm being used or 
the parameters of the algorithm in order to change the result of a signature verification process.
In X.509 certificates, the signature algorithm is protected because it is duplicated in the
TBSCertificate.signature field with the proviso that the validator is to compare both fields
as part of the signature validation process.

主要是为了防范签名算法替换攻击，所以将 signatureAlgorithm 在证书主体 TBSCertificate 中又重复定义一次。

X.509 证书验证的合理实现将使用外部字段（signatureAlgorithm）来验证签名，然后再检查内部签名字段是否与外部字段匹配。事实上，如果不进行最后一次验证，实际上不会损害安全性，因为如果有人可以伪造证书上的签名，那么他们也可以更改内部算法标识符。

4.3 编码

了解了证书内容格式之后，不知道你有没有疑问，证书的不同字段如何分隔？

回答这个问题，需要先了解一下证书的编码。

X.509 使用 ASN.1 抽象语法标记描述证书的内容，但证书内容如何编码，在 X.509 标准中并没有被界定下来。

这里先介绍一下 ITU-T X.690 ，它是 ITU-T 标准，规定了几种 ASN.1 编码格式：

• Basic Encoding Rules (BER)
• Canonical Encoding Rules (CER)
• Distinguished Encoding Rules (DER)

关于 X.509 证书，可能有不同的编码格式，目前最常见有以下两种编码格式。

（1）DER

DER（Distinguished Encoding Rules）可分辨编码规则，是 BER 的一个受限变体，也就是说 DER 是 BER 的子集，提供了一种准确编码 ASN.1 值的方法。

DER 适用于需要唯一编码的情况，例如在密码学中，并确保需要数字签名的数据结构产生唯一的序列化表示。DER 可以被认为是BER的规范形式。如在 BER 中，布尔值 true 可以编码为 255 个非零字节值中的任何一个，而在 DER 中，只有一种方法编码布尔值 true。

DER 是一种二进制编码格式，文本编辑器无法读取，但 Web 浏览器和许多客户端应用程序可以进行数据处理。

既然 DER 是一种 BER，那么不得不介绍一下 BER 的编码规则。

BER 是最早的编码规则，使用 Tag-Length-Value 的格式对所有信息进行编码。

在 BER 中，每个数据元素都被编码为类型标识符、长度描述、实际数据元素，以及可选的内容结束标记。

类型标识符	长度	实际数据	内容结束标记
Type	Length	Value	只用在不确定长度的情况

所有的编码都是以字节为单位的。

DER 在 BER 的基础上，加了如下限制：

1. 长度编码必须使用定型，且必须使用尽可能短的长度编码
2. 位串、八位组串和受限字符串必须使用原始编码
3. Set 的元素根据它们的标签值按排序顺序编码

有了上面的限制，使用 DER 编码后的内容便是唯一确定的。

知道了 DER 使用 TLV 格式编码数据，因为加入了字段长度，所以不需要添加额外的分隔符分隔不同字段。

（2）PEM

PEM（Privacy Enhanced Mail）：隐私增强邮件，是一种加密的电子邮件编码规则，在 RFC7468 中被正式标准化，可将 DER 编码的证书转换为文本文件。

具体格式如下：

-----BEGIN label 1-----
base64 string...
-----END label 1-----
-----BEGIN label 2-----
base64 string...
-----END label 2-----

其中 label 1 和 label 2 可以有 1~N 个。常用的 label 有 (https://tools.ietf.org/html/rfc7468#section-4)

CERTIFICATE : 公钥证书文件 。
CERTIFICATE REQUEST : CSR请求证书文件。
PRIVATE KEY : 私钥文件。
PUBLIC KEY : 公钥文件。
X509 CRL : X509证书吊销列表文件。

4.4 扩展名

X.509 有很多种常用的扩展名。不过这些扩展名有时候也是其他类型文件的扩展名，也就是说具有这个扩展名的文件并不一定是 X.509 证书，也可能只是保存了私钥的文件。

.pem : PEM 格式。
.key : PEM 格式的私钥文件。
.pub : PEM 格式的公钥文件。
.crt : PEM 格式的公钥证书文件，也可能是 DER 格式。
.cer : DER 格式的公钥证书文件，也可能是 PEM 格式。
.crs : PEM 格式的 CSR 文件，也可能是 DER 格式。

其中 CSR（Certificate Signing Request）文件是一种用于向证书颁发机构（CA）申请数字证书的文件格式。CSR 文件包含了公钥以及与该公钥相关的组织信息，用于验证申请者的身份和生成数字证书。

CSR 文件通常包含以下信息：

• 公钥：CSR 文件中包含了生成密钥对时所生成的公钥部分。
• 组织信息：CSR 文件中包含了与证书申请者相关的组织信息，例如组织名称、组织单位、组织地址等。
• 附加信息：CSR 文件中可以包含其他附加信息，例如主题备用名称（SAN，Subject Alternative Name）、密钥用途等。

当申请者希望获得一个数字证书时，可以使用一些工具（如 OpenSSL）生成 CSR 文件，并将该文件提交给证书颁发机构。证书颁发机构会根据 CSR 文件中的信息验证申请者的身份，并使用自己的私钥对公钥进行签名，生成一个数字证书。该证书可以用于加密通信、数字签名和身份验证等用途。

4.5 申请

举个例子方便大家理解。

假设我们公司 “Dablelv Inc.” 花了 1000 CNY 向数字证书认证中心 CA 申请了一张证书。注意，这个证书发布机构 CA 是一个大家公认并被一些权威机构接受的证书发布机构，我们的操作系统里面已经安装了 CA 的证书。CA 在给我们发布证书时，把 Issuer、Subject、Public key、Valid from、Valid to 等信息以明文的形式写到证书里面，然后用一个指纹算法计算出这些数字证书内容的一个指纹，并把指纹和指纹算法用自己的私钥进行加密，然后和证书的内容一起发布，同时 CA 还会给一个我们公司 “Dablelv Inc.” 的私钥给到我们。

假设我花了1000 CNY 买的这个证书的内容如下：

version：V3
serialNumber：0b1362b6ee6a9d3e968930f16e207d39
signature：sha256RSA
issuer：CA
validity: 起始日期-结束日期
subject：Dablelv Company
subjectPublicKeyInfo：一串很长的数字
证书其它内容
signatureAlgorithm：sha256RSA
signatureValue：证书发行者对证书的签名

其中证书签名使用 CA 的私钥，采用 RSA 对证书的摘要进行加密生成，有什么问题证书发行者 CA 会负责。

注意： 如何确保证书的合法性呢？

使用者在打开证书时，读取证书中的 Issuer 为 CA，然后会在操作系统中受信任的发布机构的证书中去找 CA 的证书，如果找不到，那说明证书的发布机构是个不受信的发布机构，证书可能有问题，程序会给出一个错误信息。 如果在系统中找到了 CA 的证书，那么应用程序就会从证书中取出 CA 的公钥，然后对我们 “Dablelv Inc.” 公司的证书里面的证书签名用 CA 的公钥进行解密。

如果解密成功，说明该证书由该发布机构发布。

如果用同一个摘要算法计算出数字证书的摘要，并把摘要与从数字签名中解密获取的摘要进行对比，如果一致说明证书内容没有被篡改。

对方然后就可以放心的使用数字证书中的公钥和我们 “Dablelv Inc.” 进行通信了。

4.6 发布机构

其实所有的公司都可以发布证书，我们自己也可以去注册一家公司来专门给别人发布证书。但是很明显，我们自己的专门发布证书的公司是不会被那些国际上的权威机构认可的，人家怎么知道你是不是个皮包公司？因此微软在它的操作系统中，并不会信任我们这个证书发布机构，当应用程序在检查证书的合法信的时候，一看证书的发布机构并不是操作系统所信任的发布机构，就会抛出错误信息。也就是说 Windows 操作系统中不会预先安装好我们这个证书发布机构的证书，不信任我们这个发布机构。

为什么一个证书发布机构受不受信任这么重要？我们举个例子。假设我们开了一个皮包公司来为别人发布证书，并且我和微软有一腿，微软在他们的操作系统中把我设置为了受信任的证书发布机构。现在如果有个小公司叫 Wicrosoft 花了 10 块钱让我为他们公司申请了一个证书，并且公司慢慢壮大，证书的应用范围也越来越广。然后有个奸商公司 JS Company 想冒充 Wicrosoft，于是给了我 10000 块，让我为他们颁布一个证书，但是证书的名字（Subject）要写 Wicrosoft，假如我为了这 10000 块真地把证书给了他们，那么他们以后就可以使用这个证书来冒充 Wicrosoft 了。

如果是一个受信合规的证书发布机构，比如你要向他申请一个名字叫 Wicrosoft 的证书，它会让你提供很多资料证明你确实可以代表 Wicrosoft 这个公司，也就是说他会去核实你的身份。证书发布机构是要为他发布出的证书负法律责任的。

到这里，你可能会想，那我们自己不就可以发布证书了吗，为何还要花钱去申请？我们自己当然也可以成立证书发布机构，但是需要通过一些安全认证等等，只是有点麻烦。另外，如果数字证书只是在公司内部使用，在公司的所有机器上把自己设置为操作系统信任的证书发布机构，这样以后公司发布的证书在公司内部的所有机器上就可以通过验证了。但是这只限于内部应用，因为只有我们公司自己的机器上设置了信任我们自己这个所谓的证书发布机构，而其它机器上并没有事先信任我们这个证书发布机构，所以在其它机器上，我们发布的证书就无法通过安全验证。

4.7 数字证书解决公钥的受信问题

了解了数字证书，我们就可以使用数字证书来保证公钥是可信的。

还是以 A 给 B 发送邮件为例。

（1）首先 A 去找证书中心（CA，Certificate Authority）申请数字证书，为公钥做认证。证书中心用自己的私钥，对 A 的数字证书做了数字签名，生成 A 的数字证书。

（2）A 在邮件正文下方除了数字签名，另外加上这张数字证书。

（3）B 收到 Email 后，从操作系统中受信任的发布机构的证书中去找 CA 的数字证书，从 CA 的数字证书中拿到 CA 的公钥，用 CA 的公钥解密这份数字证书的数字签名，验证数字证书的合法性。然后使用数字证书中 A 的公钥，验证邮件的数字签名，后面流程不再赘述，参见小节 “3.数字签名”。

注意：

（1）要是有 1 万个人要给 B 发邮件，难道 B 要保存 1 万份不同的 CA 数字证书吗？
不需要，CA 中心给可以给 B 一份“根证书”，里面存储 CA 公钥来验证所有 CA 分中心颁发的数字证书。CA 中心是分叉树结构，类似于国务院公安部->省公安厅->市级公安局，不管 A 从哪个 CA 分支机构申请的证书，B 只要预存根证书就可以验证下级证书可靠性。

（2）如何保证 CA 的根证书的可靠性？
CA 中心是获得社会绝对认可和有绝对权威的第三方机构，这一点保证了 CA 根证书的绝对可靠。如果根证书都有问题那么整个加密体系毫无意义。

5.HTTPS

数字签名和数字证书可以用于文件，当然也能用于 HTML 网页数据。HTTPS 就是数字签名和数字证书一个具体应用。

5.1 由来

超文本传输协议 HTTP 协议被用于在 Web 浏览器和网站服务器之间传递信息，HTTP 协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了 Web 浏览器和网站服务器之间的传输报文，就可以直接读取其中的信息。因此，HTTP 协议不适合传输一些敏感信息，比如信用卡号、密码等支付信息。此外，使用 HTTP 协议与服务端进行通信时，也无法得知服务端的身份，以及传输数据是否被篡改。

总的来说，HTTP 的安全缺陷有：
（1）无法验证服务端的身份。
（2）无法保证数据完整性。
（3）无法保证数据传输不被窃听。

HTTPS 的出现是为了解决 HTTP 协议的上述缺陷。HTTPS 使用“数字签名+数字证书”可以解决前两个问题，现在的绝大部分网站都会采用 HTTPS 协议进行数据传输。

如 baidu.com，点击可以查看证书，另外浏览器都会内置 CA 根证书来对这些网站的服务器证书进行校验。

然后，再用 TLS（Transport Layer Security）协议对传输通道加密，保证数据传输不被窃听，解决了第三个问题。

5.2 通信过程

HTTPS（Hyper Text Transfer Protocol Secure）就是 HTTP+TLS 协议。HTTPS 为了兼顾安全与效率，同时使用了对称加密和非对称加密。

数据使用对称加密传输，对称加密过程需要客户端的一个密钥，为了确保能把该密钥安全传输到服务器端，采用非对称加密对该密钥进行加密传输。

下图所示其连接和通信过程：

（1）建立 HTTPS 请求。

客户端向服务端发送 HTTPS 请求，将支持的加密套件（Cipher Suite）带给服务端。

（2）匹配加密协议。

服务端接收加密套件后，和自己支持的加密算法进行比对，如果不符合，则断开连接。

（3）返回 CA 证书。

服务端将 CA 证书（公钥）返回给客户端，数字证书里面包含有很多信息，比如证书的颁发机构、过期时间等等。

（4）客户端验证数字证书。

客户端验证服务端的证书合法性，不合法给出警告信息。

如果没有问题，那么就生成一个随机值，作为客户端的密钥，然后用服务端的公钥加密。

（5）发送客户端密钥。

客户端用服务端的公钥加密密钥，然后发送给服务端。

（6）服务端收取随机密钥。

服务端收到经过加密的密钥，然后用私钥将其解密，得到客户端的随机密钥。然后服务端把要传输的内容使用随机密钥进行加密，这样除非知道密钥，否则无法知道传输的内容。

（7）加密传输。

服务端将经过加密的内容传输给客户端。

（8）客户端解密加密内容。

客户端获取加密内容后，用之前生成的随机密钥对其进行解密。

以上便是 HTTPS 完整的通信过程。

5.3 优点

尽管 HTTPS 并非绝对安全，掌握根证书的机构、掌握加密算法的组织同样可以进行中间人形式的攻击，但 HTTPS 仍是现行架构下最安全的解决方案，主要有以下几个好处：

• 使用 HTTPS 协议可认证用户和服务器，确保数据发送到正确的客户机和服务器。
• HTTPS 协议是由 HTTP + TLS 可防止数据在传输过程中不被窃取、篡改，确保数据的安全和完整性。
• HTTPS 是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。

5.5 缺点

虽然说 HTTPS 有很大的优势，相对与 HTTP 而言，也存在不足之处。

• HTTPS 协议握手阶段比较费时，会使页面的加载时间延长近 50%；
• HTTPS 连接缓存不如 HTTP 高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；
• CA 证书需要支付一定费用，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用；
• CA 证书通常需要绑定 IP，不能在同一 IP 上绑定多个域名，IPv4 资源不可能支撑这个消耗；
• HTTPS 协议的加密范围也比较有限，在黑客攻击、DDoS 攻击、服务器劫持等方面几乎起不到什么作用。最关键的是，CA 证书的信用链体系并不安全，特别是在某些国家可以控制 CA 根证书的情况下，中间人攻击一样可行。

---