共计 4005 个字符，预计需要花费 11 分钟才能阅读完成。
本文目录：
1.1 背景知识
1.2 互联网数据加密的细节
1.3 互联网数据签名的细节
1.4 互联网数据安全传输的细节
1.5 CA、PKI 及信任 CA
1.6 数字证书类型和内容
1.7 SSL 握手机制
1.1 背景知识
对称加密：加密解密使用同一密钥，加解密速度快。随着人数增多，密钥数量急增 n(n-1)/2。
非对称加密：使用公私钥配对加解密，速度慢。公钥是从私钥中提取出来的，一般拿对方公钥加密来保证数据安全性，拿自己的私钥加密来证明数据来源的身份。
单向加密：不算是加密，也常称为散列运算，用于生成独一无二的校验码 (或称为指纹、特征码) 来保证数据的完整性和一致性，如 MD5、SHA。具有雪崩效应，任何一点数据的改变，生成的校验码值变化非常大。
互联网数据安全可靠的条件：
1. 数据来源可信，即数据发送者身份可信。
2. 数据具备完整性，即数据未被修改过。
3. 数据安全性，即数据不会被泄漏，他人截获后无法解密。
1.2 互联网数据加密的细节
对数据加密的方法有三种：对称加密、私钥加密和公钥加密。三种方法只靠其中任意一种都有不可容忍的缺点，因此考虑将它们结合使用。
考虑这三种加密算法的特性，公私钥加密速度慢，对称加密快，所以可以首先对数据部分使用对称加密。再进一步考虑，公钥大家都可以获取，若使用自己私钥加密，数据被截获后直接就被破解，因此使用对方的公钥加密，又由于公钥加密速度慢，所以可以使用对方公钥对对称密钥部分进行加密。
数据的收取者解密时，将使用自己的私钥解密第一层，得到对称密钥后加密的数据，再使用对称密钥解密，这样就能获得最终数据。
如下图所示分别是加密和解密的全过程。
加密的方法很多，但是上述方法是综合考虑互联网安全后较为成熟的一种简单加密方法。
使用上述方法加密保证了数据的安全性，但是还未保证数据的完整性、一致性以及数据来源的可靠性。
1.3 互联网数据签名的细节
在保证了数据的安全性后，还需要保证数据的完整性、一致性以及数据来源的可靠性。
对于数据的完整性和一致性，使用单向加密算法，通过 hash 函数计算出数据独一无二的校验码，这个校验码称为“信息摘要(Message Digest)”。
对于数据来源可靠性，使用自己的私钥加密即可验证身份，因为获得数据后使用公钥不能解密的就证明数据不是配对私钥加密的。但是私钥加密速度慢，所以只用私钥加密摘要信息，加密后的摘要信息称为“数字签名(Signature)”。
用户获得数字签名后的数据，首先使用数据来源方的公钥解密，这样获得了数据和信息摘要部分，并确认了数据来源的可靠性。由于这时候数据部分是没有被加密的，所以用户也可以使用同种单向加密算法计算出摘要信息，然后对比来源方的摘要信息和自己计算出的摘要信息，如果相等则证明数据完全未被修改过，是完整一致的。
因此只要使用数字签名就能保证数据来源的可靠性、数据的完整性和一致性。
如图所示分别是数字签名和确认数据的全过程。
1.4 互联网数据安全传输的细节
要在互联网上安全传输数据，要保证数据来源可靠、数据原始未被修改过、数据丢失不泄密。
如果数据传输双方张三和李四不在意数据丢失的泄露性，那么可以不对数据进行加密，只要数字签名即可，即使被中间人王五截获了甚至截获后修改一番再发送给李四也无所谓，因为李四可以根据数字签名验证数据的来源及数据的完整性，若发现被修改后大不了不用了。现在互联网上很多时候下载软件时就提供了签名验证，使用的就是这种机制，不管软件是否被截取，只要安装者能验证即可，如下图。
但是如果在意数据泄漏呢？就需要将数字签名和加密结合起来使用。有两种方案：1. 先对数据加密，再对加密后的整体进行数字签名；2. 先对数据进行数字签名，再对签名后的整体进行加密。
在互联网上基本使用第二种方法，用户最终只对数据部分进行校验而不对加密后的数据进行校验。具体细节如下：首先进行数字签名，再使用对称加密加密签名后的整体，然后使用对方的公钥只加密对称密钥部分。这样即保证了加密速度，还保证了数据的安全性、可靠性和完整性。解密时反向进行即可。如图所示。
但是这时还有一个漏洞，问题出在数字签名过程中私钥加密以及后面公钥解密的不安全性。图中李四在拿公钥 A 解密的时候，这个公钥 A 真的是张三的公钥吗？也许张三传输公钥给李四的过程中被王五截断，王五声称自己是张三，并把自己的公钥给了李四，然后王五用自己的私钥对木马程序进行签名，进行对称加密后再使用李四的公钥加密，最后传输给李四，这样一来李四以为王五就是张三，导致的结果是李四对木马程序完全信任。
如何解决这个漏洞呢？只要保证李四获得的公钥 A 真的是来源于张三即可，如何保证呢？互联网之下，数据传输的两端可能谁都不认识谁，谁也不相信谁，所以最终还是依靠公益性的第三方组织——CA。
1.5 CA、PKI 及信任 CA
CA(Certificate Authority)是数字证书认证中心，常称为证书颁发机构，申请者提交自己的 公钥 和一些个人信息 (如申请者国家，姓名，单位等) 给 CA，CA 对申请者的这些信息单向加密生成摘要信息，然后使用 自己的私钥 加密整个摘要信息，这样就得到了 CA 对申请者的数字签名，在数字签名上再加上 CA 自己的一些信息 (如 CA 的机构名称，CA 层次路径等) 以及该证书的信息(如证书有效期限)，就得到了所谓的数字证书。
过程如下图。
如果某用户信任了该 CA，就获取了该 CA 的公钥（实际上信任 CA 的其中一个作用就是获取 CA 公钥），使用该公钥解密数字证书就可以验证申请者的信息以及申请者公钥的可靠性（申请者的公钥只被 CA 的私钥加密，解密该私钥后只是需要验证可靠性）。
这里的关键是 CA 使用自己的私钥给申请者加密，那么如何保证 CA 是可信并且合法的呢？根 CA 是通过自签署数字证书的方式标榜自己的可信性和合法性，第一级子 CA 由根 CA 颁发合法数字证书，第二级直至所有的子 CA 都由上一级子 CA 颁发数字证书。对于多级子 CA 只需要信任根 CA 即可，因为获取了根 CA 的公钥，可以解密第一级子 CA 的证书并获取验证第一级子 CA 的公钥，层层递进，最终获取到为申请者颁发数字证书的机构并获取它的公钥。
正是这些根 CA 和子 CA 组成了 PKI。
信任 CA 后，每次接收到需要解密的数字证书时，还要去该颁发机构指定网站的证书吊销列表（CRL）中查询该证书是否被吊销，对于吊销后的证书应该不予以信任，这是信任 CA 的第二个作用。导致证书被吊销的可能性不少，例如申请者的私钥被黑客获取，申请者申请吊销等。
也有公司使用自签的证书，例如某些银行、12306 有时候就要求下载证书并安装。使用自签证书的好处当然是省钱、方便啦。
1.6 数字证书类型和内容
PKI 的两种实现方式 TLS 和 SSL 使用的证书格式都是 x509，TLSv1 和 SSLv3 基本等价，只不过 SSL 实现在 OSI 4 层模型中的应用层和传输层的中间，TLS 实现在传输层。
还有 PKI 的另一种实现方式 GPG，它的证书使用的不是 x509 格式。
数字证书中包含的信息有：申请者的公钥，证书有效期，证书合法拥有人，证书如何被使用，CA 的信息，CA 对申请者信息的数字签名。
1.7 SSL 握手机制
有了 CA 颁发的数字证书后，通信机制就和下图的机制完全不同了。
上图中每一段数据都签名加密，有了数字证书后实际上已经验证了身份，不需要每一段数据都签名，这能提升效率。在上图中的漏洞是无法确认获取的公钥 A 是否可信，有了数字证书后已经能够确认公钥 A 是可信的。但问题是公钥 A 本来目的是用来解密数字签名的，有了数字证书后不需要数字签名了，那公钥 A 不是多余的吗，如果多余，那把公钥 A 交给 CA 是不是也是多余的呢？
不多余，因为 SSL 的握手机制和数字签名机制完全不同。以下是单向验证机制，只验证服务端。
第一步：Visitor 给出协议版本号、一个客户端随机数（Client random），以及客户端支持的加密方法。
第二步：Server 确认双方使用的加密方法，以及一个服务器生成的随机数（Server random）。
第三步：Server 发送数字证书给 Visitor。
第四步：Visitor 确认数字证书有效（查看证书状态且查询证书吊销列表），并使用信任的 CA 的公钥解密数字证书获得 Server 的公钥，然后生成一个新的 46 字节随机数（称为预备主密钥 Pre-master secret），并使用 Server 的公钥加密预备主密钥发给 Server。
第五步：Server 使用自己的私钥，解密 Visitor 发来的预备主密钥。
第六步：Visitor 和 Server 双方都具有了(客户端随机数 + 服务端随机数 + 预备主密钥)，它们两者都根据约定的加密方法，使用这三个随机数生成对称密钥——主密钥（也称为对话密钥 session key），用来加密接下来的整个对话过程。
第七步：之后所有的数据只需要使用“对话密钥”加密即可，不再需要多余的加密机制。
注意：1. 在 SSL 握手机制中，需要三个随机数（客户端随机数 + 服务端随机数 + 预备主密钥）；2. 至始至终客户端和服务端只有一次非对称加密动作——客户端使用证书中获得的服务端公钥加密预备主密钥。3. 上述 SSL 握手机制的前提单向验证，无需验证客户端，如果需要验证客户端则可能需要客户端的证书或客户端提供签名等。
Server 和 Visitor 通信，Server 把数字证书发给 Visitor，最关键的一点是 Visitor 要保证证书的有效性，通过查看证书状态并去 CA 的吊销列表查看 Server 的证书是否被吊销。只有 Server 的证书可用了，才保证了第一环节的安全性。
可以看出，使用 SSL 比前文介绍的“数字签名 + 加密”简便多了，将身份验证和密钥生成在会话的开始就完成了，而不需要每次的数据传输过程中都进行，这就是https 等使用 ssl 加密机制的握手通信过程。
本文永久更新链接地址：http://www.linuxidc.com/Linux/2017-10/147745.htm
