内部网站管理办法,青岛有没有做网站的,商城分销,营销网站建设yyeygtytty文章目录 https原理为什么要加密常见的加密方式对称加密非对称加密数据摘要数据指纹数据签名 https的几种工作方案方案一#xff1a;只使用对称加密方案二#xff1a;只使用非对称加密方案三#xff1a;两端都使用非对称加密方案四#xff1a;非对称加密 对称加… 文章目录 https原理为什么要加密常见的加密方式对称加密非对称加密数据摘要数据指纹数据签名 https的几种工作方案方案一只使用对称加密方案二只使用非对称加密方案三两端都使用非对称加密方案四非对称加密 对称加密 针对上述情况的中间人攻击证书CA认证理解数据签名 方案5非对称加密对称加密证书总流程 https原理
由于http协议内容都是按照文本方式明文传输的这就会导致在传输过程中出现⼀些不安全的情况。
https也是⼀个应用层协是在http协议的基础上引入了⼀个加密层
如果单纯的使用http协议那么数据在网络传送中就以明文形式传送。如果http发送请求时先经过 ssl/tls 的加密后再去传送对方主机收到后再经过 ssl/tls 解密的过程就是https
https就相当于主机之间在应用层是明文的但是在其他层是属于密文的 可以通过端口号来决定数据是否加密例如80是http443是https
为什么要加密
因为http的内容是明⽂传输的明⽂数据会经过路由器、wifi热点、通信服务运营商、代理服务器等多个物理节点如果信息在传输过程中被劫持传输的内容就完全暴露了。劫持者还可以篡改传输的信息且不被双方察觉这就是中间⼈攻击 所以才需要对信息进行加密
常见的加密方式
对称加密
采⽤单钥密码系统的加密方法同⼀个密钥可以同时用作信息的加密和解密这种加密方法称为对称加密也称为单密钥加密。
特征加密和解密所用的密钥是相同的 算法公开计算量小速度快效率高
非对称加密
需要两个密钥来进⾏加密和解密这两个密钥是公开密钥publickey简称公钥和私有密钥privatekey简称私钥
公钥可以加密也可以用来解私钥加密的密文私钥可以加密也可以用来解公钥加密的密文
因此公钥和私钥是配对的缺点是运算速度非常慢
数据摘要数据指纹
数据摘要也就是数据指纹用来确定数据的唯一性
其原理是**利用单向散列函数(Hash函数)对信息进行运算,⽣成⼀串固定长度的数字摘要。数字指纹并不是⼀种加密机制,但可以用来判断数据有没有被窜改 **
和加密算法的区别是摘要严格意义不是加密是没有解密的只不过从摘要很难反推原信息通常用来进行数据对比
数据签名
对数据摘要再进行加密就得到数字签名
https的几种工作方案
方案一只使用对称加密
客户端和服务端都是使用同一个密钥进行加密解密引⼊对称加密之后,即使数据被截获,由于中间人不知道密钥是啥,因此就无法进行解密,也就不知道请求的真实内容了。
但是这种做法并不安全因为服务器同⼀时刻其实是给很多客⼾端提供服务的如果是相同密钥那就及其容易扩散中间人也容易获取到。如果是每个客户端用的密钥都不一样那服务器就需要维护每个客户端和每个密钥之间的关系那这样的维护成本太大
比较理想的做法,就是能在客户端和服务器建立连接的时候,双方协商确定这次的密钥是什么但是还有问题是因为密钥也要经过传输但是如果密钥直接明文传输中间人也很容易获取到所以密钥进行加密但是密钥加密的密钥也是如此。因为直接使用对称加密这种做法并不安全
方案二只使用非对称加密
首先客户端向服务端申请公钥服务端返回公钥给客户端客户端使用公钥进行加密后传输服务端接收到数据后用私钥解密处理数据后再用私钥加密返回。因为公钥和私钥是配对使用的所以用公钥加密的数据必须得用私钥解密私钥加密同理。
这种做法看似合理实际上如果中间人在一开始客户端申请公钥使就已经开始劫持了那中间人就会获取到公钥并篡改公钥所以这种做法也不安全
方案三两端都使用非对称加密
服务端拥有自己的公钥S与对应的私钥S’客户端拥有自己公钥C与对应的私钥C’客户端和服务端交换公钥客户端给服务端发信息先用S对数据加密再发送只能由服务器解密因为只有服务器有私钥S’服务端给客⼾端发信息先用C对数据加密在发送只能由客户端解密因为只有客户端有私钥C’
这种做法看似可以实际上这种做法的效率非常低并且和方案二一样中间人可以在两端交换公钥的时候就进行劫持并篡改也并不安全
方案四非对称加密 对称加密
因为非对称加密的效率很低所以可以配合对称加密使用 服务端具有非对称公钥S和私钥S’客户端发起https请求获取服务端公钥S客户端在本地生成对称密钥C,通过公钥S加密,发送给服务器.由于中间的网络设备没有私钥,即使截获了数据,也无法还原出内部的原文,也就无法获取到对称密钥服务器通过私钥S’解密,还原出客⼾端发送的对称密钥C.并且使用这个对称密钥加密给客户端返回的响应数据.后续客户端和服务器的通信都只用对称加密即可。由于该密钥只有客⼾端和服务器两个主机知道其他设备不知道密钥即使截获数据也没有意义 也就是说这种做法是利用对称加密的密钥来给非对称加密的公钥进行加密传输这样除了一开始是使用非对称加密外后面都是使用对称加密进行加密的。但是这种做法也不安全
还是一样的道理如果中间人一开始就劫持了公钥那后面再怎么传输都离不开中间人的角色了
针对上述情况的中间人攻击
上述的方案二 三 四都是出现在了一个问题上那就是如果一开始中间人就获取到了公钥。
一旦中间人获取到了就可以 服务器具有非对称加密算法的公钥S私钥S’中间⼈具有非对称加密算法的公钥M私钥M’客户端向服务器发起请求服务器明文传送公钥S给客户端中间人劫持数据报文提取公钥S并保存好然后将被劫持报文中的公钥S替换成为自己的公钥M并将伪造报文发给客⼾端客户端收到报文提取公钥M(自己当然不知道公钥被更换过了)自己形成对称秘钥X用公钥M加密X形成报文发送给服务器中间人劫持后直接用自己的私钥M’进性解密得到通信秘钥X再用曾经保存的服务端公钥S加密后将报文推送给服务器服务器拿到报文用自己的私钥S’解密得到通信秘钥X双方开始采用X进行对称加密进行通信。但是⼀切都在中间人的掌握中劫持数据进性窃甚至修改都是可以的 因此为了解决这种情况就要引入证书
证书
CA认证
服务端在使用HTTPS前需要向CA机构申领⼀份数字证书数字证书里含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器浏览器从证书里获取公钥就行了证书就如身份证证明服务端公钥的权威性
一个证书里面包含了数据的签名和明文信息。其中明文信息里包含了证书发布机构证书有效期公钥等
需要注意的是**申请证书的时候需要在特定平台⽣成查会同时⽣成⼀对⼉密钥对⼉即公钥和私钥。这对密钥对⼉就是⽤来在⽹络通信中进行明文加密以及数字签名的 **
https://myssl.com/csr_create.html
理解数据签名
签名的形成是基于非对称加密算法的
CA机构拥有非对称加密的私钥A和公钥A’CA机构对服务端申请的证书明文数据进行hash形成数据摘要然后对数据摘要用CA私钥A’加密得到数字签名S
服务端申请的证书明文和数字签名S共同组成了数字证书这样⼀份数字证书就可以颁发给服务端了
方案5非对称加密对称加密证书
在客户端和服务器刚⼀建立连接的时候,服务器给客户端返回⼀个证书证书包含了之前服务端的公钥,也包含了网站的身份信息
每次的通信传输都需要进行证书认证 判定证书的有效期是否过期判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构)**验证证书是否被篡改:从系统中拿到该证书发布机构的公钥,对签名解密,得到⼀个hash值(称为数据摘要),设为hash1.然后计算整个证书的hash值,设为hash2.对比hash1和hash2是否相等.如果相等,则说明证书是没有被篡改过的 ** 假设中间人获取到了证书 中间人篡改了证书的明文由于他没有CA机构的私钥所以无法hash之后用私钥加密形成签名那么也就没法办法对篡改后的证书形成匹配的签名如果强行篡改客户端收到该证书后会发现明文和签名解密后的值不⼀致则说明证书已被篡改证书不可信从而终止向服务器传输信息防止信息泄露给中间人 那如果中间人掉包了证书呢 因为中间人没有CA私钥所以⽆法制作假的证书所以中间人只能向CA申请真证书然后用自己申请的证书进行掉包这个确实能做到证书的整体掉包但是别忘记证书明文中包含了域名等服务端认证信息如果整体掉包客户端依旧能够识别出来。永远记住中间人没有CA私钥所以对任何证书都无法进行合法修改包括自己的 因此这种方法是可取的。
总流程
