基础概念
https也是一个应用层协议,是在http协议上基础上添加保密层(TLS/SSL,对数据进行加密,解密)
加密 就是明文变密文
解密就是密文变明文
中间人攻击
如运营商替换下载链接, 钓鱼wifi, 钓鱼热点等位于client与server中间的第三者进行的攻击
常见加密方式
对称加密
加密解密用相同密钥
加密速度快,效率高
DES,RC2
非对称加密
两个密钥进行加密/解密
可以公钥加密/私钥解密
也可以私钥加密/公钥解密
++不能只用一个钥同时加密/解密++
数据摘要 && 数据指纹
图片
两者是同意思
不是加密机制(没有解密方法),但可以用来判断数据有无篡改(即使修改了一个比特位,数据摘要也会发生巨大变化
原理是使用单向散列函数(hash)对信息进行运算,生成固定长度数字摘要
为什么说数据摘要具有唯一性?
既然数据摘要是定长且唯一的,那么当数据非常大时,不违反抽屉原理(鸽巢原理)么?
实际上是有可能碰撞的,但两者(源数据和被修改后的数据)数据摘要的碰撞概率极低,我们就认为不会碰撞,即视为数据摘要是唯一的
例如非常常用的SHA-256方法,无论输入数据大小如何,都输出256位(32字节)的摘要值,两个不同数据的碰撞概率仅为2^-128,几乎不可能。
数据摘要的应用
应用1:云盘的"云秒传功能"
百度云盘把所有资源都形成各自数据摘要,用户如要上传的资源的数字摘要已经存在,服务器直接把其他用户相同资源保存在此用户网盘上
应用2:数据库保存用户账号与密码
数据库中不可直接存储密码的明文,应存储数据摘要,通过比较数据摘要来对比密码是否正确
四种加密方案:
1.只使用对称加密
server端如何得知密钥?
方案一只使用对称加密不可行:不能保证密钥安全传输
2.只使用非对称加密
服务器将公钥给client,自己持有私钥
貌似client->server安全
但server->client不安全
方案2:
++貌似++ 保证单向数据安全
通信速度非常慢
3.双方都使用非对称加密
方案3:
++貌似++ 两方向都安全
通信速度比较慢
4.非对称加密+对称加密
使用非对称加密保证对称加密密钥的安全传输,之后都使用对称加密
++看起来++ 很安全,完善,但和方案2/3一样,都有漏洞
之所以使用单词"貌似安全",是指实际上也不安全。2/3/4加密方案的相同漏洞( 上述"貌似正确"部分的安全漏洞**)**,可见下"中间人攻击"
中间人攻击
站在中间人(攻击者)角度分析安全问题(寻找安全漏洞)
2/3/4方案问题在哪:client不知道密钥是否合法
CA证书与签名
签名
只有本人有私钥,也就意味着只有本人有对数据进行签名的能力
所有客户端都内置信任的CA机构的公钥(用来解析证书)
签名者:CA机构
证书只能由只能CA机构颁发,server颁发/生成不了证书
client第一次请求,得到的结果,不仅有公钥。实际上,得到的是证书。证书包含密钥,是++明文信息++ 。证书使用签名来保证证书完整性与不被修改。
证书图片\]:  #### 签名+非对称加密+对称加密 配合关系 总的来说,签名和非对称加密就是为了保证client的**对称密钥安全地传输给server** ##### 签名保证证书完整性 保证server公钥不被中间人掉包 中间人无法在不被发现情况下对证书进行篡改,因为没有CA私钥 ##### 非对称加密保证只有server收到client对称密钥 只有服务器拥有server私钥,所以只有服务器可以解密/真正收到client的密钥,防止中间人获取client密钥 ##### 使用client对称密钥通信 此时可保证只有client,server拥有client对称密钥,之后client与server即可使用对称密钥安全且快速通信 #### 签名为什么先hash再形成摘要,而不是直接对签名形成摘要? 缩小签名密文长度,加快数字签名的运算速度 ### HTTPS整体流程   ### 板书笔记 