|
| 1 | +<!-- TOC --> |
| 2 | + |
| 3 | +- [1. SSL 与 TLS](#1-ssl-%E4%B8%8E-tls) |
| 4 | +- [2. 从网络协议的角度理解 HTTPS](#2-%E4%BB%8E%E7%BD%91%E7%BB%9C%E5%8D%8F%E8%AE%AE%E7%9A%84%E8%A7%92%E5%BA%A6%E7%90%86%E8%A7%A3-https) |
| 5 | +- [3. 从密码学的角度理解 HTTPS](#3-%E4%BB%8E%E5%AF%86%E7%A0%81%E5%AD%A6%E7%9A%84%E8%A7%92%E5%BA%A6%E7%90%86%E8%A7%A3-https) |
| 6 | + - [3.1. TLS 工作流程](#31-tls-%E5%B7%A5%E4%BD%9C%E6%B5%81%E7%A8%8B) |
| 7 | + - [3.2. 密码基础](#32-%E5%AF%86%E7%A0%81%E5%9F%BA%E7%A1%80) |
| 8 | + - [3.2.1. 伪随机数生成器](#321-%E4%BC%AA%E9%9A%8F%E6%9C%BA%E6%95%B0%E7%94%9F%E6%88%90%E5%99%A8) |
| 9 | + - [3.2.2. 消息认证码](#322-%E6%B6%88%E6%81%AF%E8%AE%A4%E8%AF%81%E7%A0%81) |
| 10 | + - [3.2.3. 数字签名](#323-%E6%95%B0%E5%AD%97%E7%AD%BE%E5%90%8D) |
| 11 | + - [3.2.4. 公钥密码](#324-%E5%85%AC%E9%92%A5%E5%AF%86%E7%A0%81) |
| 12 | + - [3.2.5. 证书](#325-%E8%AF%81%E4%B9%A6) |
| 13 | + - [3.2.6. 密码小结](#326-%E5%AF%86%E7%A0%81%E5%B0%8F%E7%BB%93) |
| 14 | + - [3.3. TLS 使用的密码技术](#33-tls-%E4%BD%BF%E7%94%A8%E7%9A%84%E5%AF%86%E7%A0%81%E6%8A%80%E6%9C%AF) |
| 15 | + - [3.4. TLS 总结](#34-tls-%E6%80%BB%E7%BB%93) |
| 16 | +- [4. RSA 简单示例](#4-rsa-%E7%AE%80%E5%8D%95%E7%A4%BA%E4%BE%8B) |
| 17 | +- [5. 参考](#5-%E5%8F%82%E8%80%83) |
| 18 | + |
| 19 | +<!-- TOC --> |
| 20 | + |
| 21 | +# 1. SSL 与 TLS |
| 22 | + |
| 23 | +SSL:(Secure Socket Layer) 安全套接层,于 1994 年由网景公司设计,并于 1995 年发布了 3.0 版本 |
| 24 | +TLS:(Transport Layer Security)传输层安全性协议,是 IETF 在 SSL3.0 的基础上设计的协议 |
| 25 | +以下全部使用 TLS 来表示 |
| 26 | + |
| 27 | +# 2. 从网络协议的角度理解 HTTPS |
| 28 | + |
| 29 | +![此图并不准确][1] |
| 30 | +HTTP:HyperText Transfer Protocol 超文本传输协议 |
| 31 | +HTTPS:Hypertext Transfer Protocol Secure 超文本传输安全协议 |
| 32 | +TLS:位于 HTTP 和 TCP 之间的协议,其内部有 TLS握手协议、TLS记录协议 |
| 33 | +HTTPS 经由 HTTP 进行通信,但利用 TLS 来保证安全,即 HTTPS = HTTP + TLS |
| 34 | + |
| 35 | +# 3. 从密码学的角度理解 HTTPS |
| 36 | + |
| 37 | +HTTPS 使用 TLS 保证安全,这里的“安全”分两部分,一是传输内容加密、二是服务端的身份认证 |
| 38 | + |
| 39 | +## 3.1. TLS 工作流程 |
| 40 | + |
| 41 | +![此图并不准确][2] |
| 42 | +此为服务端单向认证,还有客户端/服务端双向认证,流程类似,只不过客户端也有自己的证书,并发送给服务器进行验证 |
| 43 | + |
| 44 | +## 3.2. 密码基础 |
| 45 | + |
| 46 | +### 3.2.1. 伪随机数生成器 |
| 47 | + |
| 48 | +为什么叫伪随机数,因为没有真正意义上的随机数,具体可以参考 Random/TheadLocalRandom |
| 49 | +它的主要作用在于生成对称密码的秘钥、用于公钥密码生成秘钥对 |
| 50 | + |
| 51 | +### 3.2.2. 消息认证码 |
| 52 | + |
| 53 | +消息认证码主要用于验证消息的完整性与消息的认证,其中消息的认证指“消息来自正确的发送者” |
| 54 | + |
| 55 | +>消息认证码用于验证和认证,而不是加密 |
| 56 | +
|
| 57 | +![消息认证码过程][3] |
| 58 | + |
| 59 | +1. 发送者与接收者事先共享秘钥 |
| 60 | +2. 发送者根据发送消息计算 MAC 值 |
| 61 | +3. 发送者发送消息和 MAC 值 |
| 62 | +4. 接收者根据接收到的消息计算 MAC 值 |
| 63 | +5. 接收者根据自己计算的 MAC 值与收到的 MAC 对比 |
| 64 | +6. 如果对比成功,说明消息完整,并来自与正确的发送者 |
| 65 | + |
| 66 | +### 3.2.3. 数字签名 |
| 67 | + |
| 68 | +消息认证码的缺点在于**无法防止否认**,因为共享秘钥被 client、server 两端拥有,server 可以伪造 client 发送给自己的消息(自己给自己发送消息),为了解决这个问题,我们需要它们有各自的秘钥不被第二个知晓(这样也解决了共享秘钥的配送问题) |
| 69 | + |
| 70 | +![数字签名过程][4] |
| 71 | + |
| 72 | +>数字签名和消息认证码都**不是为了加密** |
| 73 | +>可以将单向散列函数获取散列值的过程理解为使用 md5 摘要算法获取摘要的过程 |
| 74 | +
|
| 75 | +使用自己的私钥对自己所认可的消息生成一个该消息专属的签名,这就是数字签名,表明我承认该消息来自自己 |
| 76 | +注意:**私钥用于加签,公钥用于解签,每个人都可以解签,查看消息的归属人** |
| 77 | + |
| 78 | +### 3.2.4. 公钥密码 |
| 79 | + |
| 80 | +公钥密码也叫非对称密码,由公钥和私钥组成,它是最开始是为了解决秘钥的配送传输安全问题,即,我们不配送私钥,只配送公钥,私钥由本人保管 |
| 81 | +它与数字签名相反,公钥密码的私钥用于解密、公钥用于加密,每个人都可以用别人的公钥加密,但只有对应的私钥才能解开密文 |
| 82 | +client:明文 + 公钥 = 密文 |
| 83 | +server:密文 + 私钥 = 明文 |
| 84 | +注意:**公钥用于加密,私钥用于解密,只有私钥的归属者,才能查看消息的真正内容** |
| 85 | + |
| 86 | +### 3.2.5. 证书 |
| 87 | + |
| 88 | +证书:全称公钥证书(Public-Key Certificate, PKC),里面保存着归属者的基本信息,以及证书过期时间、归属者的公钥,并由认证机构(Certification Authority, **CA**)施加数字签名,表明,某个认证机构认定该公钥的确属于此人 |
| 89 | + |
| 90 | +>想象这个场景:你想在支付宝页面交易,你需要支付宝的公钥进行加密通信,于是你从百度上搜索关键字“支付宝公钥”,你获得了支什宝的公钥,这个时候,支什宝通过中间人攻击,让你访问到了他们支什宝的页面,最后你在这个支什宝页面完美的使用了支什宝的公钥完成了与支什宝的交易 |
| 91 | +>![证书过程][5] |
| 92 | +
|
| 93 | +在上面的场景中,你可以理解支付宝证书就是由支付宝的公钥、和给支付宝颁发证书的企业的数字签名组成 |
| 94 | +任何人都可以给自己或别人的公钥添加自己的数字签名,表明:我拿我的尊严担保,我的公钥/别人的公钥是真的,至于信不信那是另一回事了 |
| 95 | + |
| 96 | +### 3.2.6. 密码小结 |
| 97 | + |
| 98 | +| 密码 | 作用 | 组成 | |
| 99 | +| :-- | :-- | :-- | |
| 100 | +| 消息认证码 | 确认消息的完整、并对消息的来源认证 | 共享秘钥+消息的散列值 | |
| 101 | +| 数字签名 | 对消息的散列值签名 | 公钥+私钥+消息的散列值 | |
| 102 | +| 公钥密码 | 解决秘钥的配送问题 | 公钥+私钥+消息 | |
| 103 | +| 证书 | 解决公钥的归属问题 | 公钥密码中的公钥+数字签名 | |
| 104 | + |
| 105 | +## 3.3. TLS 使用的密码技术 |
| 106 | + |
| 107 | +1. 伪随机数生成器:秘钥生成随机性,更难被猜测 |
| 108 | +2. 对称密码:对称密码使用的秘钥就是由伪随机数生成,相较于非对称密码,效率更高 |
| 109 | +3. 消息认证码:保证消息信息的完整性、以及验证消息信息的来源 |
| 110 | +4. 公钥密码:证书技术使用的就是公钥密码 |
| 111 | +5. 数字签名:验证证书的签名,确定由真实的某个 CA 颁发 |
| 112 | +6. 证书:解决公钥的真实归属问题,降低中间人攻击概率 |
| 113 | + |
| 114 | +## 3.4. TLS 总结 |
| 115 | + |
| 116 | +TLS 是一系列密码工具的框架,作为框架,它也是非常的灵活,体现在每个工具套件它都可以替换,即:客户端与服务端之间协商密码套件,从而更难的被攻破,例如使用不同方式的对称密码,或者公钥密码、数字签名生成方式、单向散列函数技术的替换等 |
| 117 | + |
| 118 | +# 4. RSA 简单示例 |
| 119 | + |
| 120 | +RSA 是一种公钥密码算法,我们简单的走一遍它的加密解密过程 |
| 121 | +加密算法:密文 = (明文^E) mod N,其中公钥为{E,N},即”求明文的E次方的对 N 的余数“ |
| 122 | +解密算法:明文 = (密文^D) mod N,其中秘钥为{D,N},即”求密文的D次方的对 N 的余数“ |
| 123 | +例:我们已知公钥为{5,323},私钥为{29,323},明文为300,请写出加密和解密的过程: |
| 124 | +>加密:密文 = 123 ^ 5 mod 323 = 225 |
| 125 | +>解密:明文 = 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 |
| 126 | +
|
| 127 | +# 5. 参考 |
| 128 | + |
| 129 | +1. SSL加密发生在哪里:<https://security.stackexchange.com/questions/19681/where-does-ssl-encryption-take-place> |
| 130 | +2. TLS工作流程:<https://blog.csdn.net/ustccw/article/details/76691248> |
| 131 | +3. 《图解密码技术》:<https://book.douban.com/subject/26822106/> 豆瓣评分 9.5 |
| 132 | + |
| 133 | +[1]: https://leran2deeplearnjavawebtech.oss-cn-beijing.aliyuncs.com/somephoto/%E4%B8%83%E5%B1%82.png |
| 134 | +[2]: https://leran2deeplearnjavawebtech.oss-cn-beijing.aliyuncs.com/somephoto/tls%E6%B5%81%E7%A8%8B.png |
| 135 | +[3]: https://leran2deeplearnjavawebtech.oss-cn-beijing.aliyuncs.com/somephoto/%E6%B6%88%E6%81%AF%E8%AE%A4%E8%AF%81%E7%A0%81%E8%BF%87%E7%A8%8B.png |
| 136 | +[4]: https://leran2deeplearnjavawebtech.oss-cn-beijing.aliyuncs.com/somephoto/%E6%95%B0%E5%AD%97%E7%AD%BE%E5%90%8D%E8%BF%87%E7%A8%8B.png |
| 137 | +[5]: https://leran2deeplearnjavawebtech.oss-cn-beijing.aliyuncs.com/somephoto/dns%E4%B8%AD%E9%97%B4%E4%BA%BA%E6%94%BB%E5%87%BB.png |
0 commit comments