🎬慕斯主页：修仙—别有洞天
♈️今日夜电波：ヒューマノイド—ずっと真夜中でいいのに。
1:03━━━━━━️💟──────── 5:06
🔄 ◀️ ⏸ ▶️ ☰
💗关注👍点赞🙌收藏您的每一次鼓励都是对我莫大的支持😍
目录
什么是HTTPS？
加密
加密和解密的概念
常见的加密方式
HTTPS的工作过程的探究
只使用对称加密
只使用非对称加密
双方都使用非对称加密
非对称加密+对称加密
中间人攻击问题
引⼊证书
CA认证
理解数据签名
非对称加密+对称加密+证书认正
中间⼈有没有可能篡改该证书？
中间⼈整个掉包证书？
什么是HTTPS？
HTTP协议内容都是按照文本形式进行明文传输的，这样就会导致在传输过程中出现一些篡改的情况。而HTTPS（Hypertext Transfer Protocol Secure）是一种透过计算机网络进行安全通信的传输协议，他则是在HTTP的基础上加上了一层加密层，通常在应用层和传输层之间加一层软件层（一般称为 SSL /TLS）。HTTPS因此也通常称为HTTP over TLS或HTTP over SSL。这种协议在HTTP的基础上，利用SSL/TLS来加密数据包，从而提供对网站服务器的身份认证，保护交换数据的隐私与完整性。大致的图解如下：
加密
加密和解密的概念
加密就是把明文信息经过一系列的转换从而生成密文。例如：我们可以可以在客户端传输给服务端的过程中用5^明文，那么这就称为密文。
解密就是把密文信息再进行经过一系列的装换从而变回明文。例如：上面我们提到的密文例子，我们可以再使用5^密文，就变回了原来的明文。
常见的加密方式
在HTTPS中，常见的加密方式包括：
- 对称加密算法：对称加密使用相同的密钥进行加密和解密。常见的对称加密算法包括AES（高级加密标准）和DES（数据加密标准）。
- 特点：算法公开、计算量小、加密速度快、加密效率高
- 非对称加密算法：非对称加密使用一对密钥，分为公钥和私钥。公钥用于加密，私钥用于解密。常见的非对称加密算法包括RSA、DSA和ECC（椭圆曲线加密）。
- 特点：算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂，而使得加密解密速度没有对称加密解密的速度快。
- 当然我们可以使用公钥加密，只能用私钥解密，使用私钥加密只能用公钥解密。
- 由于公钥是公开的，因此我们所有人都可以使用公钥进行加密和解密。
- 如果我们使用私钥加密，那么只要拥有公钥的人都可以解密。但是，如果我们使用公钥加密，那么只有拥有私钥的人才能解密。
- 消息认证码（MAC）：MAC用于验证消息的完整性和真实性。常见的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和公钥A
- CA机构对服务端申请的证书明⽂数据进⾏hash，形成数据摘要
- 然后对数据摘要⽤CA私钥A'加密，得到数字签名S
服务端申请的证书明⽂和数字签名S共同组成了数字证书，这样⼀份数字证书就可以颁发给服务端了
非对称加密+对称加密+证书认正
客户端进行请求，服务器返回证书。客户端认证证书的合法性，并且得到服务端公钥S，并且客户端形成对称秘钥X与公钥S进行加密推送回服务器，然后服务器使用S1进行解密得到秘钥X，最后双方使用秘钥X进行通信。
大致图示如下：
一些问题：
中间⼈有没有可能篡改该证书？
• 中间⼈篡改了证书的明⽂
• 由于他没有CA机构的私钥，所以⽆法hash之后⽤私钥加密形成签名，那么也就没法办法对篡改后的证书形成匹配的签名
• 如果强⾏篡改，客⼾端收到该证书后会发现明⽂和签名解密后的值不⼀致，则说明证书已被篡改，证书不可信，从⽽终⽌向服务器传输信息，防⽌信息泄露给中间⼈
中间⼈整个掉包证书？
• 因为中间⼈没有CA私钥，所以⽆法制作假的证书(为什么？)因为只有CA机构才掌握私钥。中间人没有CA的私钥，他们无法生成有效的数字签名来伪造证书。
• 所以中间⼈只能向CA申请真证书，然后⽤⾃⼰申请的证书进⾏掉包
• 这个确实能做到证书的整体掉包，但是别忘记，证书明⽂中包含了域名等服务端认证信息，如果整体掉包，客⼾端依旧能够识别出来。
• 永远记住：中间⼈没有CA私钥，所以对任何证书都⽆法进⾏合法修改，包括⾃⼰的
感谢你耐心的看到这里ღ( ´･ᴗ･` )比心，如有哪里有错误请踢一脚作者o(╥﹏╥)o！
给个三连再走嘛~
