HTTPS简述

Http协议的缺点

1.通信过程的数据有可能被黑客拦截篡改和窃取。
2.不能保证通信双方的身份,有可能一方是伪装的。

什么是HTTPS协议

HTTP协议是运行在TCP之上的,HTTPS是运行在SSL(安全套阶层)之上再由SSL与TCP协议进行通信,SSL解决了HTTP协议不安全的问题。

SSL如何解决HTTP的问题的

SSL使用了对报文加密的方式来保证数据传输安全的? 说到这里要先介绍两种加密方式:对称加密和非对称加密。
对称加密:服务器和客户端持有一个相同的密钥,这个密钥既可以加密又可以解密。比如:A向B发送消息,A用密钥key进行加密,B收到加密的数据之后用同样的密钥key对数据进行解密。

非对称加密:服务器和客户端分别有自己的公钥和私钥,并且双方持有对方的公钥,当一方向另一方发送数据的时候首先使用对方的公钥对数据进行加密,对方收到数据之后用自己的私钥进行解密。比如 A向B发送msg,A首先用B的公钥对msg进行加密,B收到加密的msg之后用自己的私钥进行解密。

对称加密虽然简单但是,安全性低,公钥很可能在传输过程中被窃取,这样就毫无安全性可言了。非对称加密安全性较高但是十分占用计算资源。因此HTTPS使用了对称+非对称加密的方式对数据进行加密。首先用非对称加密的方式传输对称加密所要使用的密钥,之后的数据传输就是用对称加密对数据进行加密,也就是说非对称加密保证的是对称加密密钥的安全,对称加密保证的是传输的数据的安全,这样就既保证了安全性有保证了传输速度。
SSL如何确定通信方另一端的身份的? 这里用到了证书机制:
1.服务器首先将自己的公开密钥发送到数字证书认证机构
2.数字证书认证机构使用自己的私钥对服务器的公开密钥进行签名并颁发公钥证书(公钥证书=服务器的公开密钥+数字证书认证机构生成的数字签名)。
3.通信过程中服务器会把这个证书放松给客户端,客户端会拿数字证书认证机构的公钥去数字证书认证机构认证服务器公钥证书上的数字签名是否是真的,如果是真的那么通信方是可信任的。

HTTPS的通信过程

1.客户端向服务端发送客户端支持的SSL版本,加密组件列表。
2.服务端向客户端发送应答报文,该报文是从第一步客户端发送的报文中筛选出来的双方都支持的SSL版本和加密组件。
3.服务端向客户端发送公钥证书(这个公钥是用来加密后面用来加密数据的对称密钥的)。
4.服务端向客户端发送Finish报文,告诉客户端第一次握手结束。
5.客户端向服务端发送Client Key Exchange报文,包含Pre-master
secret 的随机密码(用于加密后面的消息),Pre-master secret已经用前面的公钥加密。
6.客户端向服务端发送Change Cipher Spec,告诉服务器后面使用Pre-master secret进行机密。
7.客户端向服务端发送Finish报文,第二次握手完成。
8.服务器向客户端发送Change Cipher Spec报文,这里客户端和服务端已经协商好用来加密的公钥。
9.服务器发送Finish报文,标志第三次握手结束。到这里SSL建立完成。
10.开始进行HTTP通信。

<think>嗯,用户想了解OCSP协议的基本概念和工作原理。从问题来看,用户应该是刚接触这个协议,需要清晰的解释。用户提供的引用材料很全面,涵盖了OCSP的定义、作用、工作流程以及优化方案(如OCSPStapling)。其中引用[3]的定义最简明:OCSP是用于查询X.509数字证书状态的互联网协议,替代了传统的CRL机制。在解释工作原理时,需要突出三个关键角色:客户端(浏览器)、服务器和OCSP响应器。引用[1]提到的阻塞问题很重要——原始OCSP需要客户端直接查询响应器,这会影响性能。而OCSPStapling(引用[1][4])让服务器预先获取响应并附带在TLS握手过程中,这个优化点应该重点说明。用户可能隐含想知道“为什么需要OCSP”。要补充说明证书吊销场景的重要性:当证书私钥泄露时,及时吊销能防止中间人攻击。对比CRL的缺点(更新延迟、带宽消耗)正好体现OCSP实时查询的优势。注意避开技术深坑:引用[4]提到的ASN.1编解码细节对初学者可能太复杂,只需说明响应包含“有效/吊销/未知”三种状态即可。最后用流程图描述工作流会比纯文字更直观。</think> OCSP(在线证书状态协议)是一种实时验证数字证书有效性的关键安全协议,以下是其核心概念和工作原理的说明: --- ### **OCSP协议基本概念** 1. **作用** 用于实时查询X.509数字证书的吊销状态(有效/吊销/未知),替代传统的证书吊销列表(CRL),解决CRL更新延迟和带宽消耗问题[^3][^5]。 *公式补充*:证书状态集合 $S = \\{\text{有效}, \text{吊销}, \text{未知}\\}$ 2. **核心角色** - **客户端**:发起查询的终端(如浏览器) - **OCSP响应器**:由CA部署的专用服务器(存储最新吊销状态) - **服务器**:提供服务的网站主机 --- ### **工作原理(标准流程)** ```mermaid sequenceDiagram participant 客户端 participant 服务器 participant OCSP响应器 客户端->>服务器: 发起HTTPS连接请求 服务器->>客户端: 返回证书链 客户端->>OCSP响应器: 发送OCSP请求(含证书序列号) OCSP响应器->>客户端: 返回签名响应(状态+时间戳) alt 证书有效 客户端->>服务器: 建立安全连接 else 证书吊销 客户端->>服务器: 终止连接并报警 end ``` 1. **客户端发起验证** 当客户端(如浏览器)收到服务器证书后,提取证书序列号,向CA指定的OCSP响应器发送查询请求[^2][^3]。 2. **OCSP响应器处理** 响应器核对内部数据库,生成包含状态的数字签名响应(防篡改),结构为: $$ \text{响应} = \text{签名}\big[\text{状态} + \text{时间戳} + \text{证书ID}\big] $$ 签名密钥为OCSP响应器的私钥[^1][^4]。 3. **客户端决策** 客户端验证响应签名合法性后,根据状态允许/拒绝连接: - **有效** → 继续访问 - **吊销** → 阻断并显示警告 - **未知** → 按策略处理(通常视为风险) --- ### **性能优化:OCSP Stapling** 为解决客户端直连OCSP的延迟问题(参见引用[1]): 1. **服务器主动获取** 服务端定期向OCSP响应器请求最新状态并缓存响应(通常5-10分钟更新)。 2. **握手时附带响应** 在TLS握手阶段,服务器直接将签名的OCSP响应附加到证书链中发送[^1][^4],流程简化为: ```mermaid sequenceDiagram participant 客户端 participant 服务器 客户端->>服务器: HTTPS请求 服务器->>客户端: 证书链 + 预签名的OCSP响应 客户端->>客户端: 本地验证响应有效性 ``` 优势: - 减少客户端网络延迟 - 降低OCSP响应器负载 - 响应由服务器私钥签名,客户端需验证签名链[^1][^4] --- ### **关键特点总结** | 特性 | 说明 | |---------------------|----------------------------------------------------------------------| | **实时性** | 秒级状态更新,优于CRL的周期发布[^2][^5] | | **安全性** | 响应经数字签名,防伪造(引用[1][4]) | | **网络依赖** | 需客户端能访问OCSP响应器(否则连接失败) | | **隐私风险** | OCSP响应器可能记录客户端IP和查询证书(部分实现启用匿名机制) | ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值