iis配置网站权限,wordpress更换图片地址,wordpress拖拽插件,企业网站制作教程视频Linux网络#xff1a;HTTPS协议 加密方式对称加密非对称加密混合加密中间人攻击 证书数据签名CA认证 HTTPSSSL/TSLHTTPS 在HTTP协议中#xff0c;所有的数据都采用明文的形式传输#xff0c;这就会导致数据非常容易泄露#xff0c;只要拿到HTTP报文#xff0c;就可以窃取各… Linux网络HTTPS协议 加密方式对称加密非对称加密混合加密中间人攻击 证书数据签名CA认证 HTTPSSSL/TSLHTTPS 在HTTP协议中所有的数据都采用明文的形式传输这就会导致数据非常容易泄露只要拿到HTTP报文就可以窃取各种信息。
基于HTTP协议使用一定的加密措施让HTTP内部的数据变为密文就升级为了HTTPS协议其中S表示Secure或者Safe都是安全的意思。
加密方式
对称加密
对称加密是一种采用单个密钥的加密方式通信双方采用的密钥相同因此称为对称加密。 常见的对称加密算法有DES、3DES、AES、TDEA
这些算法是公开的但是密钥不是公开的只要通信双方的密钥不泄露就算别人知道使用了哪一个算法也无法解密密文。
比如一个简单的对称加密算法加减法。
假设现在对数据123456进行加密密钥C 6。
服务端使用密钥C加密
123456 - 6 123450此时就得到密文123450将密文通过HTTP发送给客户端。
客户端使用密钥C解密
123450 6 123456客户端就拿到了最终数据123456。
假设某个黑客截取到了HTTP报文破解出数据为123450也知道使用了加减法这个黑客可以得到原数据吗
当然不可以因为黑客没有密钥C他不知道123450这个密文要与谁进行加法自然得不到原数据。
以上过程只是简单了解原理实际上不会用加减法这样简单的计算来做加密。
如果服务端与客户端通信前都约定好使用指定的加密算法和密钥C那么就可以保证这个通信是安全的。
比如一个服务端与它的多个客户端都使用C作为密钥 但是这样有一个问题如果任意一个客户端泄露了这个密钥C那么所有客户端的信息都会被泄露。因此实际上并不会对所有的客户端采用相同的密钥而是每个客户端都使用不同的密钥。
如果每个客户端都使用不同密钥那么就不能再提前约定了因为服务端并不知道未来有哪些客户端要连接自己所以在正式通信前要为每个客户端生成一个密钥并告知客户端。 问题来了这个告知客户端密钥的消息是不被加密的黑客就可以截取第一次报文查看到这个密钥。此后虽然客户端与服务端都有密钥C但是黑客也有密钥C即使后续进行通信时数据会被加密但是对于黑客来说和明文传输没有区别。
对称加密有以下特点
简单计算量小加密速度快效率高 非对称加密
非对称加密采用两个密钥完成
公钥 S公开的密钥任何人都可以知道这个密钥私钥 S*私有的密钥只有非常少的人知道
公钥和私钥是配对的它们一个负责加密一个负责解密有以下两种情况
使用公钥S加密
拥有公钥的用户可以加密拥有私钥的人可以解密。而公钥是完全公开的也就是说任何人都可以加密一个数据发送给持有私钥的人。而私钥只有少数人持有说明只有少数人有资格查看加密的数据。
举个例子在校长办公室门口有一个信箱所有学生都可以投放信件提出建议。而提出的建议被放到信箱内部其他人打不开信箱就无法查看学生的建议这样投放信件到信箱的过程就是使用公钥加密数据的过程任何一个人都可以加密数据。
如果想要查看信箱内部的信件那么就必须有信箱的钥匙而钥匙只有校长有这个信箱钥匙就是私钥。只有校长可以看信件也就是只有私钥持有者有资格查看数据。
使用私钥S*加密
使用私钥加密与之前是相反的过程只有私钥的持有者有资格加密数据但是任何人都可以查看加密后的数据。
也举个例子这就像学校发布的告示文件这种文件往往需要学校盖章表示这个文件是本校发布的具有权威性。那么这个公章就是私钥只有持有公章的人有资格代表学校发布告示而任何人都可以阅读这个告示。
在网络通信中由于双方都需要收发数据如果采用非对称加密那么就要采用两对公钥和私钥。
假设服务端生成S S*这对密钥客户端生成C C*这对密钥采用私钥进行加密公钥进行解密。 如果黑客截取到了密文就算它持有两个公钥S和C但是解密报文需要私钥S*和C*这个只有客户端和服务端分别持有那么黑客就无法破解数据。
每一个客户端与服务器都要维护两对密钥那么这两对密钥就需要临时生成在最开始需要进行公钥的交换。 最开始客户端与服务端互相不知道公钥那么就需要互相告知自己的公钥交换公钥的过程是不加密的黑客就可以拿到公钥S和C但是就算黑客拿到了两个公钥它也破解不了报文。因为报文是拿公钥加密的要拿私钥解密而客户端与服务端之间各自生成私钥根本没有把私钥发送到网络上黑客就无法破解报文
这样看起来很完美了但是它无法抵挡中间人攻击这个稍后讲解。
非堆对称加密比较复杂而且加密速度慢。 混合加密
总结以上两个加密方式
对称加密效率高如果黑客在交换密钥时入侵加密会失效非对称加密效率低如果黑客在交换密钥时入侵加密依然有效
那么能不能结合一下两者集合它们的优点
在对称加密中主要是害怕第一次交换密钥会泄露因此第一次交换密钥需要进行一次额外的加密。问题就变成了在对称加密交换密钥时需要对密钥加密。
对这个对称密钥加密不能采用对称加密的方式必须采用非对称加密因为非对称加密不怕交换密钥时的黑客入侵。 流程如下
服务端生成非对称密钥S与S*服务端告知客户端公钥为S客户端生成对称密钥C客户端告知服务端对称密钥为C并使用公钥S加密服务端使用S*解密报文得到对称密钥为C后续所有通信采用对称密钥C
这个连接过程中只有第一个报文告知S公钥是没有加密的而非对称加密不怕公钥泄露。随后客户端利用这一层非对称加密来加密密钥C这样就可以保证C的安全性。
随后所有的通信都采用C就可以提高加密的效率又不怕C被泄露这就是结合前两者的混合加密。
不过这种加密方式也害怕中间人攻击。 中间人攻击
中间人攻击简称MITM先前两种加密方式看似都很完美但是都逃不过中间人攻击。
在进行密钥交换之前必然要建立TCP连接而在建立连接的过程中有可能会有第三者入侵。
假设当前TCP连接建立完成但是发生了中间人入侵。 中间人入侵后此时server以为middle是客户端client以为middle是服务端。
以混合加密为例展示中间人是如何绕开加密的
首先server生成非对称密钥S和S*并发送公钥S给中间人server以为中间人是客户端 你可能以为公钥根本就不怕被公开此时middle就算拿到了公钥S也没有任何作用。这确实没错但是这也是中间人攻击最巧妙的一步自己再生成一对非对称密钥M和M*。 客户端接收到公钥M后以为这是服务端发送来的消息以为服务端的公钥是M。
客户端生成对称密钥C通过公钥M加密发送给中间人 此时中间人通过私钥M*解密报文得到对称密钥为C于是再伪装自己是客户端把C利用公钥S加密发回给服务端。
随后客户端与服务端采用C进行加密通信 客户端与服务端都以为自己完成了完美的加密过程但是其实中间人早已经拿到了对称密钥C后续的所有报文中间人都可以轻松破解。
导致中间人攻击的源头就是第一次交换公钥S客户端无法得知自己收到的公钥是来自于服务端还是中间人。 证书
由于客户端无法确定与自己通信的是否是服务端还是中间人此时一个CA机构站了出来它维护了一个公钥A和一个私钥A*把公钥告知给所有的浏览器。当服务器发送数据前可以找CA机构进行认证生成一个证书客户端拿到数据后通过检验证书来得知与自己通信的是否是目标服务器。
数据签名
数据签名是一种基于非对称加密的校验方式其可以检测出数据是否被篡改。
生成报文 当发送数据时先把数据data使用哈希算法生成一个哈希值在把哈希值通过私钥A*进行加密这样就得到了签名。
最后发送报文时把data和签名一起发送出去。
验证报文 接收方从收到的报文中解析出data和签名两个部分。
对data使用相同的哈希函数得到一个哈希值使用公钥A对签名解密得到另一个哈希值对比两个哈希值
依据哈希算法的特性如果两个数据的哈希值不同那么这两个数据一定不同。因此只要数据被篡改那么此处两个哈希值就不同。
那么在加密过程中到底哪一步需要通过数据签名进行确认就是第一步服务端给客户端发送公钥时将自己的公钥域名等信息一起打包作为数据data并进行签名发送给客户端。
此时如果发生中间人攻击中间人如果替换了公钥那么就会造成data与原先不一致进而导致哈希值不同客户端就知道有中间人的存在了。 CA认证
将域名公钥等信息进行打包得到data在加上这个data的签名就是一个证书也就是说证书 服务端信息 签名。
证书由CA机构进行颁发用于保证证书的权威性。先前说过CA机构会自己维护一个私钥A*不透露给任何人并且所有浏览器都会内置对应的公钥A。 服务器配置HTTPS协议前要想CA机构申请证书服务器先生成非对称密钥S和S*并把这些信息打包发送给CA机构。CA机构会对这些信息进行确认如果验证通过就利用哈希函数和私钥A*对这个数据生成签名并把签名和服务端信息打包成证书发送给服务端。
后续服务端再与客户端通信只需要把证书发给客户端。由于浏览器内置了公钥A客户端就可以检测签名是否正确域名是否是目标域名从而确认该公钥确实来自于服务器随后执行混合加密过程生成对称密钥C完成真正的加密通信。
基于这种CA认证的方式中间人就无法对证书进行修改或者掉包。
中间人修改证书
如果中间人修改了证书中的公钥S将其变为自己的公钥M此时签名就无法匹配修改后的数据客户端就得知证书被修改了。
中间人掉包证书
如果中间人想要掉包证书那么就要保证自己证书中的签名可以被A解密那么中间人就需要持有A*但是A*被CA机构严格维护中间人得不到。
中间人也可以向CA机构申请证书完成掉包但是申请证书需要同时提交域名和公钥。
中间人使用服务端的域名配上自己的公钥M申请证书CA机构会进行审核发现匹配不上不会给中间人颁发证书中间人拿自己的域名配上自己的公钥M申请证书虽然可以得到证书但是客户端拿到掉包的证书后发现域名不是自己目标服务器的域名就可以知道证书被掉包了 HTTPS
先前的内容只是HTTPS的基本原理也就是使用混合加密 证书的模式实际上HTTPS的流程还要稍微复杂一点不过基于前面的内容也很好理解了。
SSL/TSL
HTTPS的加密部分是由SSL/TSL协议完成的具体关系在下一个小标题会讲解。
先前的混合加密 证书的模式中对称密钥C完全由客户端生成服务端完全没有参与这个过程而在真正的SSL/TSL协议中这个对称密钥是由双方进行协商得出的。
HTTPS通信流程 首先客户端要与服务端建立TCP连接随后正式开始HTTPS协议。
客户端发送一个Client Random随机数这个随机数与后文的密钥相关并发送一些其它的客户端本身的信息服务端返回一个Server Random随机数也与后文的密钥相关服务端发送自己的证书服务端发送一个密钥交换算法以及这个算法的一些相关参数发送Hello Done报文表示结束
这个密钥交换算法有很多种此处为ECDHE算法。
正式开始加密 客户端首先验证证书的可靠性在这个证书中包含服务端的公钥S。随后给服务端也发送一个ECDHE的参数并且这个报文由S公钥进行加密。
此处不对ECDHE算法深入了解只需要知道客户端与服务端会交换这个算法的部分参数。
当客户端与服务端拿到了ECDHE算法的参数以及两个随机数Client Random和Server Random就开始正式生成密钥。
双方分别基于ECDHE算法生成预主密钥Pre-Master由于先前已经交换过参数它们计算出的值是相同的双方分别基于Client Random和Server Random对预主密钥Pre-Master进行再次计算得到主密钥master secret
这个主密钥master secret又会进一步生成会话密钥session secret。
随后客户端发送Change Clipher Spec报文表示接下来的报文将使用会话密钥session secret加密。随后立刻发送Fished报文这个报文也会被session secret加密在这个报文内部包含了客户端之前各种信息形成的哈希值。
服务端ACK确认该报文后正式开始通信当服务端第一次发送数据之前也会发送发送Change Clipher Spec报文表示接下来的报文将使用会话密钥session secret加密再发送一个Fished报文也包含了服务端之前各种信息生成的哈希值。
当双方的Finded报文都发送完毕后就可以互相知道对方的哈希值从而对比出之前是否有数据不统一如果这两个哈希值一样那么生成的session secret就是一样的。
最后正式开始HTTPS通信。
总结
在以上过程中麻烦的是双方要互相交换很多数据最终的sesson secret密钥是一个对称密钥但是这个密钥是由双方一起决定的不再是客户端独自生成。
如果忽略复杂的密钥生成过程可以直接简化为最初的混合加密 证书的模型最后还是维护了一个对称密钥实现数据加密。只不过这个经过这个生成密钥的过程最终的对称密钥安全性更高。
此处得到对称密钥的方式有很多种本博客只是讲解了其中一种ECDHE也没有细讲该算法内部的具体内容。 HTTPS
HTTP、HTTPS、SSL、TLS协议关系如下 其实HTTPS协议就是在HTTP协议基础上增加了一个加密层而加密是由SSL或TLS实现的其中SSL是TLS的前身。
所以上一个小标题叫做SSL/TLS这表示加密部分是由这两个协议实现的并且两者是or的关系。
