Pre
PKI - 数字签名与数字证书
PKI - 借助Nginx 实现Https 服务端单向认证、服务端客户端双向认证
发展历史
- HTTP（超文本传输协议）的发展历史：
- HTTP的起源可以追溯到1990年代早期，由蒂姆·伯纳斯-李（Tim Berners-Lee）在CERN（欧洲核子研究组织）开发出来，最初被用于在客户端和服务器之间传输HTML文档。
- HTTP/0.9是最早的版本，只支持简单的GET请求，并且没有头部信息。
- 随着互联网的发展，HTTP逐渐演进为HTTP/1.0和HTTP/1.1，引入了更多的请求方法、状态码、头部字段等功能，提高了性能和可靠性。
- 近年来，HTTP/2和HTTP/3相继发布，引入了新的特性如多路复用、头部压缩、服务器推送等，进一步优化了网络性能。
- HTTPS（安全超文本传输协议）的发展历史：
- 随着互联网的普及，人们开始意识到HTTP传输的数据存在安全隐患，容易被窃听和篡改。
- HTTPS的发展是为了解决HTTP的安全性问题。最早的HTTPS版本是在1994年由网景公司推出的，称为SSL（安全套接层）协议。
- SSL协议通过加密传输数据，保护了信息的机密性和完整性。后来，SSL逐渐演进为TLS（传输层安全）协议。
- 目前，TLS协议的版本包括TLS 1.0、TLS 1.1、TLS 1.2和TLS 1.3，不断提升加密算法的安全性和性能，并修复协议本身的安全漏洞。
- HTTPS在保障网站安全、防止信息泄露和劫持等方面发挥了重要作用，逐渐成为互联网传输数据的标准协议。
Http VS Https
HTTP与HTTPS之间存在几个关键区别：
- 安全性：
- HTTP传输的数据是明文的，容易被窃听和篡改，而HTTPS通过SSL/TLS加密传输数据，更安全可靠。
- 加密方式：
- HTTP不提供数据加密机制，而HTTPS使用SSL/TLS协议对传输的数据进行加密，保护数据的隐私性。
- 连接方式：
- HTTP连接建立相对简单，只需要进行TCP三次握手即可，而HTTPS除了TCP三次握手外，还需要进行SSL/TLS握手过程，增加了连接建立的复杂度和时间。
- 默认端口：
- HTTP的默认端口号是80，HTTPS的默认端口号是443，这样的设定方便了浏览器和服务器识别和处理不同协议的请求。
- 证书：
- HTTPS需要服务器方使用数字证书来验证身份，确保数据传输的安全性，通常由CA（证书颁发机构）颁发的证书来确认服务器的身份，而HTTP不需要证书验证。
综上所述，HTTPS相比于HTTP在安全性方面更可靠，但在性能方面可能稍有损耗，因为加密解密过程需要消耗额外的计算资源。
HTTPS 解决了 HTTP 的哪些问题
HTTPS解决了HTTP的三个主要安全问题：
- 窃听风险：
- HTTP传输的数据是明文的，容易被窃听者截获和查看通信内容。HTTPS通过SSL/TLS协议对通信内容进行加密，使得窃听者无法直接获取敏感信息。
- 篡改风险：
- 在HTTP通信过程中，攻击者可以篡改传输的数据，插入恶意内容或修改原始数据，造成信息被篡改的风险。HTTPS通过SSL/TLS协议保证数据的完整性，一旦数据被篡改，通信双方会立即发现，从而确保数据的可靠性。
- 冒充风险：
- HTTP无法验证通信方的真实身份，攻击者可以轻易冒充合法网站，引诱用户输入敏感信息或进行欺诈行为。HTTPS利用SSL/TLS协议的身份验证机制，使用数字证书来证明服务器的身份，确保通信双方的身份是可信的，从而防止了冒充风险。
综上所述，HTTPS通过在HTTP与TCP层之间加入SSL/TLS协议，解决了HTTP在信息加密、数据完整性和身份认证方面存在的安全问题，提高了网络通信的安全性和可信度。
HTTPS是如何解决上述三个风险的
- 信息机密性： (混合加密)
- HTTPS利用混合加密的方式实现信息的机密性，通过使用公钥加密和私钥解密的方式，确保通信内容只能被预期的接收方解密，从而解决了窃听的风险。
- 数据完整性：(摘要算法)
- HTTPS利用摘要算法来实现数据的完整性验证。在通信过程中，发送方会对数据进行哈希运算生成唯一的摘要，然后将该摘要与数据一起传输给接收方。接收方接收到数据后，会重新计算数据的摘要，并与发送方传输的摘要进行比较，从而验证数据是否被篡改，解决了篡改的风险。
- 身份认证：(数字证书)
- HTTPS使用数字证书来解决冒充的风险。服务器在数字证书中包含了其公钥，并由可信的证书颁发机构（CA）签名，客户端可以使用CA的公钥来验证证书的真实性。这样，客户端就可以确信与服务器通信的确是预期的服务器，而不是攻击者的冒充，从而解决了冒充的风险。
综上所述，HTTPS通过混合加密、摘要算法和数字证书等技术手段，有效地解决了HTTP通信过程中的窃听、篡改和冒充等安全风险，提高了通信的安全性和可信度。
混合加密
通过混合加密的方式可以保证信息的机密性，解决了窃听的风险。
- 对称加密的快速性和密钥保密性：
- 对称加密算法速度快，因为它只使用一个密钥进行加密和解密操作。然而，由于对称加密需要双方共享同一个密钥，而密钥的传输容易受到窃听者的攻击，无法安全地进行密钥交换。
- 非对称加密的密钥交换能力：
- 非对称加密算法使用一对密钥：公钥和私钥。公钥可以自由分发，而私钥必须保密。这种机制解决了密钥交换的问题，但由于非对称加密算法的运算速度较慢，因此不适合对大量数据进行加密。
因此，HTTPS采用混合加密的方式，利用对称加密算法和非对称加密算法的优势。在通信建立阶段，双方使用非对称加密的方式交换会话密钥（对称密钥），之后通信过程中使用对称加密的方式加密和解密数据，既保证了加密效率，又解决了密钥交换的安全性问题。
摘要算法 + 数字签名
摘要算法，也称为哈希函数，用于计算内容的哈希值或“指纹”。这个哈希值是根据内容计算出来的固定长度的唯一字符串，即使内容稍微有所改动，其哈希值也会完全不同。因此，通过比较接收到的哈希值和发送方发送的哈希值，可以判断内容是否被篡改。
常用的摘要算法包括MD5、SHA-1、SHA-256等，它们都是单向函数，即从内容计算出哈希值很容易，但从哈希值反推内容几乎是不可能的。这使得摘要算法在保证数据完整性方面非常有用，同时也被广泛应用于密码学、数字签名等领域。
数字签名是非对称加密的一种应用，它用于验证消息的完整性和身份认证。数字签名使用私钥对消息的哈希值进行加密，生成签名。接收方使用公钥解密签名，然后再对接收到的消息进行哈希计算，如果哈希值与解密出来的签名匹配，则可以确认消息的完整性和发送方的身份。
数字签名的工作原理如下：
- 发送方对消息进行哈希计算，得到消息的哈希值。
- 发送方使用私钥对哈希值进行加密，生成数字签名。
- 发送方将消息和数字签名一起发送给接收方。
- 接收方使用公钥解密数字签名，得到消息的哈希值。
- 接收方对接收到的消息进行哈希计算，得到一个新的哈希值。
- 接收方将计算得到的哈希值与解密出来的哈希值进行比较，如果两者一致，则确认消息的完整性和发送方的身份。
通过哈希算法可以确保内容不会被篡改，但是并不能保证「内容 + 哈希值」不会被中间人替换，因为这里缺少对客户端收到的消息是否来源于服务端的证明
举个例子，你想向老师请假，一般来说是要求由家长写一份请假理由并签名，老师才能允许你请假。
但是你有模仿你爸爸字迹的能力，你用你爸爸的字迹写了一份请假理由然后签上你爸爸的名字，老师一看到这个请假条，查看字迹和签名，就误以为是你爸爸写的，就会允许你请假。
那作为老师，要如何避免这种情况发生呢？现实生活中的，可以通过电话或视频来确认是否是由父母发出的请假，但是计算机里可没有这种操作。
那为了避免这种情况，计算机里会用非对称加密算法来解决，共有两个密钥：
- 一个是公钥，这个是可以公开给所有人的；
- 一个是私钥，这个必须由本人管理，不可泄露。
这两个密钥可以双向加解密的，比如可以用公钥加密内容，然后用私钥解密，也可以用私钥加密内容，公钥解密内容。
- 公钥加密、私钥解密：
- 目的：保证内容传输的安全。
- 流程：发送者使用接收者的公钥加密数据，只有接收者持有相应的私钥才能解密数据，因此确保了只有接收者能够读取原始内容，而其他人无法解密。
- 示例应用：安全地传输敏感信息，如密码、银行信息等。
- 私钥加密、公钥解密：
- 目的：保证消息的身份验证和完整性。
- 流程：发送者使用自己的私钥对数据进行加密，接收者使用发送者的公钥解密数据。只有发送者持有私钥，因此只有发送者能够对数据进行加密，这样接收者就能够确认数据确实来自发送者。
- 示例应用：数字签名、身份验证等场景。
这种加密方式的使用确保了通信的安全性和可信度，对于网络通信和数据传输至关重要。
私钥是由服务端保管，然后服务端会向客户端颁发对应的公钥。如果客户端收到的信息，能被公钥解密，就说明该消息是由服务器发送的。
数字签名算法的确提供了一种可靠的方法来确认消息的来源和完整性。通过使用发送者的私钥对消息进行加密（签名），接收者可以使用发送者的公钥来解密（验证签名），从而确认消息确实来自于发送者，并且在传输过程中未被篡改。
在这个例子中，如果你想请假，你的父亲（服务器）持有着私钥，而你的老师持有着公钥。你可以使用你父亲的私钥对请假条进行签名，然后将签名的请假条发送给老师。老师收到请假条后，使用你父亲的公钥来验证签名。如果验证成功并且确认内容完整，老师就可以确定请假条确实是由你父亲发起的，从而批准你的请假。
这种方式有效地防止了身份伪造和消息篡改，提高了通信的安全性和可信度。
数字证书
通过数字证书的方式保证服务器公钥的身份，解决冒充的风险。
前面我们知道：
- 可以通过哈希算法来保证消息的完整性；
- 可以通过数字签名来保证消息的来源可靠性（能确认消息是由持有私钥的一方发送的）；
但是这还远远不够，还缺少身份验证的环节，万一公钥是被伪造的呢？
还是拿请假的例子，虽然你爸爸持有私钥，老师通过是否能用公钥解密来确认这个请假条是不是来源你父亲的。
但是我们还可以自己伪造出一对公私钥 （中间人攻击）！
在这种攻击中，攻击者截取了通信双方（你父亲和老师）之间的通信，并试图篡改或伪造通信内容。
攻击者替换了老师的公钥，使得老师无法确认通信是否来自于真正的发送者。因此，老师使用攻击者提供的公钥来解密攻击者的私钥的数字签名，从而误认为通信来自于你的父亲。这种情况下，即使你使用了数字签名，也无法保证通信的安全性和身份验证。
你找了个夜晚，偷偷把老师桌面上和你爸爸配对的公钥，换成了你的公钥，那么下次你在请假的时候，你继续模仿你爸爸的字迹写了个请假条，然后用你的私钥做个了「数字签名」
既然伪造公私钥那么随意，所以你爸把他的公钥注册到警察局，警察局用他们自己的私钥对你父亲的公钥做了个数字签名，然后把你爸爸的「个人信息 + 公钥 + 数字签名」打包成一个数字证书，也就是说这个数字证书包含你爸爸的公钥。
这样，你爸爸如果因为家里确实有事要向老师帮你请假的时候，不仅会用自己的私钥对内容进行签名，还会把数字证书给到老师。
老师拿到了数字证书后，首先会去警察局验证这个数字证书是否合法，因为数字证书里有警察局的数字签名，警察局要验证证书合法性的时候，用自己的公钥解密，如果能解密成功，就说明这个数字证书是在警察局注册过的，就认为该数字证书是合法的，然后就会把数字证书里头的公钥（你爸爸的）给到老师。
由于通过警察局验证了数字证书是合法的，那么就能证明这个公钥就是你父亲的，于是老师就可以安心的用这个公钥解密出请假条，如果能解密出，就证明是你爸爸写的请假条。
正是通过了一个权威的机构来证明你爸爸的身份，所以你的伪造公私钥这个小伎俩就没用了。
在计算机里，这个权威的机构就是 CA （数字证书认证机构），将服务器公钥放在数字证书（由数字证书认证机构颁发）中，只要证书是可信的，公钥就是可信的。文章来源：https://www.toymoban.com/news/detail-835299.html
文章来源地址https://www.toymoban.com/news/detail-835299.html
到了这里，关于计网 - 深入理解HTTPS：加密技术的背后的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
