济南网站建设工作,快速开发平台 免费开源,做网站效果图,定制 网站文章目录 1.https协议的介绍2. 加密和解密2.1 什么是加密2.2 常见的加密方式2.2.1 对称加密2.2.2 非对称加密 2.3 数据摘要#xff08;数据指纹#xff09;2.4 数字签名 3. https协议的加密和解密方案一#xff1a;使用对称加密#xff08;❌#xff09;方案二#xff1a… 文章目录 1.https协议的介绍2. 加密和解密2.1 什么是加密2.2 常见的加密方式2.2.1 对称加密2.2.2 非对称加密 2.3 数据摘要数据指纹2.4 数字签名 3. https协议的加密和解密方案一使用对称加密❌方案二使用非对称加密❌方案三双方都使用非对称加密❌方案四非对称加密对称加密❌中间人攻击问题证书CA认证方案五证书认证非对称加密对称加密✔️ 1.https协议的介绍
在上一篇博文中我们讲到了http协议发现http协议传输的所有内容就是明文的那么如果存在中间人在客户端和服务端之间的话中间人是完全可以看到客户端和服务端之间的传输报文内容的甚至可以篡改内容所以就出现了https协议。
https协议是在http协议的基础上引入了一个加密层。
2. 加密和解密
2.1 什么是加密
加密就是指把明文要传输的信息经过一系列的变化生成密文
解密就是把密文再经过一系列的变化还原成明文 举个例子假设我们想要传递一个变量a里面的值那么如果直接传输明文就会出现泄露的风险所以这个时候我们使用另一个变量key将key ^ a的值传输过去中间人不知道这个key所以就不会泄露对方是有这个key的所以对方拿到我们传输的结果再异或key也就是key ^ a ^ key那么最后的结果就还是a就能够让对方拿到真实的结果。 这个过程就类似加密和解密的过程其中的key就是密钥。当然真实的加密和解密不会有这么简单。
2.2 常见的加密方式
2.2.1 对称加密
采用单钥密码系统的加密方法同一密钥可以同时用作信息的加密和解密这种加密方法称为对称加密
对称加密的特征加密和解密的密钥是相同的常见对称对称加密算法(了解一下)DES、3DES、AES、TDEA、Blowfish、RC2等特点算法公开、计算量小、加密速度快、加密效率高
就像我们最开始举的例子把原文异或上key作为密文在使用key异或密文获取原文的过程就是使用对称加密的方式进行加密和解密
2.2.2 非对称加密
非对称加密需要两个密钥来进行加密和解密两个密钥分别是公开密钥public key公钥和私有密钥private key私钥 常见非对称加密算法(了解)RSADSAECDSA 非对称加密的特征算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂⽽使得加密解密速度没有对称加密解密的速度快。 公钥和私钥是配对的. 最⼤的缺点就是运算速度非常慢比对称加密要慢很多。公钥可以认为是一把锁私钥是锁的钥匙锁给谁都行但是只有持有私钥的人才能打开。 通过公钥对明文进行加密形成密文 通过私钥对密文进行解密得到明文
当然也可以反着用通过私钥加密公钥解密
2.3 数据摘要数据指纹 数字指纹(数据摘要),其基本原理是利⽤单向散列函数(Hash函数)对信息进⾏运算,⽣成⼀串固定⻓度的数字摘要。数字指纹并不是⼀种加密机制,但可以⽤来判断数据有没有被窜改如果对数据某个地方进行小小的改动重新生成的哈希摘要也和改动前的大不一样。 摘要常见算法有MD5、SHA1、SHA256、SHA512等算法把⽆限的映射成有限因此可能会有碰撞两个不同的信息算出的摘要相同但是概率非常低 摘要特征和加密算法的区别是摘要严格意义不是加密因为没有解密只不过从摘要很难反推原信息通常用来进行前后数据的对比观察数据是否被修改过也可以用于实现网盘的秒传功能、公司数据库密码存储等。 涉及到用户密码的字段都是要加密的。一般数据库中的密码字段长度是固定的便于设计表结构会将用户密码生成哈希摘要。每次用户登录时都将转换成哈希摘要与数据库的哈希摘要进行对比所以数据库泄露也不怕
2.4 数字签名
对摘要经过加密得到的就是数字签名。签名的形成是基于非对称加密算法。
3. https协议的加密和解密
在网络通信过程中我们需要解决的问题就是1. 数据被监听 2. 数据被篡改针对这个问题我们提出了解决方法当然解决方法可能是有问题的所以接下来就通过提出问题-解决问题的方式来讲解
方案一使用对称加密❌
如果在通信之前通信双方约定了一个密钥在通信的时候使用密钥把明文首先加密称为密文然后再发送密文这种方式就能够实现加密通信除非密钥被破解。 但是一台服务器将来可能面对多个客户端为了区分每个客户端的不同所以每个客户端的密钥肯定得不一样。那么服务器怎么知道每个客户端的密钥分别是什么所以提出的解决方案就是让每个客户端和服务端通信的时候会重新创建一个单独的密钥
但是如果只使用对称加密就没有办法解决让密钥如何让对方安全的收到的问题。
方案二使用非对称加密❌
非对称加密既可以使用公钥加密也可以使用私钥加密。但是使用公钥加密必须使用私钥解密使用私钥加密必须使用公钥解密。
考虑到非对称加密的机制如果服务器先把公钥以明文的方式传输给浏览器之后浏览器向服务器发送的数据都是用这个公钥加密然后再传输这样发送的就是密文了服务器收到使用公钥加密的密文之后使用私钥解密拿到明文这样似乎就保证了浏览器到服务器的通信安全那么反过来服务器到客户端呢
方案三双方都使用非对称加密❌
服务端拥有公钥S与对应的私钥S’客户端拥有公钥C与对应的私钥C’客户端与服务端交换公钥此时客户端拥有S和C’服务端拥有S’和C客户端给服务端发消息先使用S对数据加密再发送只能由服务端解密服务端给客户端发消息先使用C对数据加密再发送只能由客户端解密
这样似乎就解决问题了但是依然还有两个问题
效率太低还是有安全问题
方案四非对称加密对称加密❌
先解决效率问题 服务端具有⾮对称公钥S和私钥S’客⼾端发起https请求获取服务端公钥S客⼾端在本地⽣成对称密钥C,通过公钥S加密,发送给服务器.由于中间的⽹络设备没有私钥,即使截获了数据,也⽆法还原出内部的原⽂,也就⽆法获取到对称密钥(真的吗)服务器通过私钥S’解密,还原出客⼾端发送的对称密钥C.并且使⽤这个对称密钥加密给客⼾端返回的响应数据.后续客⼾端和服务器的通信都只⽤对称加密即可.由于该密钥只有客⼾端和服务器两个主机知道,其 他主机/设备不知道密钥即使截获数据也没有意义
但是上述的通信方式都会有一个共同的问题如果再最开始的时候中间人就已经开始攻击了怎么办
中间人攻击问题
确实在⽅案2/3/4中客⼾端获取到公钥S之后对客⼾端形成的对称秘钥X⽤服务端给客⼾端的公钥S进⾏加密中间⼈即使窃取到了数据此时中间⼈确实⽆法解出客⼾端形成的密钥X因为只有服务器有私钥S’
但是中间⼈的攻击如果在最开始握⼿协商的时候就进⾏了那就不⼀定了假设hacker已经成功成为中间⼈
服务器具有⾮对称加密算法的公钥S私钥S’中间⼈具有⾮对称加密算法的公钥M私钥M’客⼾端向服务器发起请求服务器明⽂传送公钥S给客⼾端中间⼈劫持数据报⽂提取公钥S并保存好然后将被劫持报⽂中的公钥S替换成为⾃⼰的公钥M并将伪造报⽂发给客⼾端客⼾端收到报⽂提取公钥M(⾃⼰当然不知道公钥被更换过了)⾃⼰形成对称秘钥X⽤公钥M加密X形成报⽂发送给服务器中间⼈劫持后直接⽤⾃⼰的私钥M’进⾏解密得到通信秘钥X再⽤曾经保存的服务端公钥S加密后将报⽂推送给服务器服务器拿到报⽂⽤⾃⼰的私钥S’解密得到通信秘钥X双⽅开始采⽤X进⾏对称加密进⾏通信。但是⼀切都在中间⼈的掌握中劫持数据进⾏窃听甚⾄修改都是可以的
上⾯的攻击⽅案同样适⽤于⽅案2⽅案3
问题本质出在哪⾥了呢客户端无法确定收到的含有公钥的数据报⽂就是目标服务器发送过来的
证书CA认证
服务端在使⽤HTTPS前需要向CA机构申领⼀份数字证书数字证书⾥含有证书申请者信息、公钥信息等。客户端向服务器请求公钥时服务器把证书传输给浏览器浏览器从证书里获取公钥就行了证书就如⾝份证是服务端公钥的身份证明 这个证书可以理解成是⼀个结构化的字符串, ⾥⾯包含了以下信息:证书发布机构、证书有效期、公钥、证书所有者、签名等
申请证书的时候需要在特定平台⽣成CSR同时⽣成公钥和私钥。这对密钥就是用来在⽹络通信中进行明文加密以及数字签名时使用的。
其中公钥会随着CSR⽂件⼀起发给CA进⾏权威认证私钥服务端自己保留后续用于通信使用主要就是⽤来交换对称密钥
数字签名 当服务端申请CA证书的时候CA机构会对该服务端进⾏审核并专⻔为该⽹站形成数字签名过程如 下
CA机构拥有⾮对称加密的私钥A和公钥A’CA机构对服务端申请的证书明⽂数据进⾏hash形成数据摘要然后对数据摘要⽤CA私钥A’加密得到数字签名S服务端申请的证书明⽂和数字签名S共同组成了数字证书这样⼀份数字证书就可以颁发给服务端了
方案五证书认证非对称加密对称加密✔️
在客户端和服务器刚⼀建⽴连接的时候,服务器给客⼾端返回⼀个证书证书包含了之前服务端的公钥,也包含了网站的身份信息 当客户端获取到这个证书之后会对证书进行校验包括
判定证书的有效期是否过期判定证书的发布机构是否受信任受信任的机构再OS中已经内置验证证书是否被篡改从系系统中拿到该证书发布机构的公钥对签名进行解密得到一个hash值数据摘要我们称它为hash1然后计算整个证书的hash值成为hash2对比hash1和hash2是否相等如果相等就表示证书没有被篡改过
事实上我们在浏览器中是能看到的 中间人有没有可能篡改该证书
中间⼈篡改了证书的明⽂由于他没有CA机构的私钥所以⽆法hash之后⽤私钥加密形成签名那么也就没法办法对篡改后的证书形成匹配的签名如果强行篡改客户端收到该证书后会发现明⽂和签名解密后的值不⼀致则说明证书已被篡改证书不可信从⽽终⽌向服务器传输信息防止信息泄露给中间⼈
中间人整个掉包证书
因为中间⼈没有CA私钥所以⽆法制作假的证书(为什么)所以中间⼈只能向CA申请真证书然后⽤⾃⼰申请的证书进⾏掉包这个确实能做到证书的整体掉包但是别忘记证书明⽂中包含了域名等服务端认证信息如果整体掉包客户端依旧能够识别出来。永远记住中间⼈没有CA私钥所以对任何证书都⽆法进⾏合法修改包括⾃⼰的
所以最终HTTPS的加密流程如下 涉及到的密钥
第⼀组(⾮对称加密):⽤于校验证书是否被篡改.服务器持有私钥(私钥在形成CSR⽂件与申请证书时获 得),客⼾端持有公钥(操作系统包含了可信任的CA认证机构有哪些,同时持有对应的公钥).服务器在客 ⼾端请求是返回携带签名的证书.客⼾端通过这个公钥进⾏证书验证,保证证书的合法性进⼀步保 证证书中携带的服务端公钥权威性。
第⼆组(⾮对称加密):⽤于协商⽣成对称加密的密钥.客⼾端⽤收到的CA证书中的公钥(是可被信任的) 给随机⽣成的对称加密的密钥加密,传输给服务器,服务器通过私钥解密获取到对称加密密钥.
第三组(对称加密):客⼾端和服务器后续传输的数据都通过这个对称密钥加密解密. 本节完… 证,保证证书的合法性进⼀步保 证证书中携带的服务端公钥权威性。
第⼆组(⾮对称加密):⽤于协商⽣成对称加密的密钥.客⼾端⽤收到的CA证书中的公钥(是可被信任的) 给随机⽣成的对称加密的密钥加密,传输给服务器,服务器通过私钥解密获取到对称加密密钥.
第三组(对称加密):客⼾端和服务器后续传输的数据都通过这个对称密钥加密解密. 本节完…
