【Linux网络】Https【下】{CA认证/证书的签发与认证/安全性/总结}

本文主要是介绍【Linux网络】Https【下】{CA认证/证书的签发与认证/安全性/总结}，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

1.引入证书【为方案五铺垫】

1.1再谈https

1. HTTPS，全称Hypertext Transfer Protocol Secure，是一种在HTTP协议上加入了安全层（SSL/TLS）的协议。它通过传输加密和身份认证保证了传输过程的安全性，被广泛用于万维网上安全敏感的通讯，例如交易支付等方面。
   HTTPS的特点主要包括：
   安全性：HTTPS通过SSL/TLS协议对数据进行加密和身份验证，确保数据在传输过程中的保密性和完整性。加密保护了敏感数据的机密性，防止被第三方截获和窃取；身份验证防止了中间人攻击，确保了通信双方的身份可信。
   可信性：HTTPS使用证书来验证服务器的身份。证书由可信任的证书颁发机构（CA）签发，包含了服务器的公钥和颁发机构的数字签名。客户端在与服务器建立连接时会验证证书的真实性和合法性，确保通信双方的身份可信。
   SEO优化：搜索引擎将HTTPS作为网站排名的一个重要指标。
   安全的Cookie传输：在HTTPS连接中，所有的Cookie都会通过加密的方式传输，防止被窃取和篡改。这对于保护用户的登录凭据和敏感信息非常重要。
   用户信任度提升：使用HTTPS协议可以提升用户对网站的信任度。
   HTTPS的工作原理主要基于SSL/TLS协议，通过数字证书、加密算法、非对称密钥等技术完成互联网数据传输加密，实现互联网传输安全保护。HTTPS在HTTP与TCP之间加入了一个加密/身份验证层，该层负责数据的加密和解密以及身份认证。
   HTTPS适用于任何需要保护数据安全和隐私的场景，如网络银行和电子商务网站、社交媒体平台、在线支付平台、医疗保健网站等。在这些场景中，HTTPS可以有效防止黑客通过网络监听和窃取用户信息，保护用户的敏感信息不被第三方获取。

2. 之前我们讲过的四个方案，最后一个相对于完美的方案存在的问题是，即没办法知道收到的这个信息是谁发来的，即对方身份的合法性。举例：日常生活中，警察蜀黍会在大街上查看一些看起来鬼鬼祟祟的人，目的是判断这个人是否是合法公民，身份证这个证件是第三方政府（不是你不是警察）颁发的证件，用来标识合法性。

1.2SSL/TLS

SSL（Secure Sockets Layer，安全套接层）和TLS（Transport Layer Security，传输层安全性协议）是用于在两个通信应用程序之间提供保密性和数据完整性的协议。它们主要工作在应用层和传输层之间，通过互相认证、使用数字签名确保完整性、使用加密确保私密性，以实现客户端和服务器之间的安全通讯。

SSL/TLS协议的工作原理主要依赖于两个重要协议：握手协议和记录协议。握手协议负责协商加密算法、哈希算法、加密密钥，并帮助服务器和客户端相互验证。这个过程在应用程序的数据传输之前进行，并且通常包括四个步骤的握手过程。记录协议则建立在传输协议（如TCP协议）之上，对数据进行封装、压缩、加密等基本功能的支持。

SSL和TLS的关系非常密切。实际上，TLS是SSL的后续版本，它在1999年由IETF（互联网工程任务组）从SSL 3.0协议的基础上进行了标准化，并发布了TLS 1.0。TLS与SSL 3.0相比，在安全性方面进行了改进，并删除了SSL协议中存在的安全漏洞。之后，TLS又发布了多个版本，包括TLS 1.1、TLS 1.2等，每个版本都在安全性方面进行了进一步的提升。

总的来说，SSL/TLS协议是互联网通信中保障数据安全的重要协议，通过加密和身份验证技术，确保了数据在传输过程中的保密性和完整性。

1.3CA机构

1. CA认证，即电子认证服务，是指为电子签名相关各方提供真实性、可靠性验证的活动。CA机构，即Certificate Authority（证书授权机构）或称为CA中心，是负责发放和管理数字证书的权威机构，作为身份认证的有效凭据。
   CA认证的原理是通过第三方认证机构对数字证书的发放和管理，确保数字证书的真实性和可信度。CA认证的过程主要包括证书申请、申请审核、身份验证和证书发放几个环节。数字证书是包含用户公钥、用户身份信息以及CA机构的数字签名，用来确保证书的真实性和不可篡改性。
   在CA认证中，用户首先向CA提交证书申请，包括提供个人或组织的身份信息和相关证明材料。然后，CA对用户的身份和提供的信息进行验证，这通常包括核实用户的身份证件、企业注册文件等。一旦验证通过，CA会使用自己的私钥对用户的公钥进行签名，生成数字证书。数字证书包含了用户的公钥、证书的有效期、CA的签名等信息。最后，CA将签发的数字证书发送给申请者，申请者可以将证书安装到自己的设备中，以便进行加密通信或进行身份验证。
   CA机构在网络安全中起到了重要的作用，可以有效防止信息被篡改和伪造，保护用户的隐私和数据安全。同时，用户可以通过验证数字证书的真实性，来确认通信对方的身份和可信度，从而建立起安全可靠的通信环境。
   
2. CA认证
   服务端在使用HTTPS前，需要向CA机构申领一份数字证书，数字证书里含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明服务端公钥的权威性。
   

证书可以理解成是一个结构化的字符串,里面包含了以下信息:

证书发布机构
证书有效期
公钥
证书所有者
签名

需要注意的是:

申请证书的时候，需要在特定平台生成，会同时生成一对儿密钥对儿，即公钥和私钥。这对密钥对儿就是用来在网络通信中进行明文加密以及数字签名的。其中公钥会随着CSR文件，一起发给CA进行权威认证，私钥服务端自己保留，用来后续进行通信(其实主要就是用来交换对称秘钥)。

CSR在线生成工具

输入信息后会给出你的私钥和CSR文件（包含公钥）。形成CSR之后，后续就是向CA进行申请认证，不过一般认证过程很繁琐，网上有各种提供证书申请的服务商，如果有需要，直接找平台帮忙解决就行

1.4理解数字签名

签名的形成是基于非对称加密算法的，注意，目前暂时和https没有关系，不要和https中的公钥私钥搞混了。

1.4继续铺垫

上篇提到 前四个方案不完美的原因是

即

1. 客户端无法验证第一次“服务端”发来的公钥确实是服务端发来的
2. 客户端无法验证公钥是正确的
3. 总结：客户但无法验明对方的身份！
4. 我们前面的所有铺垫 都是在讲 如何能够验明一个人的身份！

证书的申请

1.5方案五

服务端申请证书

当服务端申请CA证书的时候，CA机构会对该服务端进⾏审核，并专⻔为该⽹站形成数字签名，过程如下：

1. CA机构拥有⾮对称加密的私钥A和公钥A’
2. CA机构对服务端申请的证书明⽂数据进⾏hash，形成数据摘要
3. 然后对数据摘要⽤CA私钥A’加密，得到数字签名S
   服务端申请的证书明⽂和数字签名S 共同组成了数字证书，这样⼀份数字证书就可以颁发给服务端了

回顾一二三

回顾方案四

方案五过程

0. 设CA自己的公钥为A，私钥为A‘。服务端自己的公钥为S，私钥为S‘。客户端自己的对称密钥X。
1. 客户端向服务端发起请求 请求CA证书 服务端给客户端自己的CA证书 证明自己的身份
2. 客户端对证书的明文数据用MD5算法形成数据摘要m，对数字签名用A解密形成数据摘要n，比对mn是否相等，相等说明服务端身份合法。提取证书中明文数据中服务端的公钥S。对X用S加密发送给服务端。服务端接收到后用S’解密获取X，之后双方用X加密交流。

方案五与方案四的区别：

方案四的S是直接发给客户端的，导致客户端无法验明S的合法性。
方案五的S是通过证书发给客户端的，这样能验明吗？接下来我们开始破解这种方案！

寻找方案五的漏洞

0. 设定中间人M，公钥M，私钥M‘
1. M对证书的明文数据修改，客户端对明文数据计算出的摘要和签名计算出的摘要不同，该方法不行！
2. M对摘要修改，客户端对明文数据计算出的摘要和签名计算出的摘要不同，该方法不行！【实际上M只对摘要修改没实际意义】
3. M对明文和摘要都修改，使得客户端对明文数据计算出的摘要和签名计算出的摘要相同，这样可以吗？不可以！客户端对签名解密时只会用CA的公钥，M对摘要修改后，用自己的M’加密，但是客户端对签名解密时只会用CA的公钥！此时客户端发现签名无法解密，意识到证书被修改了！即所有的浏览器都内置了CA的公钥，只会用CA的公钥对签名解密，这令一程度上赋予了CA机构权力==》面子是别人给的！
4. M把整个证书替换，M要想有证书，必须用自己的真实信息【域名/申请者】去申请，风险太高！其次，如果M真申请了，M就是一个合法机构，那么它就可以直接获取浏览器的请求数据了，为什么还要大费周章？此时合法的M如果用浏览器发来的数据做一些非法行为，这就是网络警察的工作了。同时，世界上没有两个完全相同的域名，如果真有人这么做了，浏览器在访问abc.com时显示的确实bca.com，浏览器是能看出来的！实际上存在一些伪网站，用和真的网站w相似的域名去申请证书，做的网站样式也和w相同，然后接收到浏览器的请求后，自己再向w发起请求，然后把w发来的响应再返回浏览器，这也是网络警察的工作！

客⼾端对证书进⾏认证

当客⼾端获取到这个证书之后, 会对证书进⾏校验(防⽌证书是伪造的).
• 判定证书的有效期是否过期
• 判定证书的发布机构是否受信任(操作系统中已内置受信任的证书发布机构).
• 验证证书是否被篡改: 从系统中拿到该证书发布机构的公钥, 对签名解密, 得到⼀个 hash 值(称为数
据摘要), 设为 hash1. 然后计算证书明文数据的 hash 值, 设为 hash2. 对⽐ hash1 和 hash2 是否相等. 如果相等, 则说明证书是没有被篡改过的

2.查看证书

2.1查看浏览器的受信任证书发布机构

2.2中间⼈有没有可能篡改该证书

• 中间⼈篡改了证书的明⽂
  • 由于他没有CA机构的私钥，所以⽆法hash之后⽤私钥加密形成签名，那么也就没法办法对篡改后
  的证书形成匹配的签名
  • 如果强⾏篡改，客⼾端收到该证书后会发现明⽂和签名解密后的值不⼀致，则说明证书已被篡改，
  证书不可信，从⽽终⽌向服务器传输信息，防⽌信息泄露给中间⼈

2.3为什么摘要内容在⽹络传输的时候⼀定要加密形成签名

常⻅的摘要算法有: MD5 和 SHA 系列

以 MD5 为例, 我们不需要研究具体的计算签名的过程, 只需要了解 MD5 的特点:
• 定⻓: ⽆论多⻓的字符串, 计算出来的 MD5 值都是固定⻓度 (16字节版本或者32字节版本)
• 分散: 源字符串只要改变⼀点点, 最终得到的 MD5 值都会差别很⼤.
• 不可逆: 通过源字符串⽣成 MD5 很容易, 但是通过 MD5 还原成原串理论上是不可能的.
正因为 MD5 有这样的特性, 我们可以认为如果两个字符串的 MD5 值相同, 则认为这两个字符串相同

理解判定证书篡改的过程: (这个过程就好⽐判定这个⾝份证是不是伪造的⾝份证)

假设我们的证书只是⼀个简单的字符串 hello, 对这个字符串计算hash值(⽐如md5), 结果为
BC4B2A76B9719D91
如果 hello 中有任意的字符被篡改了, ⽐如变成了 hella, 那么计算的 md5 值就会变化很⼤.
BDBD6F9CF51F2FD8
然后我们可以把这个字符串 hello 和 哈希值 BC4B2A76B9719D91 从服务器返回给客⼾端, 此时客⼾端如何验证 hello 是否是被篡改过?
那么就只要计算 hello 的哈希值, 看看是不是 BC4B2A76B9719D91 即可.
但是还有个问题, 如果⿊客把 hello 篡改了, 同时也把哈希值重新计算下, 客⼾端就分辨不出来了呀.所以被传输的哈希值不能传输明⽂, 需要传输密⽂.对证书明⽂(这⾥就是“hello”)hash形成散列摘要，然后CA使⽤⾃⼰的私钥加密形成签名，将
hello和加密的签名合起来形成CA证书，颁发给服务端，当客⼾端请求的时候，就发送给客⼾端，中间⼈截获了，因为没有CA私钥，就⽆法更改或者整体掉包，就能安全的证明，证书的合法性。
最后，客⼾端通过操作系统⾥已经存的了的证书发布机构的公钥进⾏解密, 还原出原始的哈希值, 再进⾏校验

为什么签名不直接加密，⽽是要先hash形成摘要?

• 缩⼩签名密⽂的⻓度,加快数字签名的验证签名的运算速度

如何成为中间⼈

ARP欺骗：在局域⽹中，hacker经过收到ARP Request⼴播包，能够偷听到其它节点的 (IP, MAC)
地址。例， ⿊客收到两个主机A, B的地址，告诉B (受害者) ，⾃⼰是A，使得B在发送给A 的数据包
都被⿊客截取
• ICMP攻击：由于ICMP协议中有重定向的报⽂类型，那么我们就可以伪造⼀个ICMP信息然后发送给局域⽹中的客⼾端，并伪装⾃⼰是⼀个更好的路由通路。从⽽导致⽬标所有的上⽹流量都会发送到我们指定的接⼝上，达到和ARP欺骗同样的效果
• 假wifi && 假⽹站等

3.总结

HTTPS ⼯作过程中涉及到的密钥有三组.
第⼀组(⾮对称加密): ⽤于校验证书是否被篡改. 服务器持有私钥(私钥在形成CSR⽂件与申请证书时获得), 客⼾端持有公钥(操作系统包含了可信任的 CA 认证机构有哪些, 同时持有对应的公钥). 服务器在客⼾端请求时，返回携带签名的证书. 客⼾端通过这个公钥进⾏证书验证, 保证证书的合法性，进⼀步保证 证书中携带的服务端公钥权威性。
第⼆组(⾮对称加密): ⽤于协商⽣成对称加密的密钥. 客⼾端⽤收到的CA证书中的公钥(是可被信任的)给随机⽣成的对称加密的密钥加密, 传输给服务器, 服务器通过私钥解密获取到对称加密密钥.
第三组(对称加密): 客⼾端和服务器后续传输的数据都通过这个对称密钥加密解密.

其实⼀切的关键都是围绕这个对称加密的密钥. 其他的机制都是辅助这个密钥⼯作的.

第⼀组⾮对称加密的密钥是为了让客⼾端拿到第⼆组⾮对称加密的公钥
第⼆组⾮对称加密的密钥是为了让客⼾端把这个对称密钥传给服务器.

4.https一定是安全的吗

https（Hypertext Transfer Protocol Secure）本身是为了提供安全的通信而设计的，它通过在HTTP协议上增加了一层加密（通常是SSL/TLS），以确保在客户端和服务器之间传输的数据是加密的、完整的，并且数据在传输过程中没有被篡改。然而，仅仅使用https并不意味着通信绝对安全，因为安全性是一个多层次、多方面的概念。

以下是https可能不是绝对安全的一些原因：

1. 中间人攻击（Man-in-the-Middle, MITM）：尽管https使用了加密，但如果攻击者能够成功地执行中间人攻击（例如，通过伪造证书或控制网络中的某个节点），他们仍然可能能够窃取或篡改数据。
   证书问题：如果服务器使用的SSL/TLS证书不是由受信任的证书颁发机构（CA）签发的，或者证书已经过期或被吊销，那么客户端可能会收到警告，并且通信可能不是安全的。
2. 弱加密算法或密钥：如果服务器使用的加密算法过时或密钥长度不够长，那么它可能容易受到暴力破解或其他类型的攻击。
   不安全的实现：即使https本身很安全，但如果服务器或客户端的实现中存在安全漏洞，那么整个通信也可能变得不安全。
3. 应用程序级别的漏洞：https只保护在传输层上的数据。如果应用程序本身存在安全漏洞（例如，SQL注入、跨站脚本攻击等），那么即使使用了https，攻击者仍然可能能够利用这些漏洞来窃取或篡改数据。
4. 用户行为：用户的行为也可能影响安全性。例如，如果用户点击了来自不受信任来源的链接或下载了恶意软件，那么他们的设备或数据可能会受到威胁。
5. 之前讲的中间人绞尽脑汁都是为了盗取客户端的信息（X），但是如果客户端就是中间人转而攻击服务器呢？即 中间人把浏览器内置的CA公钥保存一份 模拟浏览器向服务端发起请求，然后生成对称密钥M之后用M和服务端进行交流。如果想更安全的话，就考虑服务端对自己的信息做一下二次加密—了解即可
   因此，虽然https是一个很好的起点，但确保通信的安全性需要采取更多的措施，包括使用受信任的证书颁发机构签发的有效证书、使用强加密算法和长密钥、定期更新和修补软件漏洞、以及教育和培训用户采取安全的在线行为等。

5.应用层总结

应用层属于用户层 原因是不同用户有特定的需求：协议的定制 序列反序列 加密与解密 安全级别 ；
如果加密算法被攻破了，可以升级；但是如果应用层在内核，我们就需要升级内核，这是不合适的！即各种各样的需求放在用户层，这些东西无法统一，让那些用户自己搞！

这篇关于【Linux网络】Https【下】{CA认证/证书的签发与认证/安全性/总结}的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---