【HTTPS】—— HTTPS协议原理详解
目录
(一)Https是什么
HTTPS 也是⼀个应用层协议. 是在 HTTP 协议的基础上引⼊了⼀个加密层.HTTP 协议内容都是按照文本的方式明文传输的. 这就导致在传输过程中出现⼀些被篡改的情况.
1.1 什么是加密
加密就是把 明文 (要传输的信息)进行⼀系列变换, ⽣成密文 .解密就是把 密文 再进行⼀系列变换, 还原成明文.
- 在这个加密和解密的过程中, 往往需要⼀个或者多个中间的数据, 辅助进行这个过程, 这样的数据称为密钥
1.2 为什么要加密
臭名昭著的 "运营商劫持"
HTTPS 就是在 HTTP 的基础上进行了加密, 进⼀步的来保证用户的信息安全~
1.3 常见的加密方式
- 采用单钥密码系统的加密方法,同⼀个密钥可以同时用作信息的加密和解密,这种加密方法称为对称加密,也称为单密钥加密,特征:加密和解密所用的密钥是相同的
- 常见对称加密算法(了解):DES、3DES、AES、TDEA、Blowfish、RC2等
- 特点:算法公开、计算量小、加密速度快、加密效率⾼
⼀个简单的对称加密, 按位异或假设 明文 a = 1234, 密钥 key = 8888则加密 a ^ key 得到的密文 b 为 9834.然后针对密文 9834 再次进行运算 b ^ key, 得到的就是原来的明文 1234.(对于字符串的对称加密也是同理, 每⼀个字符都可以表示成⼀个数字)当然, 按位异或只是最简单的对称加密. HTTPS 中并不是使用按位异或.
🔥 非对称加密
- 需要两个密钥来进行加密和解密,这两个密钥是公开密钥(public key,简称公钥)和私有密钥 (private key,简称私钥)。
- 常见非对称加密算法(了解):RSA,DSA,ECDSA
- 特点:算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂,而使得加密解密速度没有对称加密解密的速度快。
💨💨 非对称加密要用到两个密钥, ⼀个叫做 "公钥", ⼀个叫做 "私钥"
- 通过公钥对明文加密, 变成密文
- 通过私钥对密文解密, 变成明文
- 通过私钥对明文加密, 变成密文
- 通过公钥对密文解密, 变成明文
非对称加密的数学原理比较复杂, 涉及到⼀些 数论 相关的知识. 这⾥举⼀个简单的⽣活上的例子.A 要给 B ⼀些重要的文件, 但是 B 可能不在. 于是 A 和 B 提前做出约定:B 说: 我桌子上有个盒子, 然后我给你⼀把锁, 你把文件放盒子⾥用锁锁上, 然后我回头拿着钥匙来开锁取文件.在这个场景中, 这把锁就相当于公钥, 钥匙就是私钥. 公钥给谁都行(不怕泄露), 但是私钥只有 B 自己持有. 持有私钥的人才能解密.
1.4 数据摘要 && 数据指纹
- 数字指纹(数据摘要),其基本原理是利用单向散列函数(Hash函数)对信息进行运算,⽣成⼀串固定长度的数字摘要。数字指纹并不是⼀种加密机制,但可以用来判断数据有没有被窜改。
- 摘要常见算法:有MD5、SHA1、SHA256、SHA512等,算法把⽆限的映射成有限,因此可能会有碰撞(两个不同的信息,算出的摘要相同,但是概率⾮常低)
- 摘要特征:和加密算法的区别是,摘要严格意义不是加密,因为没有解密,只不过从摘要很难反推原信息,通常用来进行数据对⽐
(二)Https工作过程研究
方案一:只使用对称秘钥
比较理想的做法, 就是能在客户端和服务器建⽴连接的时候, 双方协商确定这次的密钥是啥~
但是如果直接把密钥明文传输, 那么⿊客也就能获得密钥了~~ 此时后续的加密操作就形同虚设了.
方案二:只使用非对称秘钥
方案三:双方都使用非对称秘钥
方案四:非对称秘钥 + 对称秘钥
- 服务端具有⾮对称公钥S和私钥S'
- 客户端发起https请求,获取服务端公钥S
- 客户端在本地生成对称密钥C, 通过公钥S加密, 发送给服务器.
- 由于中间的网络设备没有私钥, 即使截获了数据, 也⽆法还原出内部的原文, 也就⽆法获取到对称密钥(真的吗?)
- 服务器通过私钥S'解密, 还原出客户端发送的对称密钥C. 并且使用这个对称密钥加密给客户端返回的响应数据.
- 后续客户端和服务器的通信都只用对称加密即可. 由于该密钥只有客⼾端和服务器两个主机知道, 其他主机/设备不知道密钥即使截获数据也没有意义.
由于对称加密的效率比非对称加密⾼很多, 因此只是在开始阶段协商密钥的时候使用非对称加密, 后续的传输仍然使用对称加密.
🔥 中间人攻击 - 针对上面的场景
- 1. 服务器具有非对称加密算法的公钥S,私钥S'
- 2. 中间人具有非对称加密算法的公钥M,私钥M'
- 3. 客户端向服务器发起请求,服务器明文传送公钥S给客户端
- 4. 中间人劫持数据报文,提取公钥S并保存好,然后将被劫持报⽂中的公钥S替换成为自己的公钥M,并将伪造报文发给客户端
- 5. 客户端收到报文,提取公钥M(⾃⼰当然不知道公钥被更换过了),自己形成对称秘钥X,用公钥M加密X,形成报文发送给服务器
- 6. 中间人劫持后,直接用自己的私钥M'进行解密,得到通信秘钥X,再用曾经保存的服务端公钥S加密后,将报文推送给服务器
- 7. 服务器拿到报文,用自己的私钥S'解密,得到通信秘钥X
- 8. 双方开始采用X进行对称加密,进行通信。但是⼀切都在中间人的掌握中,劫持数据,进行窃听甚至修改,都是可以的
🔥 引入证书
- 证书发布机构
- 证书有效期
- 公钥
- 证书所有者
- 签名
🔥 理解数据签名
方案五:非对称秘钥 + 对称秘钥 + 证书认证
在客户端和服务器刚⼀建立连接的时候, 服务器给客户端返回⼀个 证书,证书包含了之前服务端的公钥, 也包含了网站的身份信息.
- 判定证书的有效期是否过期
- 判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构).
- 验证证书是否被篡改: 从系统中拿到该证书发布机构的公钥, 对签名解密, 得到⼀个 hash 值(称为数据摘要), 设为 hash1. 然后计算整个证书的 hash 值, 设为 hash2. 对比 hash1 和 hash2 是否相等. 如果相等, 则说明证书是没有被篡改过的
🔥 查看浏览器的受信任证书发布机构
- Chrome 浏览器, 点击右上角的;
- 选择 "设置", 搜索 "证书管理" , 即可看到以下界面. (如果没有,在隐私设置和安全性->安全里面找找)
🔥 中间人有没有可能篡改该证书?
- 中间人篡改了证书的明文
- 由于他没有CA机构的私钥,所以无法hash之后用私钥加密形成签名,那么也就没法办法对篡改后的证书形成匹配的签名
- 如果强行篡改,客户端收到该证书后会发现明文和签名解密后的值不⼀致,则说明证书已被篡改,证书不可信,从而终止向服务器传输信息,防止信息泄露给中间人
🔥 中间人整个掉包证书?
- 因为中间人没有CA私钥,所以无法制作假的证书(为什么?)
- 所以中间人只能向CA申请真证书,然后用自己申请的证书进行掉包
- 这个确实能做到证书的整体掉包,但是别忘记,证书明文中包含了域名等服务端认证信息,如果整体掉包,客户端依旧能够识别出来。
- 永远记住:中间人没有CA私钥,所以对任何证书都无法进行合法修改,包括自己的
完整流程
总结
HttpS 工作过程中涉及到的密钥有三组.
- 第⼀组(非对称加密): 用于校验证书是否被篡改. 服务器持有私钥(私钥在形成CSR⽂件与申请证书时获得), 客户端持有公钥(操作系统包含了可信任的 CA 认证机构有哪些, 同时持有对应的公钥). 服务器在客户端请求是,返回携带签名的证书. 客⼾端通过这个公钥进行证书验证, 保证证书的合法性,进⼀步保 证证书中携带的服务端公钥权威性。
- 第⼆组(非对称加密): 用于协商生成对称加密的密钥. 客户端用收到的CA证书中的公钥(是可被信任的)给随机生成的对称加密的密钥加密, 传输给服务器, 服务器通过私钥解密获取到对称加密密钥.
- 第三组(对称加密): 客户端和服务器后续传输的数据都通过这个对称密钥加密解密.
- 第⼆组非对称加密的密钥是为了让客户端把这个对称密钥传给服务器.
- 第⼀组非对称加密的密钥是为了让客户端拿到第二组非对称加密的公钥.
原文地址:https://blog.csdn.net/m0_56069910/article/details/142415716
免责声明:本站文章内容转载自网络资源,如本站内容侵犯了原著者的合法权益,可联系本站删除。更多内容请关注自学内容网(zxcms.com)!