HTTPS

2019-04-02

对称加密

1
2
3
4
A -> 文件 -> 放入密码箱,秘钥加密 -> B -> 拿到密码箱,秘钥解密 -> 文件
存在的问题 : A如何将密码箱的秘钥安全的告诉B

DES、AES-GCM ...

非对称加密

1
2
3
4
5
6
公钥加密,私钥解密
私钥签名,公钥验证
用公钥加密的数据只有对应的私钥可以解密
用私钥加密的数据只有对应的公钥可以解密
如果可以用公钥解密,则必然是对应的私钥加的密
如果可以用私钥解密,则必然是对应的公钥加的密
1
2
3
4
5
A -> 文件 -> 用B的公钥加密 -> B -> B用自己的私钥解密 -> 文件
B -> 文件 -> 用A的公钥加密 -> A -> A用自己的私钥解密 -> 文件
存在的问题 : 非对称性加密算法加密解密时间比对称加密算法长的多

RSA、DSA、ECDSA ....

非对称+对称加密

1
2
3
4
5
B -> 设置密码箱秘钥 -> 用A的公钥对秘钥加密 -> A -> A用A的私钥解密,得到密码箱的秘钥
用非对称性加密算法传递对称加密的秘钥, 之后A-B互相通信就用对称加密进行通信

存在的问题 : 中间人X的攻击 , B没办法知道拿到的公钥确实是A的公钥
A给B发送公钥时被X截取,X将A的公钥替换为自己的公钥发送给B, B用X的公钥加密,X截取B发送的内容用X的私钥解密查看或修改内容后,X用A的公钥加密内容发送给A.

信息摘要

1
2
3
4
5
6
A将自己的公钥及个人信息计算信息摘要后一并发送给B,B收到消息后计算信息摘要进行对比看收到的消息是否被中间人篡改

存在的问题 : 中间人X , 可能把信息摘要都一并篡改发送给B
即B没办法知道收到的信息摘要一定是A的消息的消息摘要

MD5、SHA-1、SHA-2、SHA-256

认证中心

1
2
3
4
5
6
A将自己的公钥及个人信息 -> 计算信息摘要 -> 信息摘要用CA私钥加密 -> 数字签名
A的公钥及个人信息 + 数组签名 -> A的数字证书
A将自己的数字证书 -> B -> B将数字证书中A的公钥及个人信息计算信息摘要
B -> B用CA的公钥对数字证书的数字签名解密得到信息摘要 进行对比

操作系统/浏览器中内置了CA的数字证书

HTTPS

1
2
3
4
5
6
7
8
B 用 https 访问 A 时, A 首先将自己的数字证书发送 B
B 内置的CA数字证书中对发送过来的数字证书进行验证,查看其是否真的是A的数字证书
B 验证通过后,生成 秘钥(对称加密的秘钥) , 将秘钥用A的数字证书中A的公钥进行加密 , 发送给A
A 收到后用A的私钥进行机密到的到 秘钥(对称加密的秘钥)
A-B 之间随后通过对称加密进行通信

上述过程是TLS(SSL)的简版
Client-Hello Server-Hello