Linux证书与CA简介

最新推荐文章于 2024-01-09 15:07:51 发布

我来烤烤你

最新推荐文章于 2024-01-09 15:07:51 发布

阅读量1.4k

点赞数 1

分类专栏： Linux 文章标签： ssl 运维

本文链接：https://blog.csdn.net/qq_35396734/article/details/112197742

版权

Linux 专栏收录该内容

30 篇文章 0 订阅

订阅专栏

文章目录

- CA和证书

CA和证书

1 中间人攻击

Man-in-the-middle，简称为 MITM，中间人

以上的各种加密措施，前提条件都是【传输过程无任何问题】，实际上可能会被中间人替换数据

【原理】A要发送加密数据给B，则A先要请求B的公钥，B传回公钥的过程中可能被替换！！！

2 CA和证书⭐

【定义】证书 = 权威CA 认证的数字签名 + 公钥

【作用】确保公钥传输过程的安全，证明公钥合法性！！！！！！！！

PKI：Public Key Infrastructure 公共密钥加密体系
签证机构：CA（Certificate Authority）
注册机构：RA（发起申请证书的对象，不一定是CA，可能是代理商，如阿里巴巴）
证书吊销列表：CRL（对已经吊销的证书进行公布）

【标准格式】X.509：定义了证书的结构以及认证协议标准

版本号
序列号
签名算法
颁发者
有效期限
主体名称

【证书类型】

证书授权机构的证书
服务器证书
用户证书

获取证书两种方法：

自签名的证书：自已签发自己的公钥
由证书授权机构颁发：
1. 生成证书请求（csr）
2. 将证书请求 csr 发送给CA
3. CA签名颁发证书

注：CA自己的证书由上级CA颁发，根CA的证书由自己颁发（官方自签名）

3 安全协议SSL/TLS⭐

是同一个概念

早期名称：SSL（Secure Socket Layer）
现阶段名称：TLS（Transport Layer Security）

1 TLS介绍

1994年，NetScape公司设计了SSL协议（Secure Sockets Layer）的1.0版，但是未发布

…

2006：TLS 1.1 IETF(Internet工程任务组) RFC 4346，从2020年3月起，停止支持TLS 1.1及TLS 1.0版本安全协议，谷歌（Chrome）、Mozilla（Firefox）、微软（IE和Edge）、苹果（Safari）都会发布新版浏览器执行这个策略

2008：TLS 1.2 当前主要使用

2018：TLS 1.3

【TSL的功能】

机密性
认证
完整性
重放保护（防止中间人截获替换）

2 SSL与TLS组成

工作在OSI模型的【传输层】和【应用层】之间

是一个【协议栈】，包括：

Handshake协议：包括协商安全参数和密码套件、服务器身份认证（客户端身份认证可选）、密钥交换
ChangeCipherSpec 协议：一条消息表明握手协议已经完成
Alert 协议：对握手协议中一些异常的错误提醒，分为【fatal】和【warning】两个级别，fatal类型错误会直接中断SSL链接，而warning级别的错误SSL链接仍可继续，只是会给出错误警告
Record 协议：包括对消息的分段、压缩、消息认证和完整性保护、加密等

3 TLS实现过程

实现分为【握手阶段】和【应用阶段】

握手阶段(协商阶段):客户端和服务器端认证对方身份（依赖于PKI体系，利用数字证书进行身份认证），并协商通信中使用的安全参数、密码套件以及主密钥。
后续通信使用的所有密钥都是通过MasterSecret生成
应用阶段:在握手阶段完成后进入，在应用阶段通信双方使用握手阶段协商好的密钥进行安全通信

⭐实现方式1

RSA 密钥交换、RSA 数字签名

1. Visitor给出【协议版本号】、客户端【随机数1】、以及客户端【支持的加密方法】
2. Server【确认】双方使用的加密方法，生成【随机数2】
3. Server【发送数字证书】给Visitor
4. Visitor通过'查看证书状态且查询证书吊销列表'确认数字证书有效，
	并'使用信任的CA的公钥解密数字证书'获得Server的公钥，
	然后生成一个新的46字节【随机数3】（称为'预备主密钥 Pre-master secret'），
	并使用Server的公钥'加密预备主密钥'发给Server
5. Server使用自己的私钥，解密Visitor发来的预备主密钥
6. 此时Visitor和Server双方都具有了(客户端随机数1+服务端随机数2+预备主密钥3)
	它们两者都根据'约定的加密方法'，使用这三个随机数'生成对称密钥——主密钥'（也称为'对话密钥session key'）
7.双方验证完session key的有效性之后，SSL'握手机制就算结束了
8.后续的对话过程都使用 session key 进行加密
# 注：每相互通信一次，都重新计算出一个新的 session key ！！！！！

总结：

在SSL握手机制中，需要三个随机数（客户端随机数+服务端随机数+预备主密钥）
至始至终客户端和服务端只有【一次非对称】加密动作
上述SSL握手机制的【前提是单向验证】，即无需验证客户端
最关键的一点是Visitor要验证Server证书的有效性

注：RSA 密钥交换有一个很大的问题：没有前向安全性Forward Secrecy。这意味着攻击者可以把监听到的加密流量先存起来，后续一旦拿到了私钥，之前所有流量都可以成功解密

⭐实现方式2

ECDHE 密钥交换、RSA 数字签名

目前大部分 HTTPS 流量用的都是 ECDHE 密钥交换

【原理】ECDHE 是使用椭圆曲线（ECC）的 DH（Diffie-Hellman）算法

【优势】相比 RSA 密钥交换，DH 由传递 Premaster Scret 变成了传递 DH 算法所需的 Parameter，然后双方各自算出 Premaster Secret。对于这种情况，由于 Premaster Secret 无需交换，中间人就算有私钥也无法获得 Premaster Secret 和Master Secret。

【缺陷】虽然中间人拿到私钥也无法解密之前的流量，但可以实施 MITM 攻击来解密之后的流量

【结论】保证私钥安全仍然是很重要的