信息安全原理及应用:第11章 WEB的安全性
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
client_hello
server_hello
server_certifica te server_key_exc hange
服务器提供的证书.如果客户要求对服务器进行认证, X.509v3证书链 则服务器在发送server_hello消息后,向客户端发 送该消息.证书的类型一般是X.509v3. 服务器密钥交换.当服务器不使用证书,或其证书中 仅提供签名而不提供密钥时,需要使用本消息来 交换密钥. 参数,签名
9
SSL的两个重要概念 的两个重要概念
SSL连接(connection)
– 一个连接是一个提供一种合适类型服务的传输; – SSL的连接是点对点的关系; – 连接是暂时的,每一个连接和一个会话关联.
SSL会话(session)
– 一个SSL会话是在客户与服务器之间的一个关联; – 会话由Handshake Protocol创建.会话定义了一组可 供多个连接共享的加密安全参数; – 会话用以避免为每一个连接提供新的安全参数所需 昂贵的谈判代价.
16
SSL握手协议的消息格式 握手协议的消息格式
17
握手协议定义的消息类型(1) 握手协议定义的消息类型
消息类型 hello_request 说明 握手请求,服务器可在任何时候向客户端发送该消息. 无 若客户端正在进行握手过程就可忽略该消息.否 则客户端发送cleint_hello消息,启动握手过程. 客户启动握手请求,该消息时当客户第一次连接服务 版本,随机数,会话 ID,密文族,压 器时向服务器发送的第一条消息.该消息中包括 缩方法 了客户端支持的各种算法.若服务器端不能支持, 则本次会话可能失败. 其结构与client_hello消息,该消息是服务器对客户端 client_hello消息的恢复. 版本,随机数,会话 ID,密文族,压 缩方法 参数
握手协议过程( ) 握手协议过程(1)
第一阶段 安全能力的建立
(1) 客户 → 服务器 :client_hello. (2) 服务器 → 客户 :server_hello.
第二阶段 服务器认证和密钥交换
(3) 服务器 → 客户 :server_certificate. (4) 服务器 → 客户 :server_key_exchange. (5) 服务器 → 客户 :certificate_request. (6) 服务器 → 客户 :server_hello_done.
23
SET安全电子商务的构成 安全电子商务的构成
24
利用SET协议的典型交易事件序列 协议的典型交易事件序列 利用
1. 申领信用卡. 2. 持卡用户获得证书. 3. 商家获得证书. 4. 持卡用户订购商品. 5. 用户对商家的身份认证. 6. 用户发送订购和支付信息. 7. 商家请求支付认可. 8. 商家确认订购. 9. 供货. 10. 商家请求支付.
告警协议
– 用于将SSL有关的告警传送给对方实体; – 分为警告性告警(warning)或致命性告警 (fatal)两个级别.
15
SSL握手协议层 (2) 握手协议层 )
握手协议(SSL Handshake Protocol)是 SSL中最复杂的一个部分. 其功能是使服务器和客户能够相互鉴别 对方的身份,并且协商一系列安全参数. 这些安全参数包括用于加密和MAC算法, 以及用于在SSL记录中保护发送数据的加 密密钥.
第11章 章 WEB的安全性 的安全性
1
WEB的安全性问题 的安全性问题
WEB已经成为Internet上最重要的应用. WEB的安全性问题的原因.
– HTTP协议的安全性是非常脆弱的; – 服务实现上的复杂性系统的配置和管理趋于 复杂化 ,导致许多的安全隐患; – WEB最终用户常常是未经训练或不了解系统 安全细节的用户.
4
TCP/IP协议栈中的安全机制 协议栈中的安全机制
5
SSL
Secure socket layer,是Netscape提出的. TLS(Transport Layer Security) 1.0 (RFC 2246) =SSLv3.l. 设计目标是在TCP基础上提供一种可靠 的端到端的安全服务,其服务对象一般 是WEB应用. 传输层的安全协议.
26
SET的双向签名机制 的双向签名机制
27
SET支持的交易类型(1) 支持的交易类型( ) 支持的交易类型
卡用户注册 商家注册 购买请求 支付认可 支付获取 证书调查和状态 持卡用户在CA中注册,以便能够与商家进行SET报文的交 互 商家在CA中注册,以便能够支持与持卡用户和支付网关 之间的SET报文交互 持卡用户向商家发送报文,其中包含提交给给商家的订购 信息OI和提交给的银行系统的支付信息PI 支付认可是商家和支付网关之间的交换,用来核准用户的 信用卡账号足以支付购买 商家向支付网关请求支付 持卡用户或商家向CA发出证书请求后,如果CA不能立刻 处理,它将给持卡用户或商家发送回答,指示请求者 以后再查看.持卡用户或商家通过发送"证书调查" 报文来确定该证书请求的状态,并且在请求被批准时 接收证书
– SSL握手协议(SSL HandShake Protocol); – SSL密码参数修改协议(SSL Change Cipher Spec Protocol); – 应用数据协议(Application Data Protocol); – SSL告警协议(SSL Alert Protocol).
– 接收数据; – 使用指定的解密算法解 密数据; – 使用指定的MAC算法校 验MAC; – 使用压缩算法对数据解 压缩(在需要时进行); – 将记录进行数据重组; – 将数据发送给高层.
14
SSL握手协议层 (1) 握手协议层
加密规约修改协议
– 仅定义了一个由单个字节"1"构成的消息报 文; – 该消息将改变了连接所使用的加密规约.
18
握手协议定义的消息类型(2) 握手协议定义的消息类型
消息类型 certificate_request server_hello_done 说明 用于服务器向客户端要求一个客户证书. 参数 类型,授 权 该消息表明服务器端的握手请求报文已经发送完毕,正在等 无 待客户端的响应.客户端在收到该消息时,将检查服务 器提供的证书及其他参数是否是有效,可以接受的. 客户端对服务器certificate_request消息的响应,只有在服务 器端要求客户证书的时候使用.一般该消息是客户端收 到server_hello_done消息后所发送的第一条消息.若客 户端没有合适的证书,则向服务器端发送no_certificate பைடு நூலகம்告警消息(无证书可能导致握手失败) X.509v3 证书链
client_certificate
client_key_exchange certificate_verify finished
客户密钥交换.当客户不使用证书,或其证书中仅提供签名 参数,签 而不提供密钥时,需要使用本消息来交换密钥. 名 该消息用于向服务器提供对客户证书的验证. 签名
该消息在"加密规约修改"(Change Cipher Spec)消息之 散列值 后发送,以证实握手过程已经成功完成.本消息发送后, 发送方开始使用协商的新参数来执行操作.该消息需要 19 在两个方向上传送.
22
SET的设计目标 的设计目标
为支付/订购信息提供机密性. 通信信息的完整性. 鉴证持卡者是否是信用卡账户的合法用户. 持卡用户需要确认能与之进行安全交易的商家的 身份. 采用最好的安全策略和系统设计技术来保护电子 商务交易中的所有合法方. 安全性应不依赖于传运输层安全机制,但又可以 充分利用传输层的安全服务. 协议应该独立于硬件平台,操作系统和WEB软件.
13
SSL工作过程 工作过程
发送方的工作过程
– 从上层接收要发送的数据 (包括各种消息和数据); – 对信息进行分段,成若干 记录; – 使用指定的压缩算法进行 数据压缩数据(可选); – 使用指定的MAC算法生成 MAC; – 使用指定的加密算法进行 数据加密; – 发送数据.
接收方的工作过程
10
状态分为两种:
SSL的会话状态 的
–待用状态(pending state),它包含了当前握手协议协商 好的压缩,加密和MAC的算法,以及加解密的密钥等参数. –当前操作状态(current operating state),它包含了当 前SSL纪录层协议正在使用的压缩,加密和MAC的算法,以及 加解密的密钥等参数.
25
双向签名
持卡用户需要将订购信息(OI)和支付信息 (PI)一起发送给商家. 但是实际上订购信息是发送给商家的,而支付 信息是需要发送给银行系统的.为了向持卡用 户提供更好的隐私保护,SET将OI和PI分离开 来,由不同的机构处理. 简单地将OI和PI分离是不行的.这两个方面的 信息也必须采用某种必要的方式连接起来,以 解决可能出现的争端. 双向签名可以连接两个发送给不同接收者的消 息报文 ,可以满足这种需求.
6
SSL的体系结构 的体系结构
7
SSL记录协议层 记录协议层
SSL Record Protocol layer. 为高层协议提供基本的安全服务. 记录层封装各种高层协议. 具体实施压缩解压缩,加密解密,计算 和校验MAC等与安全有关的操作.
8
SSL握手协议层 握手协议层
SSL HandShake Protocol layer. 用于SSL管理信息的交换,允许应用协议传送数 据之前相互验证,协商加密算法和生成密钥等. 包括:
21
安全电子交易 (SET)
Security Electronic Transaction. 主要是为了解决用户,商家和银行之间 通过信用卡支付的交易而设计的,以保 证支付信息的机密和支付过程的完整. SET中的核心技术包括公开密钥加密,数 字签名,电子信封,电子安全证书等. 是一个安全协议的集合.
SSL 记录协议
SSL 记录协议为SSL连接提供两种服务
– 保密性.利用握手协议所定义的共享密钥对 SSL SSL净荷(payload)加密 . payload – 完整性.利用握手协议所定义的共享的 MAC密值来生成报文的鉴别码(MAC).
12
SSL工作过程和 工作过程和SSL记录格式 工作过程和 记录格式
参数:
–会话标识符: 服务器选择的一个任意字节序列,用以标识一 个活动的或可激活的会话状态. –对方的证书: 一个X.509.v3证书.可为空. –压缩算法: 加密前进行数据压缩的算法. –加密规约: 指明数据体加密的算法(无,或DES等)以及散 列算法(如MD5或SHA-1)用以计算MAC.还包括其他参数, 如散列长度. –主密值: 48位秘密,在client与server之间共享. –可重新开始的标志:一个标志,指明该会话是否能用于产生 11 一个新连接.
2
WEB安全威胁 (1) 安全威胁 )
根据威胁的位置 ,可分为:
– 对WEB服务器的攻击; – 对WEB浏览器的攻击; – 对浏览器与服务器间通信流量的攻击.
3
WEB安全威胁 (2) 安全威胁 )
根据威胁的后果 ,可分为:
– – – – 对信息完整性的攻击; 对信息保密性的攻击; 拒绝服务攻击; 对身份认证攻击.
20
握手协议过程( ) 握手协议过程(2)
第三阶段 客户认证和密钥交换
(7) 客户 → 服务器 :client_certificate. (8) 客户 → 服务器 :client_key_exchange. (9) 客户 → 服务器 :certificate_verify.
第四阶段 结束阶段
(10) 客户 → 服务器 :change_cipher_spec. (11) 客户 → 服务器 :finished. (12) 服务器 → 客户 :change_cipher_spec. (13) 服务器 → 客户 :finished.
28
SET支持的交易类型(2) 支持的交易类型( ) 支持的交易类型
购买调查 认可撤销 持卡用户在收到了对购买请求的响应以后,可以使用"购 买调查"报文来检查订购处理的状态. 它允许商家更正以前的认可请求.如果订购将不被完成, 商家撤销整个认可;若部分订购不被完成,商家可以部 分撤销认可数量. 允许商人纠正收款请求中的差错,如错误地输入了的交易 数量. 商家可向持卡用户的账号发出一个信用,用于退货或者在 运输过程中损坏. 商家对先前请求的信用进行更正. 用于商家请求验证支付网关的,并且接收支付网关当前的 密钥交换和签名证书. 允许商家与支付网关之间的批量信息通信. 用于指示由于报文错误而导致的报文被拒绝.