tls/ssl

TLS/SSL电子科技大学计算机学院

主要内容

1 、 SSL 历史和概况 2 、 SSLV3.O 中的状态 3 、记录层协议 4 、 Change Cipher Spec 协议 5 、 Alert 协议 6 、握手协议 7 、 TLS/SSL 安全性和常见攻击

1.1 SSL 发展历史

时间：

1994 年 Netscape 开发了 SSL(Secure Socket Layer) 安全套接层协议

1996 年正式发布 SSL3.0.

SSL 的版本及其特点： 1.0 ，不成熟。 2.0 ，基本上解决了 Web 通讯的安全问题。 3.0 ， 1996 年发布，增加了一些算法，修改了一

些缺陷。 TLS 1.0(Transport Layer Security 传输层安全协议，

也被称为 SSL 3.1) ， 1997 年 IETF 发布了 Draft ，同时， Microsoft 宣布放弃 PCT ，与 Netscape 一起支持 TLS 1.0 。

1999 年，发布 RFC 2246(The TLS Protocol v1.0) 。

1.1 SSL发展历史

1.2 SSL 概况

SSL V3.0 简介位于 TCP 层和应用层之间，提供 Internet

上保密通信的安全协议。分为握手层和记录层两层。会话和连接是 SSL 的两个重要的贯穿始终

的概念。

https:// 与 shttp://

1.2 SSL 概况

1.2 SSL 概况

目标

SSL 被设计用来使用 TCP 提供一个可靠的端到端安全服务，为两个通讯个体之间提供保密性、鉴别和完整性 .

SSL V3.0 的目标依优先次序为：加密安全：为通信实体间建立安全的连接。具

体体现为保密性、消息完整性和验证。互操作性：保证不同的开发者开发的 SSL V3.0

能够成功地交换加密参数。可扩展性：新的公钥加密方法和对称加密方法

在必要时可以添加进来。相对高效：为了不让加密操作占用过多的 CPU

时间， SSL 有一个可选的会话高速缓存机制，可以减少需要从头建立的连接数。

1.2 SSL 概况

SSL V3.0 有三种验证模式：Client 和 Server 都被验证；只验证 Server ，不验证 Client ；完全匿名。

模式 2 是目前 Internet 上应用最广的模式

1.2 SSL 概况

OpenSSL ，最新 0.9.8g ，实现了 SSLv2 ， SSLv3 ， TLSv1.0Openssl ——a command line tool.ssl(3) —— the OpenSSL SSL/TLS library.crypto(3)—— the OpenSSL Crypto library.URL: http://www.openssl.org

SSLeayhttp://www2.psy.uq.edu.au/~ftp/Crypto/

Internet 号码分配当局已经为具备 SSL 功能的应用分配了固定的端口号，例如带 SSL 的 HTTP(https) 被分配以端口号 443带 SSL 的 SMTP(ssmtp) 被分配以端口号 465带 SSL 的 NNTP(snntp) 被分配以端口号 563

1.2 SSL 实现

协议分为两层 -------- 握手层和记录层底层： SSL 记录协议上层： SSL 握手协议、 SSL 修改密文规约协议、

SSL 警告协议

1.3 SSL体系结构

SSL Handshake

Protocol

SSL Change Cipher Spec

Protocol

SSL Alert Protocol

HTTP

SSL Record Protocol

TCP

IP

SSL 记录协议建立在可靠的传输协议 ( 如 TCP) 之上它提供连接安全性，有两个特点

保密性，使用了对称加密算法完整性，使用 HMAC 算法

用来封装高层的协议 SSL 握手协议

客户和服务器之间相互鉴别协商加密算法和密钥它提供连接安全性，有三个特点

身份鉴别，至少对一方实现鉴别，也可以是双向鉴别协商得到的共享密钥是安全的，中间人不能够知道协商过程是可靠的

1.4 两个主要协议

SSL V3.0 的加密属性：

对称加密用于加密应用数据 ,

非对称加密用于验证实体和交换密钥非对称加密算法按用途分为密钥交换算

法和数字签名算法。

1.5 SSL V3.O 概况

SSL V3.0 中定义了两个通信主体：客户和服务器。 SSL 的客户和服务器和应用层的客户 / 服务器中

的客户和服务器的含义不同：应用层从请求服务和提供服务的角度定义客户

和服务器 SSL V3.0 从在建立加密参数的过程中扮演的角色来定义客户和服务器。

1.6 SSL V3.0的通信主体

SSL V3.0 有两个重要的、贯穿始终的概念： SSL 连接（ connection）：

一个连接是一个提供一种合适类型服务的传输（ OSI分层的定义）。

SSL 的连接是点对点的关系。有状态：每一个连接和一个会话关联。

SSL 会话（ session）：一个 SSL 会话是在客户与服务器之间的一个关联。会

话由握手协议（ Handshake Protocol）创建。会话定义了一组可供多个连接共享的密码安全参数。

会话用以避免为每一个连接提供新的安全参数所需昂贵的协商代价。

2 SSLV3.O中的状态

会话状态

会话状态包含了标识一个会话的特征的信息和握手协议的协商结果。 Client 和 server 都需要记住已建立的所有的会话的状态。会话状态供握手协议层使用 , 特别是当恢复一个会话的情形下。

2.1 会话状态和连接状态

会话状态包括如下元素：session identifier 会话标识符，由 server视具体情况决定，它标识一个正在建立的会话或一个被恢复的会话。

peer certificate server( 和 client) 的 X.509v3格式的证书。此元素可为 null,视是否验证 Server或Client而定。

compression method压缩算法，用于加密前对数据进行压缩。

cipher spec 握手协议协商的一套加密参数，包括对称加密算法、 MAC 算法 (即 Hash 算法 )和一些加密属性，例如， Hash长度等。


会话状态的特点：会有多个连接状态与一个会话相关联一旦一个会话建立，就存在一个读或写

的当前状态在握手协议中，创建了挂起的读写状态成功的握手协议，将挂起状态转变为当

前状态


会话状态参数有：Session identifier ：服务器选择的一个任意字节序列，用

以标识一个活动的或可激活的会话状态。Peer Certificate ：标识服务器的 X.509.v3 证书。可为空。Compression method ：加密前进行数据压缩的算法。Cipher spec ：指明数据体加密的算法（无，或 DES等）散列算法（如 MD5或 SHA-1）用以计算 MAC 。还包括

其它参数，如散列长度。Master secret ： 48 位秘密，在 client 与 server 之间共享。Is resumable ：一个标志，指明该会话是否能用于产生一

个新连接。


连接状态连接状态包含了 Client 和 Server 在传输数

据过程中使用的加密密钥、 MACsecrets 、 Ivs( 只有 CBC 方式的分析加密需要使用 ) 以及 Client 和 Server 的随机数。 Client 和 Server 只需在一个连接存在时记住这个连接的状态。连接状态为记录协议层所使用，记录协议层按照 Cipher Spec和连接状态给出的参数进行加 / 解密等操作。


连接状态包括如下元素： server and client randoms ： Server 和 client 为当

次连接选择的随机数。server write MAC secret ： Server 对要发送的数

据进行MAC 操作所使用的 secret , 是 Client 的 read MAC secret 。

client write MAC secret ： Client 对要发送的数据进行MAC 操作所使用的 secret, 是 Server 的 read MAC secret 。

server write key ： Server 用来加密数据、 Client用来解密数据的对称加密密钥。


client write key ： Client 用来加密数据、 Server用来解密数据的对称加密密钥。

initialization vectors 为 CBC 方式分组加密所使用的初始向量，每一个密钥有一个初始向量。

seuqence numbers ： Server/Client 为其在一个连接中发送和接收的消息分别记序列号，即两个方向上分别有各自的序列号。当 Server/Client发送或接收到 Change Cipher Spec 消息时，将相应方向上的序列号置 0 。


握手层协商的加密参数和生成的密钥何时对记录层生效？

Client 和 Server 如何协调起来同时实施新的加密参数和密钥？

这些工作主要靠 SSL V3.0 中定义的预备状态 (The Pending State) 和当前操作状态 (The Current Operating State) 以及 Change Cipher Spec 消息来实现。

2.2 预备状态和当前操作状态

预备状态和当前操作状态 SSL 用两个状态有效地实现了握手协议的协商结果和新生成的密钥对记录层生效：预备状态包含了本次握手过程协商好的压缩、加密、计算 MAC 算法 ( 不包含密钥交换算法 ) 以及密钥等。

当前操作状态包含了记录层正在使用的压缩、加密、计算 M

AC 算法 ( 不包含密钥交换算法 ) 以及密钥等。


读状态和写状态 client 和 server 都有各自独立的读状态和写状态。读状态 (The Read State)

读状态中包含解压缩算法、解密算法、验证MAC 的算法和解密密钥等。

写状态 (The Write State)

写状态中包含压缩算法、加密算法、计算MAC 的算法和加密密钥等。


预备状态、当前操作状态与读状态、写状态结合成 4 个逻辑状态：预备读状态 (The Pending Read State)预备写状态 (The Pending Write State)当前读状态 (The Current Read State)当前写状态 (The Current Write State)

以上 4 种逻辑状态中的参数取自于会话状态和连接状态。 Client 和 Server 都具有这 4 种逻辑状态。当前读状态和当前写状态构成记录协议层的操作环境，所有的上层数据都在这两种状态下被压缩 /解压缩、加 / 解密、计算 /校验 MAC 。


Client/Server 接收到 Change Cipher Spec 消息后，立即指导记录层把预备读状态中的内容拷贝进当前状态，并清空预备读状； Client/Server 在发送了 Change Cipher Spec 消息后，立即指导记录层把预备读状态中的内容拷贝进当前状态，并清空预备写状态。


记录协议为 SSL连接提供两种服务：保密性。 Handshake Protocol定义一个共享的保密密钥用于对 SSL有效载荷加密。

消息完整性。 Handshake Protocol定义一个共享的保密密钥用于形成MAC。

3 记录层协议

记录协议层的功能是根据当前会话状态给出的压缩算法， Cipher Spec给出对称加密算法、 MAC 算法、密钥长度、 Hash长度、 IV长度等参数，以及连接状态中给出的 Client 和 Server 的随机数、加密密钥、 MAC secrets JVs 、消息序列号对当前的连接中要传送的高层数据实施压缩/ 解压缩、加 / 解密、计算 /校验 MAC等操作。

对记录协议层来讲，要封装的高层协议有 4类：Change cipher spec 协议Alert 协议Handshake 协议应用层协议，例如， HTTP 、 FTP

ZELNET

3 记录协议

记录协议操作过程如图所示：

3.1 记录协议操作过程

Application Data

Fragment

Compress

Add MAC

Append SSLRecord Header

Encrypt

SSL记录协议中的操作：第一步， fragmentation。上层消息的数据被分片成 214(16384)字节大小的块，或者更小。

第二步， compression(可选 )。必须是无损压缩，如果数据增加的话，则增加部分的长度不超过 1024字节


第三步， MAC 计算：使用共享的密钥 MAC_write_secret 。 hash(MAC_write_seret||pad_2||hash(MAC_write_secret||pad_1|| seq_num||SSLCompressed.type||SSLCompressed.length||SSLCom

pressed.fragment) 其中： MAC_write_secret ：共享的保密密钥。 hash ：密码散列函数（MD5或 SHA-1）。 pad_1 ： 0x36 重复 48 次 (MD5) ；或 40 次 (SHA-1) 。 pad_2 ： 0x5C 重复 48 次 (MD5) ；或 40 次 (SHA-1) 。 seq_num ：该消息的序列号。 SSLCompressed.type ：更高层协议用于处理本分段。 SSLCompressed.length ：压缩分段的长度。 SSLCompressed.fragment ：压缩的分段 (无压缩时为明文段 ) 。注：非常类似 HMAC 。


第四步 , 加密 , 可供选择的加密算法：

采用 CBC ，算法由 cipher spec指定数据长度不超过 214+2048字节，包括 IV ，

初始协商指定，以后，前后记录连接起来

说明：如果是流密码算法，则不需要 padding


Block Cipher Stream Cipher

IDEA 128

DES-40 40

RC-40 40

3DES 168

RC2-40 40

DES 56

RC4-128 128

Fortezza 80

SSL记录格式 ContentType—— 8 位，上层协议类型 Major version ， Minnor version—— 16 位，主次版本压缩长度： 16 位——加密后数据的长度，不超过 214+204

8字节 EncryptedData fragment—— 密文数据

3.2 SSL记录格式

Content

TypeMajor

VersionMinor

VersionCompressed

Length

Plaintext(optionally

compressed)

MAC(0,16,or 20 bytes)

encr

ypte

d

该协议的作用是标志加密策略的改变。该协议只有一条消息： Change CipherSpec 消息。 Client 和 Server 都发送此消息，通知接收方继该消息之后发送的消息将采用握手层刚协商好的算法、密钥进行压缩，计算 MAC 和加密。 Change Cipherspec 消息的接收方指导记录层将预备读状态拷贝给当前读状态；

Change Cipherspec 消息的发送方指导记录层将预备写状态拷贝给当前写状态。

4 Change Cipher Spec协议

Change Cipherspec 消息由一个值为 1 的单字节构成，用以将挂起状态转至当前状态，导致当前加密处理包用于该连接。

1 1 byte

Alert 协议包括若干个 alert 消息。 Alert 消息的作用是当握手过程或数据加密等操作出错或发生异常情况时，向对方发出警告或中止当前连接。根据错误的严重程度， Alert消息分为两类：警告 alert 消息和致命 alert 消息。致命 alert消息立即中止当前连接，并将与这个连接相关的会话的 session-id 作废，以免这个会话被继续用来建立新的连接。 alert消息被加密传输。

Alert 消息由两个字节构成： Level = 1（ warning）； 2（ fatal） SSL将立即关闭本连接，本会

话的其他连接可以继续，但不能创建新连接。

Alert = 具体警告编码，如： unexpected_message bad_record_mac （均为 fat

al 的警告内容）

5 Alert协议

Level Alert

握手协议层的作用是验证实体身份、协商密钥交换算法、压缩算法和加密算法、完成密钥交换以及生成密钥，用来保护在 SSL 记录中发送的数据。

SSL V3.0 握手协议格式：

6 握手协议

Type Length Content

3 bytes

10种类型的消息

1 byte >=0 bytes

SSL握手协议的流程：交换 Hello 消息，对于算法、交换随机值等协商一致

交换必要的密码参数，以便双方得到统一的 premaster secret

交换证书和相应的密码信息，以便进行身份认证

产生 master secret 把安全参数提供给 SSL记录层检验双方是否已经获得同样的安全参数

6 握手协议Client Server

Tim

e

client hello

server hello

certificate

server_key_exchange

certificate_request

server_hello_done

certificateclient_key_exchange

certificate_verify

change_cipher_specfinished

change_cipher_spec

finished

消息参数描述hello_request Null 服务器发出此信息给客户端启动握手协

议Client_hello 版本，随机数，

会话 id ，密码参数，压缩方法

客户端发出 client_hello启动 SSL会话，该信息标识密码和压缩方法列表，服务器响应

server_hello

certificate X． 509 v3证书链

服务器发出的向客户端验证自己的消息

server_key_exchange 参数，签名密钥交换certificate_request 参数， CAs 服务器要求客户端认证server_done Null 指示服务器的 Hello消息发送完毕certificate_verify 签名对客户证书进行验证client_key_exchange 参数，签名密钥交换finished Hash值验证密钥交换和鉴别过程是成功的

SSL 握手协议使用的消息

6 握手协议

Alert 消息共有 12 种，按功能分为两类：close-notify 消息通知接收方、发方不再使用当前的连接进行消

息的发送。 Client 和 Server 都通过发送此消息来发起结束当前的连接。若一个连接不是通过发警告 close-notify 消息终止的，那么相关的会话将不被恢复。

error alerts 消息检测到错误的一方向将向对方发送 error alerts 消息。一旦发送了或接收到致命的 error alerts 消息，client 和 Server 立即中止当前连接，并忘掉该连接的密钥、 MAC secrets 以及与该连接相关的 session-id 。共有 11 个 error alerts 消息。

5 Alert协议

第一阶段：建立起安全协商客户发送一个 client_hello 消息，包括以下参数：

版本、随机数 (32 位时间戳 +28字节随机序列 ) 、会话 ID 、客户支持的密码算法列表 (CipherSuite) 、客户支持的压缩方法列表

然后，客户等待服务器的 server_hello 消息服务器发送 server_hello 消息，参数：客户建议

的低版本以及服务器支持的最高版本、服务器产生的随机数、会话 ID 、服务器从客户建议的密码算法中挑出一套、服务器从客户建议的压缩方法中

挑出一个

6 握手协议

Client Serverclient hello

server hello

建立安全能力，包括协议版本、会话ID，密码组，压缩方法，初始随机数字

CipherSuite 第一个元素指定了密钥交换的方法， SSL 支持以下一些方法：

RSA ，要求服务器提供一个 RSA 证书 DH(Diffie-Hellman) ，要求服务器的证书中包含了由 CA签名的 DH 公

开参数。客户或者在证书中提供 DH 公开参数，或者在密钥交换消息中提供此参数

EDH(Ephemeral Diffie-Hellman) ，产生临时的密钥， DH 公开参数由发送者的私钥进行签名，接收者用对应的公钥进行验证

匿名的 DH ，不加鉴别。会受到中间人攻击然后，指定以下信息

加密算法，和类型 (流还是分组密码算法 ) HMAC 算法， MD5还是 SHA-1 是否可出口 HashSize Key Material IV Size

6 握手协议

第二阶段：服务器鉴别和密钥交换服务器发送自己的证书，消息包含一个 X.509 证书，或者一条证书链除了匿名 DH 之外的密钥交换方法都需要

服务器发送 server_key_exchange 消息可选的，有些情况下可以不需要。只有当服务器的证书没有包含必需的数据的时候才发送此消息

消息包含签名，被签名的内容包括两个随机数及服务器参数服务器发送 certificate_request 消息

非匿名 server 可以向客户请求一个证书包含证书类型和 CAs

服务器发送 server_hello _done,然后等待应答

6 握手协议

服务器可以发送证书密钥交换和请求证书服务器信号以hello消息段结束

certificate

server_key_exchange

certificate_request

server_hello_done

Client Server

第三阶段：客户鉴别和密钥交换客户收到 server_done 消息后，它根据需要检查服务器提供

的证书，并判断 server_hello 的参数是否可以接受，如果都没有问题的话，发送一个或多个消息给服务器

如果服务器请求证书的话，则客户首先发送一个 certificate消息，若客户没有证书，则发送一个 no_certificate 警告• 然后客户发送 client_key_exchange 消息，消息的内容取决于密钥交换的类型

最后，客户发送一个 certificate_verify 消息，其中包含一个签名，对从第一条消息以来的所有握手消息的 HMAC值( 用 master_secret) 进行签名

6 握手协议

certificateclient_key_exchange

certificate_verify

Client Server

客户机可以发送证书客户机发送密钥交换客户机发送证书验证

第四阶段：结束第四阶段建立起一个安全的连接客户发送一个 change_cipher_spec 消息，并且把协商得到

的 CipherSuite拷贝到当前连接的状态之中然后，客户用新的算法、密钥参数发送一个 finished 消息，这条消息可以检查密钥交换和鉴别过程是否已经成功。其中包括一个校验值，对所有以来的消息进行校验

服务器同样发送 change_cipher_spec 消息和 finished 消息握手过程完成，客户和服务器可以交换应用层数据

6 握手协议


change_cipher_spec

finished

ServerClient

更改密码组合并完成握手协议

密钥交换算法 SSL 记录协议需要： CipherSuite, master secret,and the client a

nd server random values 在 hello 消息中，交换随机数以及各种算法两类密钥交换算法：

RSA ，客户产生一个 48字节的 pre_master_secret ，然后通过服务器的公钥传递给服务器

Diffie-Hellman ，双方协商得到的密钥被用作 pre_master_secret

对于各种密钥交换算法，从 pre_master_secret 计算得到 Master_secret ，然后从内存中删除

Master_secret总是 48字节长，而 pre_master_secret长度不定，取决于密钥交换算法

6 握手协议

Master_secret 的产生 SSL 3.0

Master_secret =MD5(pre_master_secret‖SHA(‘A’‖pre_master_secret ‖ClientHello.random ‖ServerHello.random)) ‖MD5(pre_master_secret‖SHA(‘BB’‖pre_master_secret ‖ClientHello.random ‖ServerHello.random)) ‖MD5(pre_master_secret‖SHA(‘CCC’‖pre_master_secret ‖ClientHello.random ‖ServerHello.random))

TLS 1.0master_secret = PRF(pre_master_secret,“master secret”, ClientHello.random+ ServerHello.random)[0..47]* PRF(secret, label, seed) 为伪随机函数

6 握手协议

伪随机函数 PRF(secret ， label ， seed) P_hash(secret, seed) = +HMAC_hash(secret, A(1) + seed) +HMAC_hash(secret, A(2) + seed) +HMAC_hash(secret, A(3) + seed)+ ... 这里 A() 定义如下： A(0) = seed A(i) = HMAC_hash(secret, A(i-

1)) 伪随机函数 PRF(secret, label, seed) =P_MD5(S1, label + se

ed) XOR P_SHA-1(S2, label + seed); 这里， S1 和 S2 为 secret 的各一半，如果 secret

为奇数个字节，则 S1 和 S2 共享一个字节

6 握手协议

重用一个 SSL 会话客户和服务器在交换 he

llo 消息中，客户要求重用已有的 SSL 会话，服务器同意使用 cache中的会话

* session id跳过第二第三阶段，直

接把 SSL 会话中的参数传递给 SSL 记录层

6 握手协议

client hello

server hello


change_cipher_spec

finished

Client Server

一些常见的攻击手法针对密钥算法的破解

取决于算法的强度，协商过程利用明文模式的攻击

上层协议中常常有一些固定的模式可以参考，比如 http 协议中 get字节串

构造字典 ( 密文 - 密钥对 ) ，查字典TLS办法：用长密钥，使得不可能构造这样的字典

重放攻击TLS 中的 nonce 有 32字节 (包含时间戳 ) ，可用于避免重放攻击

会话 ID 标识了一个完整的会话，要重放部分会话需要知道私钥

中间人攻击通过证书来认证对方对于双方都是匿名的模式，中间人攻击也是成立的

7 TLS/SSL安全性分析

历史上针对 SSL/TLS 的攻击

PRNGMillion-message attack其它

7 TLS/SSL安全性分析

SSL 协议在“重放攻击”上，有它独到的解决办法：

为每一次安全连接产生了一个 128 位长的随机数——“连接序号”

理论上，攻击者提前无法预测此连接序号，因此不能对服务器的请求做出正确的应答。但是计算机产生的随机数是伪随机数，它的实际周期要远比 2128小，更为危险的是有规律性，所以说 SSL 协议并没有从根本上解决“信息重放”这种攻击方法。

有效的解决方法是采用“时间戳”。但是这需要解决网络上所有节点的时间同步问题。

7 .1 SSL ： PRNG 攻击

Netscape v1.1 版本中存在，利用随机数发生器的弱点。先看随机数发生器

global variable seed;RNG_CreateContext() {(seconds, microseconds) = time of day; /* Time elapsed sinc

e 1970 */pid = process ID; ppid = parent process ID;a = mklcpr(microseconds);b = mklcpr(pid + seconds + (ppid << 12));seed = MD5(a, b);mklcpr(x) /* not cryptographically significant; shown for co

mpleteness */return ((0xDEECE66D * x + 0x2BBB62DC) >> 1);}


global variable challenge, secret_key; RNG_GenerateRandomBytes() {

x = MD5(seed);seed = seed + 1;return x;}

create_key() {RNG_CreateContext();tmp = RNG_GenerateRandomBytes();tmp = RNG_GenerateRandomBytes();challenge = RNG_GenerateRandomBytes();secret_key = RNG_GenerateRandomBytes();}

种子关联： pid, ppid, seconds, microsecondsSeconds往往可以获得， microseconds未知如果在目标机器上有账号，则 pid 和 ppid 可以获得否则，可以寻找 pid 和 ppid 的。

对于大多数 UNIX平台， pid+(ppid << 12) 只有 27 位


PRNG 的启示 PRNG并不是 SSL 协议本身的缺陷，而是实现上导致的缺

陷随机数对于安全协议或者安全系统的重要性

源码开放的另一层含义关键的代码接受公众的审视

Reference:

Ian Goldberg and David Wagner, “Randomness and the Netscape Browser”, January 1996 Dr. Dobb's Journal


在 RSA 算法作加密运算的时候，首先对明文消息进行编码，其格式为：

假设密文 C ，攻击者可以产生一系列整数 S并计算 C' =C*(Se) mod n ，在解密的时候，每一个 C' 对应于一个 M' 。大多数的M' 不会满足上面的格式，但是有 2-16 的概率会产生这样的结果(因为前两个字节是确定的 ) 。攻击者可以找到一系列满足条件的 S ，然后推断出密文 C 对应的明文 M 。这个过程大约需要 22

0=1,000,000 个消息和应答。攻击实施依赖于

需要一个可以提供解密准确性判断的服务器— 称为 oracle

SSL 实现是否能够精确地告知明文格式不正确？只能得到一个消息的明文，无法得到私钥

0 2 random bytes 0 message

7 .2 SSL: Million-message attack

MMA 的启示实现 SSL 的时候

对待错误消息如何响应？Contiune? 会不会招致 DOS？返回精确的错误

充分利用明文模式随机数填充

References 1. RFC 3218 2. Bleichenbacher D. , "Chosen Ciphertext Attacks against Protoc

ols Based on RSA Encryption Standard PKCS #1" in Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages:1--12, 1998.

7 .2 SSL: Million-message attack

Export ciphers and distributed cracking举例 40 位 RC4

http://cypherpunks.venona.com/date/1995/07/msg00052.html downgrade attacks

往 SSL 的低版本退化密码算法的退化

7 .3 针对 SSL 的其他攻击

SYN 包 (synchronize) TCP 连接的第一个包 , 非常小的一种数据包。

SYN攻击是最常见又最容易被利用的一种攻击手法。

SYN攻击属于 DOS攻击的一种，它利用 TCP 协议缺陷，通过发送大量的半连接请求，耗费 CPU和内存资源。

7 .3 其他攻击： SYN 攻击

SYN攻击

SYN攻击原理

SYN攻击除了能影响主机外，还可以危害路由器、防火墙等网络系统。

服务器接收到连接请求（ syn=j），将此信息加入未连接队列，并发送请求包给客户（ syn=k,ack=j+1），此时进入 SYN_RECV状态。

当服务器未收到客户端的确认包时，重发请求包，一直到超时，才将此条目从未连接队列删除。

配合 IP欺骗， SYN攻击能达到很好的效果，通常，客户端在短时间内伪造大量不存在的 IP 地址，向服务器不断地发送 syn包，服务回复确认包，并等待客户的确认，由于源地址是不存在的，服务器需要不断的重发直至超时，这些伪造的 SYN包将长时间占用未连接队列，正常的SYN请求被丢弃，目标系统运行缓慢，严重者引起网络堵塞甚至系统瘫痪。


HACKER短时间内伪造大量不存在的 IP 地址，向服务器不断地发送 syn包 .

服务回复确认包，并等待客户的确认 , 进入相应的 Syn_RECV状态 .

由于源地址是不存在的，服务器需要不断的重发直至超时 .

这些伪造的 SYN包将长时间占用未连接队列，正常的SYN请求被丢弃，目标系统运行缓慢，严重者引起网络堵塞甚至系统瘫痪。


HACKER Server

Syn_REC

V（K）

Syn_RECV

（K+1）

………

不停发SYN,直至耗完

SERVER资源

SYN攻击防范技术归纳起来，主要有两大类 :

通过防火墙、路由器等过滤网关防护，通过加固 TCP/IP 协议栈防范 .

但必须清楚的是， SYN攻击不能完全被阻止，我们所做的是尽可能的减轻 SYN攻击的危害，除非将 TCP 协议重新设计。


序列号猜测攻击 TCP 建立连接分为三个步骤 , 称为三次握手法。在连接的

建立过程中 ,主机 A 和 B 的 TCP 模块分别使用自己的初始序列号 ISN (initial sequence number) 。

如果 TCP 的序列号被猜测到 ,那么攻击者就可以与要攻击的服务器“完成” TCP 的三次握手 ,并建立一个“真正”的 TCP 连接 ,而在此过程中攻击者甚至不需要收到任何发自服务器的响应。

7 .3 其他攻击：序列号猜测攻击

序列号猜测攻击原理对于一个需要授权用户才可以访问的服务器而言 ,

当攻击者能够猜测出要攻击的系统用于下一次连接时使用的初始序列号时 ,就能够欺骗这台服务器 , 通过假冒对该服务器 SYN/ ACK包的应答来欺骗服务器连接已经建立。

在一次攻击过程中 ,首先主机要以真实的身份做几次尝试性的连接。通常 ,这个过程被重复若干次 ,在每次连接过程中把其中的 ISN 号记录下来 , 同时 ,攻击者通过多次统计 , 对 RTT(round - trip time 往返时间 ) 进行平均求值。 RTT 被用来猜测下一次可能的 ISN 。


对 TCP 序列号的猜测不仅发生在三次握手的过程中 ,还发生在连接建立后的数据传送过程中。一般 TCP 的序列号要猜测很多次 , 在这之中可能会出现几种情况 :

1) 如果猜测正确 , 数据将会放到接收缓冲区中 ; 2) 如果序列号小于目的主机所期望的序列号 ,包被丢

弃 ; 3) 如果序列号大于目的主机所期望的序列号 ,但是小

于 TCP 的接收窗口范围 ,将被放到一个悬挂队列中 ,因为有可能是后发送的数据先到达了 ;

4) 如果不是目的主机所期望的序列号 ,又不在 TCP 的接收窗口范围内 ,包被丢弃。

假设主机 C 假冒服务器 A 信任的主机 B 向服务器 A 发出连接请求 , 右图是攻击示意图。


利用 TCP 序列号猜测的攻击方式：利用这个弱点可以实施多种不同类型的攻击 ,包括 :

新型的拒绝服务 (DoS ,Denial of Service) 攻击 ,即切断单个网络服务器的联络并使应用软件和网络看上去很不稳定。

信息投毒型攻击 ,即向准备发布的数据流中插入伪信息 , 如发表虚假的新闻报道或欺骗性股价信息等 ;

话路劫持 ,即接管用户与计算机系统的连接 , 让劫持者以用户的身份进行应用软件的操作 , 如操纵本应该只允许用户本人使用的财务软件或互联网基础设施管理系统等。


序列号猜测攻击防范

有许多种可行的办法用来减少 TCP 序列号猜测攻击的威胁 ,包括：使用防火墙进行包过滤不使用依赖基于主机地址认证的应用程序从更根本的角度改进 TCP 生成 ISN 的算法等

由于 TCP 序列号猜测攻击的难易程度与 TCP 协议实现方法息息相关 , 防御这种攻击的措施不仅在于使用外在的安全屏障 ,更重要的是要求系统开发商在实现 TCP 协议中采用安全的 ISN 实现方法 ,减少猜中 TCP 序列号的概率。


IE处理内嵌在 HTTP页面中的 HTTPS 对象存在一个漏洞它只检查 HTTPS 服务器的证书是否由可信的 CA签名

的，而完全忽略该证书是否有适当的名字，以及是否已经过期。

对于当前这个页面而言，其实并不危险问题在于

IE 会把这个证书缓存起来，并标记为可信任的，一直到浏览器的会话结束

这意味着，假如说， IE 客户在访问一个 HTTP页面时，如果该页面被插入一个包含指向有问题的 SSL server的 HTTPS 对象 (比如说一个 image) 的话， IE 不会警告遇到一个非法的证书，只要这个证书确实是被可信CA签名的

7 .4Microsoft IE 中 SSL/TLS 的一个漏洞

IE 中 SSL/TLS 的漏洞的情形：假如说中间人在服务器返回的页面上加上一句话 <img src="https://www.yoursite.com/nonexistent.gif" widt

h=1 height=1> HTTPS部分显示的是一个被偷来的或者过期的 www.shop.com

的证书，这个证书是有效签名的，但是 IE并不检查证书中的名字和过期情况

如果客户通过 HTTPS 连接到 yoursite网站上， IE将认为这是可信的站点，而不再进一步检查

……

参考： http://archives.neohapsis.com/archives/vulnwatch/2001-q4/0077.html http://archives.neohapsis.com/archives/vulnwatch/2001-q4/0080.html

7 .4Microsoft IE 中 SSL/TLS 的一个漏洞

电子科技大学计算机学院

tls/ssl

Documents