前瞻
HTTP与HTTPS的关系
HTTPS也是一个在应用层的协议,是在HTTP协议基础上的一个加密解密层
明文 密文 秘钥
明文->秘钥 加密
秘钥->明文 解密
例如:明文为7 秘钥为2 7^2=101=5; 5就是密文
例子:
因为http的内容是明文传输的,明文数据会经过路由器、wifi热点、通信服务运营商、代理服务器等多个物理节点,如果信息在传输过程中被劫持,传输的内容就完全暴露了。劫持者还可以篡改传输的信息且不被双方察觉,这就是 中间人攻击,所以我们才需要对信息进行加密。
常见的加密方式
对称加密:
单秘钥加密,加密和解密所用秘钥相同
DES 3DES AES
特点:加密效率高,加密快,计算小
非对称加密:
双密钥加密 :公开秘钥 私有秘钥
DSA RSA
我们可以将明文使用公开秘钥加密,再用私有秘钥解密
也能加个明文使用私钥加密,公钥解密
特点:算法强度复杂 运算速度非常慢
数据摘要&&数据指纹
对数据采用类如哈希和MD5方法变成散列值
应用场景: 百度云盘秒传 当我们传入一部电影时,会先形成数据指纹,一旦百度云盘对比指纹成功,就会形成一个指向性文件,指向别人已经上传好的文件
我们来设计https
提出方案,发现方案问题
方案一:双方只用对称秘钥:
中间人也能拿到公钥,当客户端发送请求时,中间人能直接用公钥解密
方案二:双方只用非对称加密:
中间人无法拿公钥解密,只有服务器能用私钥解密,貌似是安全的,但是服务端向给客户端回应呢,服务端用私钥加密,但是中间人不也可以用公钥解密,用公钥加密,客户端又无法解密
方案三:双方都用非对称加密
服务器有一对非对称秘钥 公钥S 私钥S*
客户端有一对非对称秘钥 公钥C 私钥C*
双方交换公钥 此时中间人,客户端,服务端都有S C 客户端和服务端额外有自己的 S* C*
当客户端用S加密request 只有服务器能用S*解密,没问题,中间人无法解密
服务端进行响应,用客户端的公钥C加密,只有客户端能用自己的私钥C*解密,中间人也无法解密
看起来无懈可击,但是非对称加密运算速度非常慢,可能导致响应到零点几秒
并且依旧有安全问题
但数据只值10元钱。但是我们用100去破密,此时可以说我们是加密是安全的
方案四:用非对称加密与对称加密
服务器拥有S S* ,客户端拥有公钥P,服务端发给客户端S,此时我们得让服务端知道P,但不能让中间人知道P,此时就用S+P发给服务端,只有服务端能用S*解密得到公钥P,此后只用对称秘钥进行通信。
既解决速度问题,又解决了安全问题
即使市面上HTTPS60%都是这种方案,但是还是有问题
我们试着作为攻击这个方案
我们作为中间人一直都是被动处理信息,但是我们是可以主动发起攻击的,假设此时中间人也拥有了非对称私钥M M*
我们可以在客户端向服务端获取公钥S的时候就发起攻击,直接将S换成M,假装无事发生发送给客户端,客户端再用M加密对称秘钥C,此时客户端发送给服务端C+M,此时中间人截获,可以直接用M*截取C,之前,我们中间人客户端服务端都是不知道我们的存在的,我们肯定要一直待在暗处,此时就不能傻乎乎的把C+M发送给服务器,因为一旦发生C+M,服务器解密不出来C,就发现了我们的存在,此时我们就又要假装无事发生的将之前获取S,对C+S发送给服务器,让服务器以为只有自己知道了C。
同理在上面我们提到双方都用非对称加密也是有安全问题的,我们直接将S截获换成M,把服务器骗了,当客户端发送req+M时,中间人就可以解密了
这个问题,在于我们客户端太单纯了,一有坑就跳。
此时我们就得引入证书了
申请https证书-CSDN博客
解决:方案五
浏览器/client内置CA权威机构的公钥+证书(server的公钥)+非对称+对称= 方案5