1. 基本原理
TLS 依赖两种加密技术：
- 对称加密（symmetric encryption）
- 非对称加密（asymmetric encryption）
1.1 对称加密
加密方和解密方共享同一个秘钥 K：
加密：C = E(M, K)
解密：M = D(C, K)
攻击者且听到 K 后就可以作为一个中间人伪装成任意一个对象，实现中间人攻击
1.2 非对称加密
非对称加密利用成对的两个秘钥：K1 和 K2，加密者使用一个加密，解密者可以利用另一个解密：
加密：C = E(M, K1)
解密：M = D(C, K2)
解密者生成一对秘钥，私钥保存，公钥公开
但是中间人可以截获公钥，然后自己生成一对秘钥，把自己的公钥发送给加密者
用自己的私钥解密加密者的信息，然后用解密者的公钥加密发送给解密者
或者中间人收到解密者公钥加密的消息后，对消息破坏篡改，再发送给解密者
导致解密者无法正确解析密文
1.3 数字签名
- 光靠非对称加密很难确定信息发送方身份，因此发明了数字签名
- 根据数字签名，接收方接收到信息之后，可以判断信息是否被破坏过，如果没有被破坏，就可以正确的解码。如果被破坏，就直接丢弃
- 数字签名可以保证对信息的任何篡改都可以被发现，从而保证信息传输过程中的完整性
- 数字签名是实现的关键技术就是哈希技术
- 加密者先对将要传输的信息进行哈希，得到一串独一无二的信息摘要
- 哈希函数往往是不可逆的，无法根据哈希后的内容推断原文；同时，不同的原文，会造成不同的哈希结果，并且结果的差异是巨大甚至毫无规律的
- 对原文进行再细微的修改，得到的哈希后的内容都会与未经修改的原文的哈希内容大相径庭，保证消息内容不被篡改
- 然后，加密者将信息摘要，用自己的私钥进行加密
这样就保证只有加密者的公钥才能对信息摘要进行正确的解码，进而保证信息摘要一定是来自加密者
加密后的信息摘要实际就是数字签名的内容 - 最后，加密者再将数字签名附加到原文信息的后面，使用解密者公钥加密后发送给解密者
- 解密者接收到信息之后，首先使用自己的私钥解密报文，分别获得原文和数字签名
- 利用加密者公钥对数字签名进行解密，得到信息摘要，如果成功解码，就说明数字签名是来自加密者
- 然后，解密者将信息原文进行哈希得到自己的信息摘要，与解码数字签名得到的信息摘要进行对比，如果相同，就说明原文信息完整，没有被篡改，反之，则确认信息被破坏了
目前为止，利用公钥和私钥以及数字签名，可以保证信息传输过程中的私密性和完整性
但还存在一个问题：就是公钥分发的问题，上述中间人劫持公钥的问题并没有解决
这个问题就需要数字证书和 CA 来解决了
1.4 数字证书和 CA
每个加密者或者接受者都有自己的私钥和公钥，如何判断对方的公钥是真实代表对方的是一个问题
实际我们会引入一个第三方机构，每个人都找这个真实可信的独立的第三方，请求真伪鉴别服务
第三方机构就是 CA（Certification Authorith，证书颁发机构）会给解密者创建一个数字证书
“用户首先产生自己的密钥对，并将公钥及部分个人身份信息传送给认证中心
认证中心在核实身份后，将执行一些必要的步骤，以确信请求确实由用户发送而来
然后，认证中心将发给用户一个数字证书，该证书内包含用户的个人信息和他的公钥信息，同时还附有认证中心的签名信息”
公钥和身份信息（域名或者IP）合起来就是 CSR（certificate signing request，身份证申请）
实际过程可以看做 CA 利用自己的私钥对 CSR 加密，作为数字签名
然后 CSR 连同 CA 的数字签名构成数字证书，也称为 CRT（CA signed certificate）
在之后的发送中加密者将数字证书附在数字签名后
接收者收到后用 CA 的公钥解密获得，加密者的身份和公钥
攻击者不能通过 CA 的验证，无法获取证书，解密者接受后判断数字证书包含的身份信息不是加密者，因此会拒绝
但是如果选择信任了错误的 CA，也会被攻击，通常浏览器中会内置靠谱 CA 的身份证（公钥）
1.4 信任链、根身份证和自签名
CA 也分为不同级别，需要逐级验证
比如 CA1 不被大家信任，于是可以将身份信息和公钥发送给受信任的 CA2，获得自己的数字证书
CA1 在给其他人签署数字证书时，会在后面附上自己的数字证书
这样接受者首先利用 CA2 的公钥验证 CA1，获得 CA1 的公钥后再验证发送者
这样逐级签署数字证书，形成了一条信任链
最终的根节点就是自签名证书，如 CA2 可以用自己的私钥把自己的公钥和域名加密，生成证书
网友评论