SSL/TLS会话的流量分析
http://blog.fourthbit.com/2014/12/23/traffic-analysis-of-an-ssl-slash-tls-session/
我希望这篇文章能够说明使用SSL/TLS时在协议层发生了哪些事情。为了实现分析目的，我将用非阻塞模式实现一个基于OpenSSL的TCP客户端和服务端，编译工具使用的的是我熟悉的Scheme Gambit。
需要注意的是：SSL/TSL对应用程序的安全防护只等同于底层基础组件（网络与主机层）。 SSL/TLS是一种独立的协议，它把自己植入到应用层协议（通常指HTTP，但适用于其它协议）和传输层协议(TCP)之间。如此操作，TLS仅要求底层和上层协议做出一些小小的改动就能适配，因此，它对用户来说几乎是透明的，换句话说，用户可以不关心它的存在。当然，它也有一些缺陷，在某些方面有些限制（比如说不能用于UDP）。
自从问世之后，SSL/TLS有了长足的发展。如今我们认为SSL2.0和3.0版本是不安全的，因此，它们被新的TLS 1.0/1.1/1.2版本替代。这些协议的历史是一个有趣的主题。
协议描述
如之前描述的那样，TLS协议位于应用层和传输层之间。它被分为两个主要的子层。这是TLS协议的通用结构，它在网络栈中的位置如下图所示：
较低层位于TCP之上，作为一种面向连接的可靠传输层协议。这一层基本上由TLS Record Protocol组成。简而言之，Record Protocol首先把高层协议数据分解成214字节以下的块，然后选择性地压缩数据，增加消息鉴权代码，最后根据根据密码规范（协商）规范对数据进行加密，添加SSL Record头域。需要注意的一点是：每个数据块都被打包成不保留客户端消息边界的结构，这意味着同一类型的多个消息可以合并为一个单一的结构。
下图描述构建SSL Record的处理过程：
-----------+data --+--------------> 1. Fragment data-----------++------------------------+| || |+------------------------+2. Compress data (generally no compression applied)+------------------------+----+| |MAC | Add a Message Authentication Code| | |+------------------------+----+3. Encrypt data+-----------------------------+|ciphertext || |+-----------------------------+4. Add header+----+-----------------------------+TLS Record | |ciphertext | Add a TLS Record headerheader | | |+----+-----------------------------+
较高一层位于SSL Record协议层之上，它由四种子协议组成。每种子协议都有其特定的功能目的，作用于通信过程中的不同阶段：
Handshake Protocol握手协议: SSL握手协议涉及有Client和Server之间交互的四组消息（有时称为flights）。每组消息通常在一个独立的TCP segment上传输。下图展示了整个流程的摘要，并提供了可选步骤。请注意：ChangeCipherSpec 消息不属于本协议，因为它本身就是一种协议。如下所示：
TLS Handshake+-----+ +-----+| | | || | ClientHello | || o----------------------------> | || | | |CLIENT | | ServerHello | | SERVER| | [Certificate] | || | [ServerKeyExchange] | || | [CertificateRequest] | || | ServerHelloDone | || | <----------------------------o || | | || | [Certificate] | || | ClientKeyExchange | || | [CertificateVerify] | || | ** ChangeCipherSpec ** | || | Finished | || o----------------------------> | || | | || | ** ChangeCipherSpec ** | || | Finished | || | <----------------------------o || | | |+-----+ +-----+Optional messages--------------------------------------------------------------------------------------------Certificate (server) needed with all key exchange algorithms, except for anonymous ones.ServerKeyExchange needed in some cases, like Diffie-Hellman key exchange algorithm.CertificateRequest needed if Client authentication is required.Certificate (client) needed in response to CertificateRequest by the server.CertificateVerify needed if client Certificate message was sent.
ChangeCipherSpec Protocol: 它使先前协商的参数生效，对通信加密。
Alert Protocol警报协议: 通信异常时，用它指示说明可能危及安全性的潜在问题。
Application Data Protocol应用数据协议: 它接受任意数据（通常是应用层数据），并提供安全通信信道。I
可以把多条消息组合成一条Record层消息，但这些消息必须属于同一个子协议。因此，每个子协议都必须有自己的分割方法定义（即有自己的消息长度描述）。
Record Protocol 格式
TLS Record 报头包含三个字段，都是高层构建数据所须要的：
Byte 0: TLS record 类型
Bytes 1-2: TLS 版本号(major/minor)
Bytes 3-4: record 数据的长度（不包含报头本身）。最大支持16384 (16K)。
record type (1 byte)// version (1 byte major, 1 byte minor)/ // / length (2 bytes)/ / /+----+----+----+----+----+| | | | | || | | | | | TLS Record header+----+----+----+----+----+Record Type Values dec hex-------------------------------------CHANGE_CIPHER_SPEC 20 0x14ALERT 21 0x15HANDSHAKE 22 0x16APPLICATION_DATA 23 0x17Version Values dec hex-------------------------------------SSL 3.0 3,0 0x0300TLS 1.0 3,1 0x0301TLS 1.1 3,2 0x0302TLS 1.2 3,3 0x0303
握手协议格式
这是TLS中最复杂的子协议。规范主要聚焦于此，因为它处理建立安全连接所需的全部机制。下图显示了握手协议消息的一般结构。TLS规范中有10种握手消息类型（不计算扩展），接下来我将挨个说明这些握手消息的具体格式。
|||Record Layer | Handshake Layer| || | ...more messages+----+----+----+----+----+----+----+----+----+------ - - - -+--| 22 | | | | | | | | | ||0x16| | | | | | | | |message |+----+----+----+----+----+----+----+----+----+------ - - - -+--/ / | \ \----\-----\ |/ / | \ \type: 22 / | \ handshake message length/ type/length: arbitrary (up to 16k)Handshake Type Values dec hex-------------------------------------HELLO_REQUEST 0 0x00CLIENT_HELLO 1 0x01SERVER_HELLO 2 0x02CERTIFICATE 11 0x0bSERVER_KEY_EXCHANGE 12 0x0cCERTIFICATE_REQUEST 13 0x0dSERVER_DONE 14 0x0eCERTIFICATE_VERIFY 15 0x0fCLIENT_KEY_EXCHANGE 16 0x10FINISHED 20 0x14
HelloRequest: 允许Server端重启握手协商。它不经常使用。如果连接已经建立很长时间（以小时为单位），以至于安全性被削弱，那么Server端可以用这个消息强制Client端重新协商会话密钥。
|||| Handshake Layer||
- ---+----+----+----+----+| | | | |4 | 0 | 0 | 0 | 0 |
- ---+----+----+----+----+/ | \ \---------\/ \ \
record \ length: 0
length \type: 0
ClientHello: 这个消息通常用于启动一个TLS握手协商。它携带一个Client端支持的密码套件列表供Server端选择（最好是强度最大的）；一个压缩方法列表；一个支持的扩展列表。它甚至还提供一个SessionId 字段，为Client端重启先前会话提供一种可能性。
|||| Handshake Layer|| - ---+----+----+----+----+----+----+------+----+----------+--------+-----------+----------+| 1 | | | | | |32-bit| |max 32-bit| Cipher |Compression|Extensions||0x01| | | | 3 | 1 |random| |session Id| Suites | methods | | - ---+----+----+----+----+----+----+------+----+----------+--------+-----------+----------+/ | \ \---------\ \----\ \ \/ \ \ \ \ SessionId record \ length SSL/TLS \ length \ version SessionIdtype: 1 (TLS 1.0 here) lengthCipherSuites+----+----+----+----+----+----+ | | | | | | | | | | | | | | +----+----+----+----+----+----+\-----\ \-----\ \----\\ \ \length cipher Id cipherIdCompression methods (no practical implementation uses compression)+----+----+----+ | | | | | 0 | 1 | 0 | +----+----+----+\-----\ \\ \length: 1 cmp Id: 0Extensions+----+----+----+----+----+----+----- - - | | | | | | | | | | | | | |...extension data +----+----+----+----+----+----+----- - -\-----\ \-----\ \----\\ \ \length Extension Extension dataId lengthServerHello: ServerHello 消息非常类似于ClientHello 消息是，但它只包含一个加密套件和一种压缩方法。如果它包含一个SessionId (SessionId 长度大于零)，那么它给Client端的信号就是可以在将来尝试重用。
|||| Handshake Layer|| - ---+----+----+----+----+----+----+----------+----+----------+----+----+----+----------+| 2 | | | | | | 32byte | |max 32byte| | | |Extensions||0x02| | | | 3 | 1 | random | |session Id| | | | | - ---+----+----+----+----+----+----+----------+----+----------+--------------+----------+/ | \ \---------\ \----\ \ \ \----\ \/ \ \ \ \ SessionId \ Compression record \ length SSL/TLS \ (if length > 0) \ method length \ version SessionId \type: 2 (TLS 1.0 here) length CipherSuiteCertificate: 消息的包体包含一个公钥证书链。证书链让TLS能够支持证书层次架构和PKIs（公钥基础架构）。
|||| Handshake Layer|| - ---+----+----+----+----+----+----+----+----+----+----+-----------+---- - -| 11 | | | | | | | | | | ||0x0b| | | | | | | | | |certificate| ...more certificate - ---+----+----+----+----+----+----+----+----+----+----+-----------+---- - -/ | \ \---------\ \---------\ \---------\/ \ \ \ \ record \ length Certificate Certificate length \ chain lengthtype: 11 lengthServerKeyExchange: 这个消息携带Client端需要从Server端获取的密钥交换算法参数，以便之后的对称加密。它是可选的，因为并不是所有密钥交换都要求Server端显式地发送消息。事实上，在大多数情况下，Certificate 消息足以让Client端与Server端安全地通信premaster 密钥。这些参数的格式完全取决于所选的CipherSuite，即前文描述的ServerHello消息里设定的值。
|||| Handshake Layer||
- ---+----+----+----+----+----------------+| 12 | | | | algorithm ||0x0c| | | | parameters |
- ---+----+----+----+----+----------------+/ | \ \---------\/ \ \
record \ length
length \type: 12
CertificateRequest: 当Server端要求对Client端身份验证时使用的消息。Web服务中比较罕见，但在某些场合中非常重要。这个消息不仅要求Client端提供证书，还告诉Client端哪些类型的证书是可接受的。此外，它还指明哪些证书颁发机构被认为是可信任的。
|||| Handshake Layer||
- ---+----+----+----+----+----+----+---- - - --+----+----+----+----+-----------+-- -| 13 | | | | | | | | | | | C.A. ||0x0d| | | | | | | | | | |unique name|
- ---+----+----+----+----+----+----+---- - - --+----+----+----+----+-----------+-- -/ | \ \---------\ \ \ \----\ \-----\/ \ \ \ Certificate \ \
record \ length \ Type 1 Id Certificate \
length \ Certificate Authorities length \type: 13 Types length Certificate Authoritylength
ServerHelloDone: 此消息说明完成握手协商的Server部分。它不携带任何附加信息。
|||| Handshake Layer||
- ---+----+----+----+----+| 14 | | | |4 |0x0e| 0 | 0 | 0 |
- ---+----+----+----+----+/ | \ \---------\/ \ \
record \ length: 0
length \type: 14
ClientKeyExchange: 它为Server端提供必要的数据，以生成对称加密的密钥。消息格式非常类似于ServerKeyExchange，它主要依赖于Server端所选择的密钥交换算法。
|||| Handshake Layer||
- ---+----+----+----+----+----------------+| 16 | | | | algorithm ||0x10| | | | parameters |
- ---+----+----+----+----+----------------+/ | \ \---------\/ \ \
record \ length
length \type: 16
CertificateVerify: Client端使用些消息来证明Server端持有与公钥证书相对应的私钥。消息中包含Client端的数字签名的散列信息。如果Server端向Client端发CertificateRequest消息，那么要求Client发送待验证的证书。同样，信息的精确大小和结构取决于约定的算法。在所有场景中，server端输入的散列函数的输入信息都是相同的。
|||| Handshake Layer||
- ---+----+----+----+----+----------+| 15 | | | | signed ||0x0f| | | | hash |
- ---+----+----+----+----+----------+/ | \ \---------\/ \ \
record \ length
length \type: 15
Finished: 此消息标志着TLS协商完成，CipherSuite 被成功激活。 既然协商已经成功，那么此消息就应该以加密的形式发送，因此，在发送这条消息之前，必须先发送ChangeCipherSpec 协议报文来激活加密。Finished 消息包含之前所有握手消息组合的散列信息签名，跟着一个特殊的编号标识server/client 角色、还有master 密码和填充数据。这里的散列计算结果不同于CertificateVerify hash，因为它包含更多的握手信息。
|||| Handshake Layer||
- ---+----+----+----+----+----------+| 20 | | | | signed ||0x14| | | | hash |
- ---+----+----+----+----+----------+/ | \ \---------\/ \ \
record \ length
length \type: 20
ChangeCipherSpec 协议格式
这是最简单的协议，它只有一条消息。之所以把它作为一个单独的协议，而不是握手协议的一部分，是因为Record 层的封装需要。TLS马上要对整个Record 层消息进行加密了，Changeciperspec 消息标记着加密正式激活，由于不能只对消息的某一部分执行加密，因此，其它消息都不可能与changeciperspec 消息组合。那么避免这种组合的最佳方式就是把这条消息提升为协议状态。
下图是ChangeCipherSpec消息的唯一结构：
|||Record Layer | ChangeCipherSpec Layer||+----+----+----+----+----+----+| 20 | | | | | ||0x14| | | 0 | 1 | 1 |+----+----+----+----+----+----+/ / |/ / |type: 20 / |//length: 1
Alert 协议格式
Alert协议也很简单。它定义了两个字段：严重级别和警报描述。第一个字段表示警报的来得程度（1表示警告，2表示致命）；第二个字段携带一个编码，描述确切的条件。支持的alert描述取决于SSL/TLS 版本。
|||Record Layer | Alert Layer||+----+----+----+----+----+----+----+| 21 | | | | | | ||0x15| | | 0 | 2 | | |+----+----+----+----+----+----+----+/ / |/ / |type: 21 / |//length: 2Alert severity dec hex----------------------------------------WARNING 1 0x01FATAL 2 0x02TLS 1.0 Alert descriptions dec hex----------------------------------------CLOSE_NOTIFY 0 0x00UNEXPECTED_MESSAGE 10 0x0ABAD_RECORD_MAC 20 0x14DECRYPTION_FAILED 21 0x15RECORD_OVERFLOW 22 0x16DECOMPRESSION_FAILURE 30 0x1EHANDSHAKE_FAILURE 40 0x28NO_CERTIFICATE 41 0x29BAD_CERTIFICATE 42 0x2AUNSUPPORTED_CERTIFICATE 43 0x2BCERTIFICATE_REVOKED 44 0x2CCERTIFICATE_EXPIRED 45 0x2DCERTIFICATE_UNKNOWN 46 0x2EILLEGAL_PARAMETER 47 0x2FUNKNOWN_CA 48 0x30ACCESS_DENIED 49 0x31DECODE_ERROR 50 0x32DECRYPT_ERROR 51 0x33EXPORT_RESTRICTION 60 0x3CPROTOCOL_VERSION 70 0x46INSUFFICIENT_SECURITY 71 0x47INTERNAL_ERROR 80 0x50USER_CANCELLED 90 0x5ANO_RENEGOTIATION 100 0x64
ApplicationData 协议格式
这层协议的任务是正确封装来自应用层的数据，这样，它就可以无缝地由底层协议（TCP处理），而不需要强制修改通信协议栈的任何一层。协议的消息格式遵循前面消息相同的结构。
|||Record Layer | ApplicationData Layer (encrypted)||+----+----+----+----+----+----+----+--- - - - - - - --+---------+| 23 | | | | length-delimited data | ||0x17| | | | | | | | MAC |+----+----+----+----+----+----+----+--- - - - - - - --+---------+/ / |/ / |type: 23 / |//length: arbitrary (up to 16k)
SSL/TLS 流量分析
流量分析的主要目的是测试我当前为Gambit Scheme 编译器开发的TLS client端。我将使用Wireshark 抓包，client端基于Scheme，内置支持SSL/TLS；测试服务端（带证书），是OpenSSL发行版本的部分。Server端监听端口443，所有通信都通过环回设备完成。在Wireshark中查看TLS包的最简单方式是使用协议过滤器‘ssl’。
第一条消息 (client –> server)
Once the server is running and waiting for connection, the client can initiate it. This is the first packet, sent by the client:
一旦Server端运行并等待连接，Client端就可以开始了。下面是由Client发出的第一个数据包：
Full contents of the packet0000 02 00 00 00 45 00 00 98 13 ed 40 00 40 06 00 00 ....E.....@.@...0010 7f 00 00 01 7f 00 00 01 ec 26 01 bb 43 7c ee 74 .........&..C|.t0020 60 b5 50 0a 80 18 31 d7 fe 8c 00 00 01 01 08 0a `.P...1.........0030 21 62 1e 1e 21 62 1e 1e 16 03 01 00 5f 01 00 00 !b..!b......_...0040 5b 03 01 54 9a ab 72 98 65 11 2f da 9e cf c9 db [..T..r.e./.....0050 6c bd 4b 4c 56 4b 0c a5 68 2b aa 60 1f 38 66 e7 l.KLVK..h+.`.8f.0060 87 46 b2 00 00 2e 00 39 00 38 00 35 00 16 00 13 .F.....9.8.5....0070 00 0a 00 33 00 32 00 2f 00 9a 00 99 00 96 00 05 ...3.2./........0080 00 04 00 15 00 12 00 09 00 14 00 11 00 08 00 06 ................0090 00 03 00 ff 01 00 00 04 00 23 00 00 .........#..------------Family: IP0000 02 00 00 00 ....IP protocol0000 45 00 00 98 13 ed 40 00 40 06 00 00 7f 00 00 01 E.....@.@.......0010 7f 00 00 01 ....TCP protocol0000 ec 26 01 bb 43 7c ee 74 60 b5 50 0a 80 18 31 d7 .&..C|.t`.P...1.0010 fe 8c 00 00 01 01 08 0a 21 62 1e 1e 21 62 1e 1e ........!b..!b..------------TLSv1 protocol0000 16 03 01 00 5f 01 00 00 5b 03 01 54 9a ab 72 98 ...._...[..T..r.0010 65 11 2f da 9e cf c9 db 6c bd 4b 4c 56 4b 0c a5 e./.....l.KLVK..0020 68 2b aa 60 1f 38 66 e7 87 46 b2 00 00 2e 00 39 h+.`.8f..F.....90030 00 38 00 35 00 16 00 13 00 0a 00 33 00 32 00 2f .8.5.......3.2./0040 00 9a 00 99 00 96 00 05 00 04 00 15 00 12 00 09 ................0050 00 14 00 11 00 08 00 06 00 03 00 ff 01 00 00 04 ................0060 00 23 00 00 .#..TLSv1 Record protocol0000 16 03 01 00 5f ...._16 Handshake protocol type03 01 SSL version (TLS 1.0)5f Record length (95 bytes)TLSv1 Handshake protocol0000 01 00 00 5b 03 01 54 9a ab 72 98 65 11 2f da 9e ...[..T..r.e./..0010 cf c9 db 6c bd 4b 4c 56 4b 0c a5 68 2b aa 60 1f ...l.KLVK..h+.`.0020 38 66 e7 87 46 b2 00 00 2e 00 39 00 38 00 35 00 8f..F.....9.8.5.0030 16 00 13 00 0a 00 33 00 32 00 2f 00 9a 00 99 00 ......3.2./.....0040 96 00 05 00 04 00 15 00 12 00 09 00 14 00 11 00 ................0050 08 00 06 00 03 00 ff 01 00 00 04 00 23 00 00 ............#..01 ClientHello message type00 00 5b Message length03 01 SSL version (TLS 1.0)54 .. b2 32-bytes random number00 Session Id length00 2e Cipher Suites length (46 bytes, 23 suites)00 39 .. ff 23 2-byte Cipher Suite Id numbers01 Compression methods length (1 byte)00 Compression method (null)00 04 Extensions length (4 bytes)00 23 SessionTicket TLS extension Id00 00 Extension data length (0)
第二条消息 (server –> client)
第一条消息中只 包含一个TLS握手消息(ClientHello)，它是Client端发向Server端的。Server端响应ClientHello的TCP数据包里包含了三个握手信息：ServerHello、 Certificate 和 ServerHelloDone（没有ServerKeyExchange 或 CertificateRequest）。下一个数据包和之后的实例，我将省略底层协议(TCP/IP)的内容。
ServerHello message 0000 16 03 01 00 35 02 00 00 31 03 01 54 9a ab 72 85 ....5...1..T..r.
0010 91 a4 a7 a9 27 fe 3d e4 da f6 38 a5 aa 6e 5a 2f ....'.=...8..nZ/
0020 31 90 5b 41 b0 5d de d8 9d ae f6 00 00 35 00 00 1.[A.].......5..
0030 09 ff 01 00 01 00 00 23 00 00 .......#..16 Handshake protocol type03 01 SSL version (TLS 1.0)35 Record length (53 bytes)02 ServerHello message type00 00 31 Message length (49 bytes)03 01 SSL version (TLS 1.0)54 9a ab 72 First 4 bytes of random (Unix time)85 .. f6 Last 28 bytes of the random number00 Session Id length00 35 Selected Cipher Suite (RSA with AES-256-CBC SHA)00 Selected compression method (null)00 09 Extensions lengthff 01 00 01 00 Extension (Renegotiation Info)00 23 00 00 Extension (SessionTicket TLS)Certificate message 0000 16 03 01 01 e4 0b 00 01 e0 00 01 dd 00 01 da 30 ...............0
0010 82 01 d6 30 82 01 3f 02 01 01 30 0d 06 09 2a 86 ...0..?...0...*.
0020 48 86 f7 0d 01 01 04 05 00 30 45 31 0b 30 09 06 H........0E1.0..
0030 03 55 04 06 13 02 41 55 31 13 30 11 06 03 55 04 .U....AU1.0...U.
0040 08 13 0a 53 6f 6d 65 2d 53 74 61 74 65 31 21 30 ...Some-State1!0
0050 1f 06 03 55 04 0a 13 18 49 6e 74 65 72 6e 65 74 ...U....Internet
0060 20 57 69 64 67 69 74 73 20 50 74 79 20 4c 74 64 Widgits Pty Ltd
0070 30 1e 17 0d 39 39 30 35 30 31 30 31 32 36 33 35 0...990501012635
0080 5a 17 0d 39 39 30 35 33 31 30 31 32 36 33 35 5a Z..990531012635Z
0090 30 22 31 0b 30 09 06 03 55 04 06 13 02 44 45 31 0"1.0...U....DE1
00a0 13 30 11 06 03 55 04 03 13 0a 54 65 73 74 73 65 .0...U....Testse
00b0 72 76 65 72 30 81 9f 30 0d 06 09 2a 86 48 86 f7 rver0..0...*.H..
00c0 0d 01 01 01 05 00 03 81 8d 00 30 81 89 02 81 81 ..........0.....
00d0 00 fa 23 7a 03 2a 27 b1 c3 09 64 ce 36 ab eb d0 ..#z.*'...d.6...
00e0 08 16 75 54 68 6f 39 2e d0 9e 81 ed 91 f8 2b 48 ..uTho9.......+H
00f0 0e 59 10 63 0e bc ff c3 1b 4f 7a 2e d2 97 45 01 .Y.c.....Oz...E.
0100 c2 fd 20 68 98 63 76 34 48 73 3d 3e a1 74 d1 13 .. h.cv4Hs=>.t..
0110 b5 30 2b 4d a6 a4 e7 17 74 9c 2e 96 e6 82 01 a3 .0+M....t.......
0120 2a 29 66 59 89 f6 6a 2e de 99 d8 cc 8d 75 4b b7 *)fY..j......uK.
0130 35 96 db 11 a0 20 60 13 59 03 77 d8 a8 1f 26 78 5.... `.Y.w...&x
0140 38 8d 78 b5 52 31 22 c8 b8 64 c3 46 5f d4 8f e0 8.x.R1"..d.F_...
0150 83 02 03 01 00 01 30 0d 06 09 2a 86 48 86 f7 0d ......0...*.H...
0160 01 01 04 05 00 03 81 81 00 c8 0c fa c6 c0 93 c0 ................
0170 df 8d 27 da f9 17 f6 81 c1 97 99 ba ef 64 0c ca ..'..........d..
0180 cc 2f b9 45 4d e4 6a af cd cb 12 17 00 67 28 f5 ./.EM.j......g(.
0190 d6 63 a3 3c d6 7c df f1 b8 6b a9 e5 ba 05 93 e2 .c.<.|...k......
01a0 ab 3f ec 5d 82 c6 aa 18 7b 32 ce 58 04 a2 ac f8 .?.]....{2.X....
01b0 7a 4a 8b 8d 07 95 6e 7a 23 df 7f 61 54 55 3d 32 zJ....nz#..aTU=2
01c0 13 e2 e8 95 0b 3f 18 d7 2a e9 a3 7d 7d 8b 2c d9 .....?..*..}}.,.
01d0 22 91 6e 69 bb 3f 03 7f 75 22 5f 41 22 68 9b dd ".ni.?..u"_A"h..
01e0 ec 4c 0f f0 9e f9 b6 25 13 .L.....%.16 Handshake protocol type03 01 SSL version (TLS 1.0)01 e4 Record length (443 bytes)0b Certificate message type00 01 e0 Message length00 01 dd Certificates length00 .. 13 Certificates dataServerHelloDone message0000 16 03 01 00 04 0e 00 00 00 .........16 Handshake protocol type03 01 SSL version (TLS 1.0)00 04 Record length (4 bytes)0e ServerHelloDone message00 00 00 Message length
第三条消息 (client –> server)
看起来一切正常，符合上面的协议概述。Client端和Server端现在已经就所用加密算法（RSA密钥交换，AES-256-CBC对称加密、SHA 消息散列）、压缩算法（不压缩）和TLS扩展（SessionTicket TLS, Renegotiation Info）达成一致。此外，Client端现在已经拥有Server端的证书，因此它可以判断Server端是否可信。下一个数据包将由Client端发送，携带以下信息：ClientKeyExchange、 ChangeCipherSpec、 Finished (已经加密)。
ClientKeyExchange message0000 16 03 01 00 86 10 00 00 82 00 80 2d 28 e4 30 eb ...........-(.0.0010 31 35 b0 4b 5e 4c 4d c6 ee 01 f5 33 e7 f8 3f 9b 15.K^LM....3..?.0020 d7 53 fc 5c e0 2d d6 12 ba 55 f8 46 ab 73 d8 3d .S.\.-...U.F.s.=0030 b0 0a f7 03 7f 58 e0 32 8f 91 1f b8 cf 56 aa 89 .....X.2.....V..0040 9e 27 84 08 ec 78 f8 74 0c d3 80 f2 ec 04 65 e1 .'...x.t......e.0050 3e 92 91 52 b5 5e aa 67 e9 e6 40 e9 10 67 3c 3f >..R.^.g..@..g<?0060 73 f7 62 4a 0c 42 30 c1 06 6f 53 2f c2 6b d5 c8 s.bJ.B0..oS/.k..0070 67 6f 06 d7 92 86 6e 1d 4d dd 6b 3f b0 26 6c 25 go....n.M.k?.&l%0080 2c d8 81 5a 80 e0 e2 cc d1 62 9c ,..Z.....b.16 Handshake protocol type03 01 SSL version (TLS 1.0)00 86 Record length (134 bytes)10 ClientKeyExchange message type00 00 82 Message length (130 bytes)00 .. 9c RSA encrypted key data (premaster secret)ChangeCipherSpec message0000 14 03 01 00 01 01 ......14 ChangeCipherSpec protocol type03 01 SSL version (TLS 1.0)00 01 Message length (1 byte)01 ChangeCipherSpec messageFinished message (encrypted)0000 16 03 01 00 30 0c c1 86 73 a4 a3 26 62 30 21 7f ....0...s..&b0!.0010 c3 2f 1a 83 34 2d 57 f0 e2 0d 37 d4 51 66 08 22 ./..4-W...7.Qf."0020 b0 ea b4 a4 1e 81 2a fd 5f 07 47 9f b7 2c 0a dc ......*._.G..,..0030 65 08 77 40 2a e.w@*16 Handshake protocol type03 01 SSL version (TLS 1.0)00 30 Message length (48 bytes)0c .. 2a Encrypted Finished message
第四条消息 (server –> client)
Client端发送ChangeCipherSpec和Finished消息之后，Server端也要做同样的事情，这样才能双边启动对称密钥加密套件，执行加密的通信。Server端必须发自己的 ChangeCipherSpec 和 Finished 消息，握手的过程才算成功。这个消息中有一件很有趣的事情发生：一个扩展协议起作用。这个扩展名为Transport Layer Security (TLS) Session Resumption without Server-Side State，这已经说明它的作用了。你应该还记得，它是ClientHello请求的组成部分，并且在server端的ServerHello消息中完成。这个扩展的相关信息，可以查找 RFC5077规范。如文档所述，这个扩展在握手消息中分配的编码是4。
NewSessionTicket message0000 16 03 01 00 aa 04 00 00 a6 00 00 00 00 00 a0 f7 ................0010 2f 0c fd be ce f7 96 86 ca fd da 58 d6 16 b3 3c /..........X...<0020 89 1a a5 a2 af 3c 80 50 7b 99 71 05 3b 0e d3 27 .....<.P{.q.;..'0030 75 78 0d 0a 20 6c e7 1c ce 7b 5d 52 ad f1 04 88 ux.. l...{]R....0040 ec fa 04 c9 6a 74 fc 7b 3d 99 aa 8a ec 7a a3 18 ....jt.{=....z..0050 81 63 2f db b0 16 5b 49 63 f4 53 bc 57 18 27 37 .c/...[Ic.S.W.'70060 f2 7f 66 e6 4d 46 59 2d 17 39 d5 79 a4 49 4d 93 ..f.MFY-.9.y.IM.0070 d2 80 34 8b 49 f5 31 72 7f 7b 41 46 37 9b ae a9 ..4.I.1r.{AF7...0080 3c f0 6f 2e 7f 75 e3 bf 2f d8 fc a4 be cb 2c 84 <.o..u../.....,.0090 01 b2 25 01 23 91 6e c0 c1 09 9d 42 c8 b8 e6 1b ..%.#.n....B....00a0 fe 1e ed b3 52 7f 25 90 ae fc 34 f5 96 1b f0 ....R.%...4....16 Handshake protocol type03 01 SSL version (TLS 1.0)aa 04 Message length (170 bytes)04 New Session Ticket message type (extension)00 00 a6 Message length (166 bytes)00 .. f0 Session Ticket dataChangeCipherSpec message0000 14 03 01 00 01 01 ......14 ChangeCipherSpec protocol type03 01 SSL version (TLS 1.0)00 01 Message length01 ChangeCipherSpec messageFinished message (encrypted)0000 16 03 01 00 30 6d 09 0e 9f dd 09 03 2f 84 65 f8 ....0m....../.e.0010 94 0f d6 7b 4b 54 31 a1 25 a4 27 03 ae c3 4e af ...{KT1.%.'...N.0020 27 04 32 5a 1f 29 90 fa 0a 4b 89 2f af d8 88 99 '.2Z.)...K./....0030 41 de dd 89 3f A...?16 Handshake protocol type03 01 SSL version (TLS 1.0)00 30 Message length (48 bytes)6d .. 3f Encrypted Finished message
应用数据(client <–> server)
此时，Client端和Server端已经完成握手，加密通信就位，应用数据可以安全传输了。以下是一个record实例，可以把几个record放在一个TCP数据包里。
ApplicationData message0000 17 03 01 00 30 5d 15 3d a2 40 ef d2 01 25 ca 54 ....0].=.@...%.T0010 26 5f 5d b0 d2 2f 2f 6d 2d ec 56 85 b0 4c a9 bf &_]..//m-.V..L..0020 eb 97 be 31 ad cd de 3a b4 71 1e c8 53 96 0b 2d ...1...:.q..S..-0030 c3 91 3d a2 15 ..=..17 ApplicationData protocol type03 01 SSL version (TLS 1.0)00 30 Message length (48 bytes)5d .. 15 Encrypted application data
关闭连接
由于我们已经处于加密链路中，想了解数据包的真实内容的话，唯一的方法是让Wireshark或类似工具知道传输过程中所使用这密钥。这是有可能的，但是，我认为从这个分析目的，知道Client端开Server端主动要求关闭连接时所发的alert消息就足够了。这个Alert 消息的类型应该是 CloseNotify (类型0)，但是我们不能从原始的裸数据中看到它。这个案例中，Client端是下面这条Alert消息的发报者：
Alert message0000 15 03 01 00 20 3e 2e 43 30 49 49 6a f6 37 69 eb .... >.C0IIj.7i.0010 0d dd c3 e2 d3 e1 5d e3 4e b3 e2 22 9d 85 f9 c4 ......].N.."....0020 59 b3 41 a9 86 Y.A..15 Alert protocol type03 01 SSL version (TLS 1.0)00 20 Message length (32 bytes)3e .. 86 Encrypted alert message
结束语
从流量分析可以看出，库和client 端实现正在按照 TLS 1.0规范的预期进行。我希望这对您了解 SSL/TLS 协议的内部工作有所帮助。我发现查看十六进制原始数据(特别是像 Wireshark 这样强大的工具)是一种非常有益和有趣的网络工作方式。
SSL/TLS会话的流量分析相关推荐
- TLS配置和流量分析实验
TLS配置和流量分析实验 1)理解 TLS 协议原理: 2)掌握 apache 服务器的 HTTPS 配置方法: 3)掌握 TLS 流量分析方法. https://download.csdn.net/ ...
- SSL/TLS协议交互流程分析
本文参考 SSL/TLS协议运行机制的概述 tls运行机制,这里不细说,建议细看 HTTPS与TLS The Transport Layer Security (TLS) Protocol v1.2 ...
- 使用openssl进行ssl/tls加密传输会话测试
[小蜗牛嘻哈之作] 我们首先看看下面一段"对话": [root@pps ~]# openssl s_client -connect localhost:110 -starttls ...
- python 发送邮件正文字体设置_python 文字 坐标python smtplib模块发送SSL/TLS安全邮件实例...
python的smtplib提供了一种很方便的途径发送电子邮件.它对smtp协议进行了简单的封装. smtp协议的基本命令包括: HELO 向服务器标识用户身份 MAIL 初始化邮件传输 mail f ...
- SSL/TLS、对称加密和非对称加密和TLSv1.3
本文主要对对称加密和非对称加密的原理以及过程进行分析,同时还会简单介绍一下TLS/SSL的一些相关内容,并且对比TLSv1.2和TLSv1.3的不同. 1.SSL和TLS的历史 其实早期的互联网协议基 ...
- 第四篇：网络安全，SSL/TLS加密技术
文章目录 一.前言 二.SSL/TLS 2.1 SSL/TLS是什么 2.2 SSL/TLS加密基本原理 2.3 SSL/TLS建立握手过程 三.CA & SSL Server & S ...
- SSL/TLS 协议简介与实例分析
作者:drinkey 以前读RFC时总结的一篇文章,主要介绍了SSL/TLS协议的相关知识,包括协议本身以及简单的密码学概念,以及用实例解析了HTTP over SSL的协商过程,在最后简要列出了SS ...
- SSL/TLS捕包分析
一.基本概念 SSL:(Secure Socket Layer,安全套接字层),位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层.SSL通过互相认证.使用数字签名确保完整性.使用加密确保私密 ...
- wireshark抓包分析SSL/TLS协议
SSL/TLS协议一般有两种握手过程,一种是SSL握手,一种是会话恢复.前些时候在写HTTP和HTTPS协议区别的时候介绍了SSL协议的相关理论知识,但多少还是有点抽象,今天我们可以通过wiresha ...
最新文章
- CES2018：英特尔披露量子计算和神经拟态计算研究最新进展
- python嵌套循环效率_Python嵌套循环数组比较优化的可能性？
- C++ 十字链表图转java版
- golang中的goredis
- connect 超时
- Linux常用运维命令笔记
- DIV+CSS列表式布局（同意图片的应用）
- svn复制出来的java_从svn下载的项目（或从别处拷贝来的）报错的可能情况以及解决经验...
- 腾讯微博虽然停运，但其仍是一款成功的产品
- vs该文件没有与之关联的应用来执行该操作_Hadoop大数据实战系列文章之Zookeeper...
- ECSHOP2.7.3删除后台左侧菜单中的云服务中心
- LFSR(线性反馈移位寄存器)
- matlab实现移位寄存器,Matlab移位寄存器的实现
- 51单片机学习笔记——串口通信
- linux开启cups服务,Linux中cups打印服务实战设置
- 电商用户行为分析-大数据
- 大学里青年教师待遇真的很低吗？
- 移动端设置overflow-x:hiden后scrollTop失效并一直为0
- excel2010免费下载与安装
- CSP-J/S初赛考点总结