计算系统与网络安全 Computer System and Network Security 电子科技大学 计算机科学与工程学院 2018/12/1

The Architecture of SSL 第7章 协议安全技术（安全协议实例） What is SSL? The Architecture of SSL How Does SSL work？ How to use the SSL in your security architecture Conclusions 2018/12/1

The Architecture of SSL 第7章 协议安全技术（安全协议实例） What is SSL? The Architecture of SSL How Does SSL work？ How to use the SSL in your security architecture Conclusions 2018/12/1

What is SSL SSL: Secure Sockets Layer protocol SSL is a secure protocol between application layer and TCP layer which provides confidential communication in un-secure network 2018/12/1

回顾：TCP/IP协议栈 应用层 SMTP HTTP TELNET DNS SNMP 传输层 TCP UDP 网络层 IP ICMP IGMP 网络接口层 ARP RARP 2018/12/1

回顾：TCP/IP的安全性问题及其解决方法 网络层安全 SMTP HTTP TELNET DNS SNMP 应用层 传输层层 TCP UDP 网络层 IP ICMP IGMP IP /IPSec 网络接口层 ARP RARP 2018/12/1

回顾：TCP/IP的安全性问题及其解决方法 传输层安全 SMTP HTTP TELNET DNS 应用层 SNMP SSL/TLS SSl/TLS 传输层层 TCP UDP 网络层 IP ICMP IGMP 网络接口层 ARP RARP 2018/12/1

The Goals of SSL Encryption（加密） Scalability（可扩展性） Efficiency（高效性） 透明性 SSL被设计用来使用TCP提供一个可靠的端到端安全服务 为两个通信实体之间提供 保密性 完整性 验证（身份鉴别) 密钥交换 Scalability（可扩展性） 新的密钥算法可以容易的加入 Efficiency（高效性） 减少对CPU的使用 透明性 对应用层透明 2018/12/1

The Goals of SSL (Cont.) 透明性 应用协议 明文数据流 SSL协议实现 密文数据流 可靠传输协议 DH RSA DES RC4 IDEA SHA ......... 应用程序 ..... Telnet HTTP FTP TCP SPX ........ Internet Ethernet 可靠传输协议 SSL协议实现 应用协议 明文数据流 密文数据流 2018/12/1

History of SSL Netscape 公司于1994开发 1996年IETF成立工作组 1999年推出TLS v1 SSL v2 released in 1995 SSL v3 also released in 1995 due to bugs in v2 1996年IETF成立工作组 Transport Layer Security (TLS) committee 1999年推出TLS v1 TLS v1 was based upon SSLv3 2003年推出TLS 扩展 2006年推出TLS v1.1 2018/12/1

Cryptographic Feature of SSL 连接是保密的，对称加密算法用于数据加密 实体的身份通过公钥加密算法得到验证 连接是可靠的，加密的消息摘要用于保证消息的完整性 2018/12/1

Cryptographic Feature of SSL Key Exchange. RSA Fixed Diffie-Hellman Ephemeral Diffie-Hellman Anonymous Diffie-Hellman Fortezza Data Compression: PKZip WinZip gzip .... Data Encryption: RC2-40 RC4-128 DES DES 40 3DES IDEA Fortezza Message Digest: MD5 SHA. 2018/12/1

The Architecture of SSL 第7章 协议安全技术（安全协议实例） What is SSL? The Architecture of SSL How Does SSL work？ How to use the SSL in your security architecture Conclusions 2018/12/1

SSL中的通信实体 通信实体（entity）是指SSL的参与者 在SSL v3中定义了两个通信实体 客户 服务器 客户是协议的发起者 服务器 服务器是协议的响应者 SSL Client（SSL客户） SSL Server（SSL服务器） 2018/12/1

SSL 的协议分层 SSL Record Protocol TCP IP SSL Handshake Protocol SSL Change Cipher Spec Protocol SSL Alert Protocol HTTP Protocol 握手协议：用来实现密钥交换和认证 记录层协议：用来安全传输数据 加密规约修改协议：启用新的密码参数 报警协议：报警和错误 Stallings Fig 17-2. 2018/12/1

一个问题 Question：为什么在SSL中存在两层：记录层和握手层？ 2018/12/1

Key Terms of SSL 在SSL中，有几个关键概念； SSL Session（SSL会话） SSL Connection（SSL连接） SSL Session State（SSL会话状态） SSL Connection State（SSL连接状态） 2018/12/1

SSL会话 SSL session（会话） an association between client & server（是客户和服务器之间的一个关联） created by the Handshake Protocol（通过握手协议来创建） define a set of cryptographic parameters（定义了一套加密参数） may be shared by multiple SSL connections（可以被多个SSL连接共享） An SSL session is stateful（是一个有状态协议）. It is the responsibility of the SSL Handshake protocol to coordinate the states of the client and server, thereby allowing the protocol state machines of each to operate consistently（使得客户和服务器状态一致）. 2018/12/1

SSL连接 SSL connection（连接） a transient, peer-to-peer, communications link（是一种通信实体具有对等关系的通信连接） associated with one SSL session（与一个SSL Session关联） 连接是瞬时的，用后即消失 2018/12/1

另外一个问题 Any question about SSL session and connection? Question: Session and connection has any relationship? 2018/12/1

会话与连接的关系 连接&会话 会话是用来协商安全参数的（如加密算法等） 连接是用来安全传输应用程序数据的（如加密传送消息） 理论上，双方可以存在多个同时会话，但在实践中并未用到这个特性 在任意一对通信双方之间，也许会有多个安全连接 每个连接都只和一个会话相关 一个会话可能包含多个安全连接 会话定义了一组可以被多个连接共用的密码安全参数，对于每个连接，可以利用会话来避免对新的安全参数进行代价昂贵的协商 An SSL session may include multiple secure connections; in addition, parties may have multiple simultaneous sessions. 2018/12/1

会话与连接的关系 连接&会话 Connection Session 一个会话包含多个连接 2018/12/1

会话与连接的思考 Any question about session and connection? Question: What about session and connection? 2018/12/1

SSL Session & Session State SSL session And Session States（会话与会话状态） Session States(会话状态）： 标识一个具体的SSL会话的信息 客户和服务器必须存储已经建立的会话的及其响应会话状态的信息 会话状态信息供握手协议层使用 特别是恢复一个会话时 2018/12/1

SSL Session & Session State (Cont.) SSL Connection and Connection States（连接与连接状态） Connection States (连接状态）contains all the information in one specific connection Only when the connection exists, the connection states will be remembered 2018/12/1

SSL Session & Session State (Cont.) Information of Session States（内容） Session Identifier (会话标识符） The X.509 certificates of Peer Certificate Server (Client) （客户或服务器的X.509证书，如果不需要验证，则该信息为空） Compression Methods （压缩算法） Cipher Spec （握手协议已经协商的一套加密参数） 对称加密算法 MAC算法 加密属性（包括Hash长度等） 2018/12/1

SSL Session & Session State (Cont.) Connection States includes（内容包括）： Server and client randoms: 本次连接的随机数（包括客户和服务器的） Server write MAC secrete(服务器MAC计算密钥）：服务器对要发送的数据进行hash运算的秘密值，它也是客户接收时进行Hash运行的秘密值 Client write MAC secrete（客户端MAC计算密钥）：客户对要发送的数据进行Hash运算的秘密值,它也是服务器接收数据时进行hash运算的秘密值 2018/12/1

SSL Session & Session State (Cont.) Server write key（服务器发送数据的加密密钥）：服务器用来加密数据、客户用来解密数据的对称加密密钥 Client write key （客户端发送数据的加密密钥） ：客户用来加密、服务器用来解密的对称加密密钥 Initialization Vectors (IV)：采用密码反馈模式是的初始化向量 Sequence Vectors：客户/服务器为其在一个连接中发送和接收消息分配的序列号 2018/12/1

SSL Session & Session State (Cont.) Question: why uses two write keys and two MAC secretes 2018/12/1

SSL Session & Session State (Cont.) Write Key（实际就是会话密钥） Key1（M1） Client One Connection Server Key2（M2） Client Server 2018/12/1

SSL Session & Session State (Cont.) MAC Secrete（实际就是MAC运算的秘密值） HAC（S1， M1） Client One Connection Server HAC（S2， M2） Client Server 2018/12/1

SSL Session & Session State (Cont.) Question：连接和会话在SSL中是如何建立和维护的？ Answer：为了回答这个问题，需要知道what is record layer protocol and what is handshake protocol。 2018/12/1

SSL Record protocol Layer 建立在可靠的传输协议（如TCP）基础上 提供连接安全性 保密性：使用对称加密算法 完整性：使用HMAC算法 2018/12/1

SSL Record protocol Layer (Cont.) 根据当前会话状态，给出压缩算法，Cipher Spec给出对称加密算法、MAC算法、密钥长度、Hash长度、IV长度，以及连接状态中给出的Client和Server的随机数、加密密钥、MAC秘密值、IV，消息序列号等，对将要传送的数据实施以下操作： 压缩/解压 加密/解密 MAC计算/MAC校验 2018/12/1

SSL Record protocol Layer (Cont.) 用来封装高层的协议 Change Cipher Spec protocol Alert protocol Handshake protocol Application protocol (HTTP, FTP, TELNET, et al) 2018/12/1

SSL Record protocol Layer (Cont.) Question：Record protocol layer中使用的密码及相关信息从那里得到？ 2018/12/1

Change Cipher Spec (Cont.) Change Cipher Spec: SSL修改密码规范协议 标志加密策略的改变 客户和服务器都发送该消息，通知接收方继该消息之后发送的消息，将采用握手层刚协商好的算法、密钥等进行压缩、MAC计算等 该消息有一个值为一位的单字节构成，它是明文传送 2018/12/1

Change Cipher Spec (Cont.) Question：在Change Cipher Spec中，提到如果发送该消息后，将使用新的加密、压缩和MAC算法，请问：它和以前的这些信息是一个什么关系(换句话说，握手层协商的加密参数等何时对记录层生效）? Answer: SSL使用另外两个状态来管理这种关系 预备状态 当前操作状态 2018/12/1

Change Cipher Spec (Cont.) Pending State（预备状态） 用来保存握手协议协商的密码信息（如压缩、加密、计算MAC的算法以及密钥等） Current State（当前状态） 用来保存记录层正在使用的密码信息（如压缩、加密、计算MAC的算法以及密钥等） 2018/12/1

Change Cipher Spec (Cont.) SSL Client SSL Server SSL Record Protocol 当前状态 当前状态 预备状态 SSL Handshake Protocol 预备状态 SSL Change Cipher Spec Protocol 当前状态 SSL Record Protocol 当前状态 2018/12/1

Alert protocol Alert Protocol：SSL警报协议 根据错误程度，Alert消息分为两类：警告消息（warning Msg）和致命消息（Fatal Msg） 致命消息将导致连接被立即中止，并将与这个连接相关的会话（会话标识符）作废，以免这个会话被继续用来建立新的连接 2018/12/1

Alert protocol (Cont.) 根据功能，Alert消息被分为两类：Close_Notify 和Error Alerts Alert Error：通知对方关闭该连接 区别： 前者关闭的连接可以被恢复 后者不能 Alert消息被加密传输 2018/12/1

Alert protocol (Cont.) 警告消息（Warning Msg） 结束通知 无证书 证书出错 不支持的证书 证书撤销 证书过期 未知证书 2018/12/1

Alert protocol (Cont.) 致命消息（Fatal Msg） 意外消息 MAC记录出错 解压失败 握手失败 非法参数 2018/12/1

Alert protocol (Cont.) 警报协议格式 Level Alert 字段取值 含义 Level 1 警告 2 SSL即将关闭 xx 均为严重警告消息 yy 2018/12/1

Application protocol 应用层协议 加密传输 不透明的内容（大于1字节） 2018/12/1

The Architecture of SSL 第7章 协议安全技术（安全协议实例） What is SSL? The Architecture of SSL How Does SSL work？ How to use the SSL in your security architecture Conclusions 2018/12/1

Working Process of Record layer 发方 Step 1 分片：从上层接收任意大小的数据块（ Records） Step 2 压缩：用当前会话状态中给出的压缩算法明文结构SSLPlaintext压缩为压缩记录SSLCompressed Step 3 MAC计算：用当前会话状态中指定的MAC算法对SSLCompressed计算消息摘要 Step 4机密：用加密算法加密压缩数据和消息摘要，形成密文结构SSLCiphertext Step 5封装发送：将数据封装为可靠传输层协议的数据包，并发送到可靠传输层协议 2018/12/1

Working Process of Record layer (Cont.) 2018/12/1

Working Process of Record layer (Cont.) 第一步：分片 2018/12/1

Working Process of Record layer (Cont.) 第二步：压缩 无损压缩 不会增加1024字节 以上长度的内容(短消息） 没有默认压缩算法 2018/12/1

Working Process of Record layer (Cont.) 第三步：MAC计算 消息摘要计算 2018/12/1

Working Process of Record layer (Cont.) 第四步：加密 消息摘要计算 2018/12/1

Working Process of Record layer (Cont.) 第五步：封装发送 SSL协议头 消息摘要计算 2018/12/1

Working Process of Record layer (Cont.) 2018/12/1

Working Process of Record layer (Cont.) 2018/12/1

Working Process of Record layer (Cont.) 2018/12/1

练习 请给出记录层收方的工作流程 2018/12/1

Working Process of Record layer (Cont.) 2018/12/1

问题 Question：Record protocol layer中使用的密码及相关信息如何得到？ Answer：由handshake protocol协商并进一步计算得到。 2018/12/1

Handshake protocol 握手协议 握手协议时SSL中最复杂的部分 此协议允许客户端和服务器相互认证、协商加密和MAC算法，保护数据使用的密钥通过SSL记录传递 握手协议在传递应用程序数据之前使用 The cryptographic parameters of the session state are produced by the SSL Handshake Protocol, which operates on top of the SSL Record Layer. When a SSL client and server first start communicating, they agree on a protocol version, select cryptographic algorithms, optionally authenticate each other, and use public-key encryption techniques to generate shared secrets. These processes are performed in the handshake protocol, which can be summarized as follows: The client sends a client hello message to which the server must respond with a server hello message, or else a fatal error will occur and the connection will fail. The client hello and server hello are used to establish security enhancement capabilities between client and server. The client hello and server hello establish the following attributes: Protocol Version, Session ID, Cipher Suite, and Compression Method. Additionally, two random values are generated and exchanged: ClientHello.random and ServerHello.random. 2018/12/1

Handshake protocol 功能回顾 握手协议层的功能 客户和服务器之间相互鉴别 协商密钥交换算法 协商加密算法和密钥 协商压缩算法 生成密钥 完成密钥交换 2018/12/1

Handshake protocol使用的协议 使用三个协议 SSL Handshake protocol 核心协议 SSL Change Cipher Spec 改变参数时使用 SSL Alert protocol 出现错误时使用 2018/12/1

Handshake protocol的作用 握手协议建立一个会话或者恢复一个会话 握手协议中每次握手都会生成新的密钥，MAC秘密值和初始化向量等。 Client和Server之间要建立一个连接，必须进行握手过程，每次握手都会存在一个会话和一个连接，连接一定是新的，但会话可能是已经存在的。 2018/12/1

Handshake protocol的本质 握手协议本质上是一个密钥交换协议，但它也包含认证功能，因此可以视为认证和密钥交换协议 握手协议主要由四个过程组成 建立安全能力 服务器认证和密钥交换 客户端认证和密钥交换 完成 Question：为什么需要服务器密钥交换和客户端密钥交换两个过程？ Answer：因为SSL在同一个连接的两个方向采用不同的密钥 2018/12/1

Handshake protocol的第一步 Client Server ClientHello --------> ServerHello <-------- 第一步完成： （1）客户告诉服务器自己的要求或能力 （2）服务器按照自己的要求或能力选择并回应客户 2018/12/1

Handshake protocol的第二步 Client Server Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> 第二步完成（服务器）： （1）向客户证明自己的身份 （2）完成密钥交换 （3）向客户提出自己的认证要求（可选） （4）告诉客户自己本阶段结束 第二步完成（客户）： （1）向服务器证明自己的身份（可选） （2）完成密钥交换 （3）向服务器发送自己的认证校验信息（可选） （4）告诉服务器自己本阶段结束 2018/12/1

Handshake protocol的第三步 Client Server [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished 第三步完成（服务器）： （1）向客户通告启用新的密码参数 （2）告诉客户自己本阶段结束 第三步完成（客户）： （1）向服务器通告启用新的密码参数 （2）告诉服务器自己本阶段结束 2018/12/1

Handshake protocol的第四步 Client Server Application Data <-------> Application Data 第四步完成（服务器）： （1）利用启用的密码参数加密发送数据 第四步完成（客户）： （1）利用启用的密码参数加密发送数据 2018/12/1

Handshake protocol总结 ClientHello --------> ServerHello <-------- Client Server ClientHello --------> ServerHello <-------- Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished 2018/12/1 Application Data <-------> Application Data

第一阶段： 建立安全能力（客户->服务器） 第一阶段： 建立安全能力（客户->服务器） SSL Client SSL Server Port 443 Client Hello The Client Hello message (a) SSL Version (highest) that is understood by the client. （SSL版本号） (b) A Random number to compute the secret key（随机数，防重放攻击，记为ClientHello.random） (c) Session Identifier（会话标识） 0： 新建一个会话和连接 非0：在已有会话上建立连接 (d) Data Encryption to identify the encryption methods available to the Client（密码组），包括两个部分 密钥交换算法（Key Exchange） 密码规范（cihper Spec） (e) Data Compression method for message exchange（压缩方法） 2018/12/1

第一阶段： 建立安全能力（服务器->客户） 第一阶段： 建立安全能力（服务器->客户） SSL Client SSL Server Port 443 Server Hello The Server Hello message (a) SSL Version (highest) that is understood by the client. （SSL版本号） (b) A Random number to compute the secret key（随机数，防重放攻击，记为ServerHello.random ） (c) Session Identifier（会话标识） (d) Data Encryption to identify the encryption methods （密码组） (e) Data Compression method for message compression（压缩方法） 2018/12/1

问题 两个遗留问题： （1）消息如何产生 （2）哪些密码参数？ 2018/12/1

问题 问题1：消息如何产生 客户端根据自己的实际情况构建client Hello message Question: How does the server compute the server hello message and send to client? Answer: a. SSL Version? The highest the client available b. A Random number to compute the secret key? Server generate it and it is independent of client’s number c. Session Identifier（会话标识）? If the client’s identifier is not 0 then the same as client’s, else generate a new identifier d. Data Encryption to identify the encryption methods? The one chose from client’s encryption methods list. e. Data Compression method for message compression? The one chose from client’s compression methods list. 2018/12/1

问题（续） 问题2：密码参数 密钥交换算法: 密码规范(CipherSpec) 压缩算法 1 RSA密钥交换协议 2 DH密钥交换协议 3 Fortezza密钥交换协议 为Fortezza模式定义的技术 （1）固定DH：包含认证中心签发的Diffie-Hellman公钥参数的服务器证书（公钥证书包含客户端Diffie-Hellman公钥参数，该参数由客户端在证书数中提供，或者在密钥交换消息中提供） 密钥交换算法: （2）瞬时Diffie-Hellman: 此技术用来创建一次性密钥。在这种情况下，Diffie-Hellman公钥在交换时使用服务器的RSA或者DSS私钥签名，客户端使用服务器的相应公钥验证签名 密码算法 MAC算法 密码类型：流密码或者分组密码 是否可出口（只在美国以外使用） MAC长度 密钥材料 IV大小 密码规范(CipherSpec) （3）匿名DH：使用基本的Diffie-Hellman 压缩算法 2018/12/1

问题（续） Question：Why does SSL use three kind of DH algorithms? Answer: Provides different security abilities 瞬时DH安全最高 匿名DH安全性最差，容易受到中间人攻击 2018/12/1

握手协议工作过程第一步 Client Hello SSL Client SSL Server Server Hello 2018/12/1

握手协议工作过程第二步 如果需要对客户端进行认证，服务器开始发送自己的证书消息等。该过程一般包含四条消息： 证书消息（Certificate） 服务器密钥交换消息（Server_Key_Exchange) 客户端证书请求消息（Certificate_Request) 服务器结束消息（Server_Hello_Done) 2018/12/1

第二阶段：服务器认证和密钥交换（服务器->客户） Certificate The server Identifier information A Digital Certificate of the sever information encrypted with the CAs Private Key（也可能是一组证书）. This contains the server‘s Public Key （包含服务器公钥） 说明： 服务器证书消息是服务器向客户端传送自己的证书，使得客户端知道服务器的公钥以及其他信息。 SSL Client SSL Server Port 443 The Server Certificate message 2018/12/1

第二阶段：服务器认证和密钥交换（服务器->客户） SSL Client SSL Server Port 443 Server_key_Exchange Server Key exchange message The Certificate type to indicate the type of public key The Certificate Authority is a list of distinguished names of Certificate Authorities acceptable to the Server 说明： （1）服务器密钥交换消息用来向客户端发送服务器自己的密钥信息 （2）The Server Key exchange message不是必须的 如果使用了固定Diffie-Hellman或者RSA密钥交换，则不需要。 反之，如果使用匿名Diffie-Hellman、瞬时Diffie-Hellman、Fortzza 或者服务器在使用RSA时仅用了RSA签名密钥。 RSA：在第一阶段包含了服务器的公钥 固定DH：由于在固定DH中，服务器在第一阶段发送的证书消息中包含了服务器自己的公钥 2018/12/1

第二阶段：服务器认证和密钥交换（服务器->客户） SSL Client SSL Server Port 443 Certificate_Request The Client Certificate Request message The Certificate type to indicate the type of public key (证书类型) （1）RSA （2）DSS （3）Diffie-Hellman ..... The Certificate Authority is a list of distinguished names of Certificate Authorities acceptable to the Server(认证中心CA列表）服务器可以接受的认证中心列表 说明： 如果服务器不使用匿名Diffie-Hellman，则客户端证书请求消息是必须的。它的目的是要求客户端向自己发送证书等消息，以便进行认证。 2018/12/1

第二阶段：服务器认证和密钥交换（服务器->客户） SSL Client SSL Server Port 443 Server _Hello_Done Server Done message 表明服务器的hello和相关信息结束 在此消息之后，服务器将等待客户端的应答 2018/12/1

第二阶段：服务器认证和密钥交换（服务器->客户） 总结 Server Certificate Server_key_Exchange Client Certificate Request SSL Server SSL Client Server Done Message 2018/12/1

第三阶段：客户机验证和密钥交换 在接收到服务器完成消息之后 如果请求了证书，客户端需要验证服务器是否提供了合法的证书 检查server_hello参数是否可以接受 如果所有条件满足，则客户端向服务器发回一个或者多个消息： 1）客户端证书消息（Certificate)：如果服务器请求了证书，必须有该消息 2）客户端密钥交换消息(Client_Key_Exchange)：必须发送 3）客户端证书校验消息（Ceritificate_Verify)：可以发送(便于服务器验证自己的证书） 2018/12/1

第三阶段：客户机验证和密钥交换（客户->服务器） SSL Client SSL Server Port 443 Certificate Client Certificate message The Client Identifier information A Digital Certificate of the client information 说明： 如果服务器请求了证书，但是客户端没有合适的证书，则发送”无证书警报“消息 2018/12/1

第三阶段：客户机验证和密钥交换（客户->服务器） SSL Client SSL Server Port 443 Client Key Exchange Client Key Exchange message The encrypted session key which will serve as a pre-master secret key encrypted with the server’s public key. 说明： 如果是RSA，该消息包含客户端生成的48字节的次密钥（ pre-master secret key ），并使用服务器证书中的公钥或者服务器密钥交换消息中的临时RSA密钥加密，它用于生成主密钥（ master secret key ） 如果是Diffie-Hellman，该消息包含客户端的Diffie-Hellman公钥参数 如果是Fortezza，则包含客户端的Fortezza参数 2018/12/1

第三阶段：客户机验证和密钥交换（客户->服务器） SSL Client SSL Server Port 443 Certificate_Verify Certificate Verify Message The Certificate Verify Message is composed of the Hash value of the client’s certificate. 说明： Hash签名很复杂，它对签名的所有消息即密钥信息等进行Hash运算，并用自己的私钥加密，从而即是有人盗用了客户端证书，也无法发送该证书验证消息 2018/12/1

第三阶段：客户机验证和密钥交换（客户->服务器） 总结 Certificate Client Key Exchange Certificate_Verify SSL Client SSL Server 2018/12/1

第四阶段：完成 此阶段完成安全连接的设置，主要包含以下消息： 客户： 服务器 1）客户端发送的修改密码规范消息（Change_Cipher_Spec) 2）客户端发送的完成消息（Finished) 服务器 3）服务器发送的修改密码规范消息（Change_Cipher_Spec) 4）服务器发送的完成消息（Finished) 2018/12/1

The Client’s Change cipher spec 第四阶段：完成（客户->服务器） SSL Client SSL Server Port 443 Change_Cipher_Spec The Client’s Change cipher spec 说明： 该消息不是握手协议的一部分，是使用修改密码规范协议来完成的 .它通知服务器启用新的密钥和算法。 在此之后，客户端使用新的算法、密钥和密码发送新的完成消息 2018/12/1

The Client Finish message 第四阶段：完成（客户->服务器） SSL Client SSL Server Port 443 Client Finish The Client Finish message The Client Finish message is composed of The client authenticates the server with a message encrypted with the newly generated shared keys. （客户端用新建立的会话密钥来认证服务器） This validates to the server that a secure connection has been created（确保连接的合法性）. 2018/12/1

The Server’s Change cipher spec 第四阶段：完成（客户->服务器） SSL Client SSL Server Port 443 Change_Cipher_Spec The Server’s Change cipher spec 说明： 该消息不是握手协议的一部分，是使用修改密码规范协议来完成的 。它通知客户端启用新的密钥和算法。 在此之后，服务器端使用新的算法、密钥和密码发送新的完成消息 2018/12/1

第四阶段：完成（客户->服务器） Server Finish message SSL Client SSL Server Port 443 Server Finish Server Finish message The Server Finish message is composed of The server authenticates the client with a message encrypted with the newly generated shared keys（服务器用新的会话密钥来认证客户）. This validates to the client that a secure connection has been created(确保连接的合法性） 说明: the Server and client can now begin to use their six shared keys for bulk data encryption utilizing the SSL Record Layer protocol（从此刻开始，客户端和服务器的记录层协议将启用新的密钥和算法进行数据加密） 2018/12/1

第四阶段：完成（客户->服务器） 总结 Change_Cipher_Spec Client Finish Server Finish SSL Client SSL Server 2018/12/1

问题 Question：Why does SSL need the finish operation？ Answer：从预备状态向当前状态改变 2018/12/1

SSL Handshake Protocol SSL Change Cipher Spec Protocol 第四阶段：完成（客户->服务器） SSL Record Protocol 当前状态 SSL Handshake Protocol SSL Change Cipher Spec Protocol 预备状态 SSL Client SSL Server Port 443 2018/12/1

SSL握手协议报文－总结 2018/12/1

SSL握手协议报文－总结 Stallings Fig 17-6. 2018/12/1

SSL握手协议报文－总结 在握手协议中，服务器证书请求和客户端证书请求都是可选的，因此SSL的握手过程实际蕴含三种验证方式： 客户端和服务器均被认证 只验证服务器 客户端和服务器均不被认证（即匿名模式） 2018/12/1

SSL握手协议报文－总结 2018/12/1

问题 Question：在handshake协议中，只交换了一个秘密（称之为次秘密），请问，SSL是如何得到通信中需要的加密密钥（即工作密钥）、MAC计算密钥和密码算法需要的IV值的？ Answer：回答这个问题需要知道SSL的密钥计算规则 2018/12/1

第二&三阶段交换结果：六对密钥 总结 C > S S > C C > S S > C Encryption MAC SSL Client SSL Server C > S S > C C > S S > C Encryption MAC IV 2018/12/1

Client write MAC secret Server write MAC secret 密码参数的生成 次秘密 （pre_master_secret） 主秘密 （master secret） Client write MAC secret Client write secret Client write IV Server write MAC secret Server write secret Server write IV 2018/12/1

主秘密的创建 共享主秘密(Master Secret)由客户机和服务器共享，是依据通过安全密钥交换后得到的次秘密（ pre_master_secret）来生成的一次性48字节值（384） 次密钥pre_master_secret 交换方法主要有两种： RSA：由客户端生成48字节的次密钥，并用服务器的RSA公钥加密后发送到服务器，服务器用其密钥解密，得到次密钥 Diffie-Hellman：客户端和服务器同时生成Diffie-Hellman公钥，密钥交换后双方执行Diffie-Hellman计算，创建共享次密钥 Master Secret 分两个步骤生成： Exchange pre_master_secret（交换次密钥） Compute the master_secret（双方计算主密钥） 2018/12/1

主秘密的创建（续） For Asymmetric cryptographic computations（非对称密码算法计算） The asymmetric algorithms are used in the handshake protocol to authenticate parties and to generate shared keys and secrets. The pre_master_secret should be deleted from memory once the master_secret has been computed（计算后需从内存中删除） master_secret = MD5(pre_master_secret + SHA('A' + pre_master_secret + ClientHello.random + ServerHello.random)) + MD5(pre_master_secret + SHA('BB' + pre_master_secret + MD5(pre_master_secret + SHA('CCC' + pre_master_secret + ClientHello.random + ServerHello.random)); 2018/12/1

主秘密的创建（续） When RSA is used for server authentication and key exchange A 48-byte pre_master_secret is generated by the client Encrypted under the server's public key, and sent to the server The server uses its private key to decrypt the pre_master_secret Both parties then convert the pre_master_secret into the master_secret, as specified above. The pre_master_secret should be deleted from memory once the master_secret has been computed（计算后需从内存中删除） master_secret = MD5(pre_master_secret + SHA('A' + pre_master_secret + ClientHello.random + ServerHello.random)) + MD5(pre_master_secret + SHA('BB' + pre_master_secret + MD5(pre_master_secret + SHA('CCC' + pre_master_secret + ClientHello.random + ServerHello.random)); 2018/12/1

主秘密的创建（续） 对于Diffie-Hellman A conventional Diffie-Hellman computation is performed The negotiated key (K) is used as the pre_master_secret and is converted into the master_secret, as specified above. master_secret = MD5(pre_master_secret + SHA('A' + pre_master_secret + ClientHello.random + ServerHello.random)) + MD5(pre_master_secret + SHA('BB' + pre_master_secret + MD5(pre_master_secret + SHA('CCC' + pre_master_secret + ClientHello.random + ServerHello.random)); 2018/12/1

其他密码参数的创建 Symmetric cryptographic calculations and the CipherSpec（SSL中的密码规约参数） The technique used to encrypt and verify the integrity of SSL records is specified by the currently active CipherSpec(密码规约）. A typical example would be to encrypt data using DES and generate authentication codes using MD5. The encryption and MAC algorithms are set to SSL_NULL_WITH_NULL_NULL at the beginning of the SSL Handshake Protocol, indicating that no message authentication or encryption is performed（SSL协议开始是并不进行加密或完整性验证）. The handshake protocol is used to negotiate a more secure CipherSpec and to generate cryptographic keys（握手协议用来协商密码参数，并生成密钥） 2018/12/1

其他密码参数的创建：加密密钥和MAC密钥 Converting the master secret into keys and MAC secrets The master secret is hashed into a sequence of secure bytes, which are assigned to the MAC secrets, keys, and non-export IVs required by the current CipherSpec（当前的密码参数）. CipherSpecs require a client write MAC secret, a server write MAC secret, a client write key, a server write key, a client write IV, and a server write IV, which are generated from the master secret in that order. Unused values, such as FORTEZZA keys communicated in the KeyExchange message, are empty. 2018/12/1

其他密码参数的创建：加密密钥和MAC密钥（续） The following inputs are available to the key definition process: MasterSecret[48] ClientHello.random ServerHello.random When generating keys and MAC secrets the master secret is used as an entropy source（熵源） and the random values provide unencrypted salt material and IVs for exportable ciphers. 2018/12/1

其他密码参数的创建：加密密钥和MAC密钥（续） To generate the key material（计算方法）： key_block = MD5(master_secret + SHA(`A' + master_secret + ServerHello.random + ClientHello.random)) + MD5(master_secret + SHA(`BB' + master_secret + MD5(master_secret + SHA(`CCC' + master_secret + ClientHello.random)) + [...]; until enough output has been generated. 2018/12/1

其他密码参数的创建：加密密钥和MAC密钥（续） Then the key_block is partitioned as follows. client_write_MAC_secret[CipherSpec.hash_size] server_write_MAC_secret[CipherSpec.hash_size] client_write_key[CipherSpec.key_material] server_write_key[CipherSpec.key_material] client_write_IV[CipherSpec.IV_size] /* non-export ciphers */ server_write_IV[CipherSpec.IV_size] /* non-export ciphers */ 2018/12/1

Client Server 2018/12/1

The Architecture of SSL 第7章 协议安全技术（安全协议实例） What is SSL? The Architecture of SSL How Does SSL work？ How to use the SSL in your security architecture Conclusions 2018/12/1

SSL的具体实现 2018/12/1

SSL与web安全 HTTP RFC 2817 and RFC 2818 describes HTTP over TLS -The first application layer secured with SSL RFC 2817 and RFC 2818 describes HTTP over TLS Maybe skipped 2018/12/1

SSL与web安全 First implementation of HTTP over SSL was issued in 1995 by Netscape Netscape was prevented from choosing shttp S-HTTP（secure HTTP） another protocol for securing messages Treats each request – response pair as a single unit Allows protect different messages between server-client differently Maybe skipped 2018/12/1

HTTP connection behavior Close connection after each response Images: require response/request pair HTTP 1.1 Connection : Keep-Alive (persistent connection) Some browsers still open number of connections to load page with images in parallel Large number of parallel connections is optimized by SSL session resumption. 2018/12/1

Basic Technologies HTTP (Hypertext Transfer Protocol) First protocol to use SSL Request/Response structure Most browsers speak http protocol HTML (Hypertext Markup Language) Offers the ability to structure the document Provide links to move to another documents URL (Uniform Resource Locator) 2018/12/1

Security of web－Summary 2018/12/1

Web安全的特点 提供双向的服务，攻击防范能力脆弱 作为可视化窗口和商业交互平台，提供多种服务，事关声誉 底层软件庞大，如apache约10M，历来是漏洞之最，攻击手段最多 如果被攻破可能导致成为进入企业的跳板 配置比较复杂 2018/12/1

Web安全的组成部分 Browser 安全 Web Server安全 Browser 与Web Server之间网络通信安全 HTTP Brower Web Server 2018/12/1

Web安全方案 网络层：IPSec 传输层：SSL/TLS 应用层：SET/SHTTP 2018/12/1

HTTP Over SSL(TLS): Protocol Client hello Server hello Server Certificate serverHelloDone ClientKeyExchange E(Kserv, PK) ChangeCipherSpec FIN Handshake (MAC) Application_data http request Application_data http response Alert : close_notify Handshake Data Close 2018/12/1

HTTP Over SSL(TLS): Overview Client makes connection to the server Handshakes SSL Transmits data over SSL channel Assigned port 443 Special configuration of the server needed (mod_ssl), possible to configure another port No client data is sent until SSL connection established Long web pages require spanning multiple SSL records 2018/12/1

HTTP Over SSL(TLS): Protocol Format version Record Length Content type Encrypted Data and Mac Record Header Data Content types: ChangeCipherSpec Handshake Application Data Alert (signaling error and closure) 2018/12/1

HTTP Over SSL(TLS): Connection closure When one side initiates closure Must send close_notify Optionally withholds its TCP FIN until close_notify received from other side. If TCP FIN received without close_notify this may indicate possible attack 2018/12/1

HTTP Over SSL(TLS): End-point Authentication When user’s browser receives certificate CA is a known CA Browser compares: Name of the site that it intended to connect with Hostname in certificate 2018/12/1

HTTP Over SSL(TLS): Session Resumption Minimizes the number of SSL handshakes, within the same session sides speak with already established keys If the close was premature（过早） in no case SSL implementation should resume session 2018/12/1

HTTP Over SSL(TLS): Error Handling Servers logs errors. Later maybe examined by administrator Clients receive via dialog boxes SSL implementation should: Report legitimate errors（报告合法错误） Not overwhelm the user (hide unimportant)（不致过渡影响用户） This slide maybe skipped 2018/12/1

HTTP Over SSL(TLS): SSL in IE 2018/12/1

The Architecture of SSL 第7章 协议安全技术（安全协议实例） What is SSL? The Architecture of SSL How Does SSL work？ How to use the SSL in your security architecture Conclusions 2018/12/1

总结 会话和连接是SSL中至关重要的概念 SSL的体系结构包括握手协议层和记录协议层 握手协议层实现密钥交换和认证功能 记录协议层实现数据的加密传送 SSL可以用来解决HTTP的某些安全问题，但它不是一个彻底的解决方案 本小节中没有完整的讨论Web的安全 2018/12/1

教材与参考书 教材： 李毅超 曹跃，网络与系统攻击技术 电子科大出版社 2007 周世杰 陈伟 钟婷，网络与系统防御技术 电子科大出版社 2007 参考书 阙喜戎 等 编著，信息安全原理及应用，清华大学出版社 Christopher M.King, Curitis E.Dalton, T. Ertem Osmanoglu（常晓波等译）. 安全体系结构的设计、部署与操作，清华大学出版社，2003(Christopher M.King, et al, Security Architecture, design, deployment & Operations ) William Stallings，密码编码学与网络安全－原理与实践（第三版），电子工业出版社，2004 Stephen Northcutt， 深入剖析网络边界安全，机械工业出版社，2003 冯登国，计算机通信网络安全，2001 Bruce Schneier, Applied Cryptography, Protocols, algorithms, and source code in C (2nd Edition)( 应用密码学 －协议、算法与C源程序， 吴世忠、祝世雄、张文政等译) 蔡皖东，网络与信息安全，西北工业大学出版社，2004 2018/12/1

Any Question? Q&A 2018/12/1