1 一个中间人攻击的案例 : 点外卖 , 截取 , 回假消息要求银行卡和密码 , 再截取
2 非对称 , 公钥加密私钥解密 , 私钥加密公钥解密
3 对称算法效率更高
4 如果只有双方知道对称秘钥 , 完全OK , 但是要如何约定好对称秘钥
5 用谍战剧做比喻 , 偷偷交换”密码本”
6 私钥只会存在外卖服务器里
7 公钥是可以传播的
8 公钥加密->黑客不能解密->服务器可以解密->私钥加密不行,会被黑客解密,公钥加密也不行,谁也解密不了
9 一对公钥私钥不够用 , 客户端也要有一对 , 并且把公钥给服务器
10 客户端和服务器都不能保证双方发的公钥是对的 , 可能被中间人替换了
11 所以需要数字证书 , 由权威机构认证 , 称为CA Certificate Authority
12 创建私钥
image.png
13 创建公钥
image.png
14 创建证书请求 , 证书请求用来发给CA , 生成证书
image.png
15 CA会对证书盖章 , 称为签名算法
16 怎么确定盖章是真的CA盖的呢? 用CA的私钥盖(签名)的章
17 CA如何签名的 ? 先对信息做hash , 然后把hash作为签名和信息一起发出去 (这里不太懂啊?)
18 可以自己给自己签名? 权威机构呢?
image.png
19 查看证书内容的方法
image.png
20 Issuer是颁发者,Subject是被授予者 , Validity是有限期 , Public-key是公钥 , Signature Algorithm是签名算法
21 于是公钥获取过程就转为从外卖网站拿到一个证书 , 然后用CA的公钥解密证书 , 并且验证签名 , 都对上了则可以保证是对的公钥 (还是不太清楚?) , 再说一下 , 大概就是CA先用xx算法进行哈希 ,然后私钥加密 , 客户用公钥解密 , 然后根据证书上的哈希算法对信息哈希 , 看看签名能否对上
22 CA的公钥也可能是假的 , 所以需要层层CA的背书 .
23 还真的可以自己给自己签名啊
24 非对称和对称的结合 : 非对称传输对称秘钥 , 然后对称用于后续传输
25 一张https时序图 , 仔细看写下自己的理解 ?
26 客户端先发送加密方法和随机数 , 服务端也返回它的加密方法和随机数 , 然后发送证书 , 结束
27 客户端开始校验证书 , 产生第三个随机数pre-master , 用服务器公钥加密后发给服务器 , 所以第三个随机数不会泄露
28 用3个随机数算出对称秘钥 , 切换传输方式为对称加密 , 测试 , 通过后和HTTP一样
29 疑问: 前面的两个随机数有什么作用? 都是明文传的 , 可能是减少后面3个随机数生成的随机数冲突的几率吧 , 毕竟第三个怎么也不会泄露
30 TLS协议?
31 上面这个说的是单向认证 , 还可以双向认证 , 岂不更复杂?
32 重放问题? 篡改问题? 不是很懂
33 什么是Nonce随机数
34 用timestamp+nonce随机数做不可逆的hash , 用于服务器判断唯一请求 , 防止黑客重放 , 篡改时间戳会被签名识破
35 HTTPS太复杂 , 有效率问题 , 有哪些其他手段可以解决吗?
36 如何信任CA ? 有这样一个比喻, 你想确认区公安局的电话号码 , 你可以去市公安局确认 , 信不过还可以去省公安局 , 一级一级背书 , 总有一个你信任的 电话号码=公钥 , 公钥在证书里
网友评论