建设一个人才网站需要的人才,wordpress 生成地区,模板企业网站,有谁做彩票网站吗#x1f3ac;慕斯主页#xff1a;修仙—别有洞天 ♈️今日夜电波#xff1a;ヒューマノイド—ずっと真夜中でいいのに。 1:03━━━━━━️#x1f49f;──────── 5:06 #x1f504; ◀️ ⏸… 慕斯主页修仙—别有洞天 ♈️今日夜电波ヒューマノイド—ずっと真夜中でいいのに。 1:03━━━━━━️──────── 5:06 ◀️ ⏸ ▶️ ☰ 关注点赞收藏您的每一次鼓励都是对我莫大的支持 目录
什么是HTTPS 加密
加密和解密的概念
常见的加密方式 HTTPS的工作过程的探究
只使用对称加密
只使用非对称加密
双方都使用非对称加密
非对称加密对称加密
中间人攻击问题 引⼊证书
CA认证
理解数据签名
非对称加密对称加密证书认正
中间⼈有没有可能篡改该证书
中间⼈整个掉包证书 什么是HTTPS HTTP协议内容都是按照文本形式进行明文传输的这样就会导致在传输过程中出现一些篡改的情况。而HTTPSHypertext Transfer Protocol Secure是一种透过计算机网络进行安全通信的传输协议他则是在HTTP的基础上加上了一层加密层通常在应用层和传输层之间加一层软件层一般称为 SSL /TLS。HTTPS因此也通常称为HTTP over TLS或HTTP over SSL。这种协议在HTTP的基础上利用SSL/TLS来加密数据包从而提供对网站服务器的身份认证保护交换数据的隐私与完整性。大致的图解如下 加密
加密和解密的概念 加密就是把明文信息经过一系列的转换从而生成密文。例如我们可以可以在客户端传输给服务端的过程中用5^明文那么这就称为密文。 解密就是把密文信息再进行经过一系列的装换从而变回明文。例如上面我们提到的密文例子我们可以再使用5^密文就变回了原来的明文。 常见的加密方式 在HTTPS中常见的加密方式包括 对称加密算法对称加密使用相同的密钥进行加密和解密。常见的对称加密算法包括AES高级加密标准和DES数据加密标准。 特点算法公开、计算量小、加密速度快、加密效率高 非对称加密算法非对称加密使用一对密钥分为公钥和私钥。公钥用于加密私钥用于解密。常见的非对称加密算法包括RSA、DSA和ECC椭圆曲线加密。 特点算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂而使得加密解密速度没有对称加密解密的速度快。当然我们可以使用公钥加密只能用私钥解密使用私钥加密只能用公钥解密。由于公钥是公开的因此我们所有人都可以使用公钥进行加密和解密。如果我们使用私钥加密那么只要拥有公钥的人都可以解密。但是如果我们使用公钥加密那么只有拥有私钥的人才能解密。 消息认证码MACMAC用于验证消息的完整性和真实性。常见的MAC算法包括HMAC基于散列的消息认证码。数字签名数字签名用于验证消息的发送者和完整性。常见的数字签名算法包括RSA和DSA。 在HTTPS连接中通常会结合使用这些加密方式以确保通信的机密性、完整性和认证性。 HTTPS的工作过程的探究
只使用对称加密 使用只有对称加密的HTTPS连接存在一个关键问题密钥交换和管理。 在对称加密中加密和解密使用相同的密钥。这意味着服务器和客户端需要共享同一个密钥来加密和解密通信。然而在一个开放的网络环境中安全地共享密钥是非常困难的。如果密钥在传输过程中被截获或泄露那么整个通信链路就会被暴露安全性受到威胁。 例如如果通讯算法各持有同一个密匙并且除了双方没人知道。这样双方的通信安全当热可以保证。但是真的这么简单吗我们该如何保证客户端和服务器双方使用的是同一个密匙如果是内置的内置在浏览器亦或者操作系统中无论是哪一个都有办法被黑客所获取。如果不是内置的那么我们在将密匙传输的过程中也是会有安全隐患的。 只使用非对称加密 只使用非对称加密的HTTPS连接也存在一些问题主要包括 性能问题非对称加密算法通常比对称加密算法更复杂因此加密和解密的计算成本更高。这可能会导致HTTPS连接的性能下降特别是对于高流量的网站或服务而言。密钥长度问题为了提高安全性通常需要较长的密钥长度。较长的密钥长度会增加加密和解密的计算复杂度进一步影响性能。密钥交换问题虽然非对称加密可以解决密钥交换和管理的问题但仍然存在一些挑战。密钥交换需要在通信的开始阶段进行并且涉及到公钥的传输。如果攻击者能够截获或篡改公钥的传输就可能导致安全性问题。例如我们服务器持有私钥而服务器先把公钥以明文方式传输给浏览器之后浏览器向服务器传数据前都先用这个公钥加密好再传。但是在传输的时候浏览器公钥被黑客截取了这个时候黑客就可以在这个传输过程中获得来着服务器的信息了。中间人攻击在只使用非对称加密的情况下仍然存在中间人攻击的风险。攻击者可能会伪装成合法的服务器或客户端并与另一方建立加密连接从而截获或篡改通信内容。 双方都使用非对称加密 我们让服务器和客户端都都持有各自独特的公钥和私钥即每个通信实体都有一对公钥和私钥。通常的流程如下 1服务器持有公钥S、私钥S1客户端持有公钥C、私钥C1。 2客户端与服务器通信前互相交换自己所持有的公钥。 3若客户端给服务器发消息就使用公钥S加密后续只能服务器使用秘钥S1解密若服务器给客户端发消息则使用公钥C加密只能由客户端用秘钥C1解密。 大致的图示如下 这种做法看似是安全的但是双方使用非对称加密可能会导致通信的性能下降特别是对于大量通信或需要实时性的应用而言。并且仍然存在安全的问题后面详讲虽然双方都使用非对称加密但仍然存在中间人攻击的风险。攻击者可能会伪装成合法的通信实体并与另一方建立加密连接从而截获或篡改通信内容。使用非对称加密的安全性依赖于公钥的安全性。如果公钥被截获或篡改通信的安全性将受到威胁。 非对称加密对称加密 结合非对称加密和对称加密是一种常见且有效的做法通常被用于保障通信的安全性和效率。这种组合利用了两种加密方式的优点解决了各自的缺点。通常的流程如下 1服务器持有公钥S、私钥S1客户端持有公钥C。 2客户端向服务器发送请求服务器响应返回公钥S。 3客户端获取S并使用公钥C加密然后发送给服务器。 4服务器使用私钥S1解密得到公钥C双方使用公钥C进行对称加密传输。 大致图示如下 然而这样依旧存在问题这里存在着中间人攻击的问题MITM 尽管使用了非对称加密进行密钥交换但仍然存在中间人攻击的风险。攻击者可能伪装成合法的通信实体与双方建立加密连接并对通信内容进行篡改或监视。 中间人攻击问题 我们首先明确以下开始的条件 服务器拥有非对称加密的公钥S、S1客户端拥有对称加密的公钥C、中间人拥有非对称加密的公钥M、M1。 接下来开始正式的操作 这个中间人可能是处于浏览器中也可能处于非法的软件中等等等等这里认为在浏览器中客户端经过浏览器向服务器请求公钥服务器因此经过浏览器向客户端返回公钥S但是这个时候中间人将S从报文中拿出来保存好并且把自己的公钥M填入报文中并且返回了客户端然而客户端并不知道报文已经被替换过了。客户端得到公钥M使用M加密公钥C经过浏览器返回给服务器。然而在这个过程中中间人就可以通过自己的秘钥M1提取公钥C。再公钥C和曾经保存的公钥S进行加密后填入报文推送给服务器。在完成这个操作够双方开始通信这个时候之间人既能同时掌握双方的信息可以对这些数据进行监听甚至直接进行修改植入自己的程序 大致的图示如下 上面的攻击方案同样适用于仅使用非对称加密和双方都使用非对称加密。 那么中间人可以攻击的核心原因是什么呢这是因为客户端无法验证公钥的合法性 引⼊证书
CA认证 服务端在使⽤HTTPS前需要向CA机构申领⼀份数字证书数字证书⾥含有证书申请者信息犯法直接线下真实、公钥信息等。服务器把证书传输给浏览器浏览器从证书⾥获取公钥就⾏了证书就如⾝份证证明服务端公钥的权威性。这份数组证书就是为了解决上述的问题。他的本质实际上就是数据 这个证书可以理解成是⼀个结构化的字符串,⾥⾯包含了以下信息: • 证书发布机构 • 证书有效期 • 公钥 • 证书所有者 • 签名 • ...... 需要注意的是申请证书的时候需要在特定平台⽣成查会同时⽣成⼀对⼉密钥对⼉即公钥和私钥。这对密钥对⼉就是⽤来在⽹络通信中进⾏明⽂加密以及数字签名的。其中公钥会随着CSR⽂件⼀起发给CA进⾏权威认证私钥服务端⾃⼰保留⽤来后续进⾏通信其实主要就是⽤来交换对称秘钥。 理解数据签名 签名的形成是基于⾮对称加密算法的注意⽬前暂时和https没有关系不要和https中的公钥私钥搞混大致的过程是对于大文本进行摘要再对摘要的信息进行加密。 这个加密的过程大致如下将提交上来的数据经过哈希散列数据摘要数据包含了原始数据的抽象表示。哈希函数将原始数据转换为一个固定长度的二进制字符串这个字符串就是数据摘要也称为哈希值或消息摘要形成对应的散列值然后CA机构会使用自己的私钥进行加密加密后则被称为签名再将原始的文本和签名结合形成签名的数据这个过程成为颁发证书。 后续再将这个证书给服务端再由服务端把证书给客户端。但是服务端向客户端返回证书的时候也可以被中间人篡改啊那么如何保证客户端的证书是没有被篡改过的呢客户端会将证书拆分开来分为明文部分和签名明文部分进行散列函数md5形成数据摘要由于签名是经过数据摘要和 CA机构 的私钥 加密过的因此再由CA机构的公钥这个公钥通常会内置客户端中进行解密后续比对这两部分的散列值即可图示如下 当服务端申请CA证书的时候CA机构会对该服务端进⾏审核并专⻔为该⽹站形成数字签名过程如下 CA机构拥有⾮对称加密的私钥A和公钥ACA机构对服务端申请的证书明⽂数据进⾏hash形成数据摘要然后对数据摘要⽤CA私钥A加密得到数字签名S 服务端申请的证书明⽂和数字签名S共同组成了数字证书这样⼀份数字证书就可以颁发给服务端了 非对称加密对称加密证书认正 客户端进行请求服务器返回证书。客户端认证证书的合法性并且得到服务端公钥S并且客户端形成对称秘钥X与公钥S进行加密推送回服务器然后服务器使用S1进行解密得到秘钥X最后双方使用秘钥X进行通信。 大致图示如下 一些问题
中间⼈有没有可能篡改该证书 • 中间⼈篡改了证书的明⽂ • 由于他没有CA机构的私钥所以⽆法hash之后⽤私钥加密形成签名那么也就没法办法对篡改后的证书形成匹配的签名 • 如果强⾏篡改客⼾端收到该证书后会发现明⽂和签名解密后的值不⼀致则说明证书已被篡改证书不可信从⽽终⽌向服务器传输信息防⽌信息泄露给中间⼈ 中间⼈整个掉包证书 • 因为中间⼈没有CA私钥所以⽆法制作假的证书(为什么)因为只有CA机构才掌握私钥。中间人没有CA的私钥他们无法生成有效的数字签名来伪造证书。 • 所以中间⼈只能向CA申请真证书然后⽤⾃⼰申请的证书进⾏掉包 • 这个确实能做到证书的整体掉包但是别忘记证书明⽂中包含了域名等服务端认证信息如果整体掉包客⼾端依旧能够识别出来。 • 永远记住中间⼈没有CA私钥所以对任何证书都⽆法进⾏合法修改包括⾃⼰的 感谢你耐心的看到这里ღ( ´ᴗ )比心如有哪里有错误请踢一脚作者o(╥﹏╥)o 给个三连再走嘛~
