HTTPS
HTTPS 基于 HTTP , 只是比 HTTP 多了一个 “加密层”
为什么要有HTTPS ?
只要网络上的数据 是明文传输的 , 都是存在被劫持 , 被篡改的风险的
为了能够改善此问题 , 就引入了加密 , HTTPS就应运而生
HTTPS = HTTP + 加密层
加密
加密 就是把 明文 (要传输的信息) 进行一系列变换 , 生成密文
解密 就是把 密文 再进行一系列变换 , 还原成 明文
在这个加密和解密的过程中 , 往往需要一个或者多个中间的数据 , 辅助进行这个过程 . 这样的数据称为 密钥
对称加密 : 只有一个密钥 , key
明文 + key => 密文
密文 + key => 明文
加密和解密使用同一个密钥
HTTPS 基本工作过程
加密 : 针对 HTTP 的各种 header 和 body
使用对称密钥
当黑客侵入路由器 :
服务器对应的客户端有很多个 , 不是只有一个 , 不同的客户端 , 使用的密钥,是相同还是不同呢 ?
因此服务器就需要维护每个客户端和每个密钥之间的关联关系 , 这是非常麻烦的事情 , 比较理想的做法 , 就是能在客户端和服务器建立连接的时候 , 双方协商确定这次的密钥是什么 .
那此时 , 看来需要针对 key 也进行加密 , 难道生成一个 key2 , 使用 key2 来加密key , key2 也需要告诉服务器 , 谁来加密key2 ? 此时引入非对称加密
非对称加密
客户端是希望把自己的 key 安全的 传输给服务器 , 不被黑客拿到
客户端和服务器 的业务数据传输 , 仍然是使用对称加密的方式 .(对称加密速度快 ,成本低) , 为了保证对称密钥能够安全到达服务器 , 引入非对称加密 , 保护对称加密 , 非对称加密在对称密钥传输完成后 , 就可以不用了
中间人攻击
安全是 " 相对的 " .黑客也不是吃素的 , 黑客通过"偷袭" 的方式 , 如何放倒了客户端
中间人攻击 , 破解的关键 , 在于让客户端能够信任公钥
引入证书
在客户端和服务器刚一建立连接的时候 , 服务器就给客户端返回一个证书
这个证书包含了刚才的公钥 , 也包含了网站的身份信息
证书 :
服务器的url
证书的过期时间
颁布证书的机构
服务器自己的公钥pub
…
加密后的签名 : 先针对证书的所有属性 , 计算一个校验和(签名) , 再由证书颁布机构,使用自己的私钥对于这个签名进行加密
客户端拿到证书后 , 就首先需要针对证书进行校验 !
- 得到初始的签名 : 客户端使用系统中内置的权威机构的公钥 pub2 ,针对上述证书中的 加密签名进行解密 , 得到了初始签名(这个签名是权威机构算出来的)(设为sum1)
- 计算现在的签名 : 客户端使用同样的签名计算 算法 , 基于证书中的属性重新计算 , 得到sum2
- 比较两个签名是否相同 , 如果相同 , 说明证书中的数据都是未被篡改的原始数据 . 如果签名不相同 . 说明证书的数据被篡改过 , 客户端的浏览器弹框报错
为什么说 黑客不能篡改了呢 ?
如果黑客要篡改 :
- 黑客把证书中的服务器的公钥pub , 替换成自己的公钥
- 黑客针对证书的各个属性, 重新计算签名
- 黑客需要把签名 , 重新加密 , 要想加密 , 务必需要知道权威机构的私钥pri2 ,然而 , 黑客不知道pri2
**此处安全的关键 , 不是黑客 " 看不到" , 而是黑客 " 改不了" **
总结
HTTPS 工作过程中涉及的密钥有三组
第一组(非对称加密) : 用于校验证书是否被篡改 , 服务器持有私钥(私钥在注册证书时获得),客户端持有公钥(操作系统包含了可信任的CA认证机构有哪些,同时持有对应的公钥).服务器使用这个私钥对证书的签名进行加密 . 客户端通过这个公钥解密获取到证书的签名, 从而校验证书内容是否经过篡改
第二组(非对称加密) : 用于协商生成对称加密的密钥 . 服务器生成这组 私钥-公钥 对 , 然后通过证书吧公钥传递给客户端 , 然后客户端用这个公钥给生成的对称加密的密钥加密 , 传输给服务器 , 服务器通过私钥解密获取到对称加密密钥
第三组(对称加密) : 客户端和服务器后续传输的数据都通过这个对称密钥加密解密
其实一切的关键都是围绕这个对称加密的密钥 . 其他的机制都是辅助这个密钥工作的
第二组非对称加密的密钥就是为了让客户端把这个对称密钥传给服务器
第一组非对称加密的密钥是为了让客户端拿到第二组非对称加密的公钥