SSL和TLS协议格式
转载：http://www.tuicool.com/articles/rQjEzy3
相关学习资料
http://www.360doc.com/content/10/0602/08/1466362_30787868.shtml
http://www.gxu.edu.cn/college/hxhgxy/sec/COURSE/ch13/1.htm
http://www.rfc-editor.org/rfc/rfc6101.txt
http://3600.1kapp.com/?p=546
http://wiki.mbalib.com/wiki/SSL%E4%BF%AE%E6%94%B9%E5%AF%86%E6%96%87%E5%8D%8F%E8%AE%AE
http://www.h3c.com.cn/Products___Technology/Technology/Security_Encrypt/Other_technology/Technology_book/200812/622834_30003_0.htm
http://technet.microsoft.com/zh-cn/library/cc785811(v=ws.10).aspx
http://www.rfc-editor.org/rfc/rfc2246.txt
目录
1. SSL协议格式
2. TLS协议格式
3. HTTPS、SSL/TLS初始化协商过程
1. SSL协议格式
SSL(Secure socket Layer 安全套接层协议)指使用公钥和私钥技术组合的安全网络通讯协议。SSL协议是网景公司(Netscape)推出的基于WEB应用的安全协议，SSL协议指定了一种在应用程序协议(如Http、Telenet、NMTP和FTP等)和TCP/IP协议之间提供数据安全性分层的机制，它为TCP/IP连接提供数据加密、服务器认证、消息完整性以及可选的客户机认证，主要用于提高应用程序之间数据的安全性，对传送的数据进行加密和隐藏，确保数据在传送中不被改变,即确保数据的完整性。
SSL 以对称密码技术和公开密码技术相结合，可以实现如下三个通信目标：
1. 秘密性: SSL客户机和服务器之间传送的数据都经过了加密处理,网络中的非法窃听者所获取的信息都将是无意义的密文信息
2. 完整性: SSL利用密码算法和散列(HASH)函数,通过对传输信息特征值的提取来保证信息的完整性,确保要传输的信息全部到达目的地,可以避免服务器和客户机之间的信息受到破坏。
3. 认证性:利用证书技术和可信的第三方认证，可以让客户机和服务器相互识别对方的身份。为了验证证书持有者是其合法用户(而不是冒名用户)，SSL要求证书持有者在握手时相互交换数字证
书，通过验证来保证对方身份的合法性。
SSL协议位于TCP/IP协议模型的网络层和应用层之间，使用TCP来提供一种可靠的端到端的安全服务，它是客户/服务器应用之间的通信不被攻击窃听，并且始终对服务器进行认证，还可以选择对客户进行认证。
SSL协议应用层来说是透明的，我们在编写基于SSL的HTTPS应用时，无论客户端还是服务端都不需要考虑SSL的存在
SSL协议在应用层通信之前就已经完成:
1) 加密算法 2) 通信密钥的协商 3) 服务器认证工作
在此之后,应用层协议所传送的数据都被加密。SSL实际上是共同工作的两层协议组成，如下图所示
对于这张SSL的层次结构图，我们需要牢记几点:
1. 不管是TCP/IP的4层协议、还是ISO的7层协议，它们都是基于接口式的松耦合层次结构的协议，也就是说，只要遵循接口的格式，中间可以插入任意的协议层，这也是SSL能存在的理论依据
2. 所谓的高层次、低层次，本质上是一种"数据封装"的概念，高层的数据封装进底层的数据包，然后加上某些数据包的头部，仅此而已
3. "SSL握手协议"、"SSL改变密码格式协议"、"SSL警告协议"、"HTTP.."我们都可以看成是"SSL记录协议"封装的上层应用层数据，它们都基于下层的"SSL记录协议"进行封装，从而实现自己
的功能。至于为什么会有这么多的上层协议，也很容易理解，因为SSL是一种加密目的的协议，这类密码学相关的协议在初始化(握手)的过程中普遍都需要一些列的交互过程，握手协议来支持
对总体的结构有了初步认识之后，我们接下来开始深入学习SSL的协议格式，在学习的过程中，我们应该时常回忆上面的这张整体结构图，理解它们的层次关系
0x1: SSL记录协议
我们知道，SSL记录协议是用来封装上层协议数据的协议，在SSL协议中，所有的传输数据都被封装在记录中。记录是由:
1) 记录头 2) 长度不为0的记录数据
组成的。”所有”的SSL通信都使用SSL记录层，记录协议封装上层的:
1) 握手协议 2) 警告协议 3) 改变密码格式协议 4) 应用数据协议
SSL记录协议定义了要传输数据的格式，它位于一些可靠的的传输协议之上(如TCP)，用于各种更高层协议的封装，记录协议主要完成:
1) 分组、组合 2) 压缩、解压缩 3) 以及消息认证 4) 加密传输等
1. 分段
每个上层应用数据被分成2^14字节或更小的数据块
2. 压缩
压缩是可选的，并且是无损压缩，压缩后内容长度的增加不能超过1024字节。
3. 在压缩数据上计算消息认证MAC。
4. 对压缩数据及MAC进行加密。
5. 增加SSL记录头(内容类型、主版本、次版本、压缩长度)
最终经过封装后的SSL记录数据包格式如下
-
1. 内容类型(8位):
-
封装的高层协议
-
1) 握手协议(
handshake): 22
-
2) 警告协议(
alert): 21
-
3) 改变密码格式协议(
change_cipher_spec): 20
-
4) 应用数据协议(
application_data): 23
-
2. 主要版本(8位):
-
使用的
SSL主要版本，目前的
SSL版本是
SSL
v3，所以这个字段的值只有3这个值
-
3. 次要版本(8位):
-
使用的
SSL次要版本。对于
SSL
v3
.0，值为0。
-
4. 数据包长度(16位):
-
1) 明文数据包:
-
这个字段表示的是明文数据以字节为单位的长度
-
2) 压缩数据包
-
这个字段表示的是压缩数据以字节为单位的长度
-
3) 加密数据包
-
这个字段表示的是加密数据以字节为单位的长度
-
5. 记录数据
-
这个区块封装了上层协议的数据
-
1) 明文数据包:
-
opaque
fragment
[SSLPlaintext.length];
-
2) 压缩数据包
-
opaque
fragment
[SSLCompressed.length];
-
3) 加密数据包
-
3
.1) 流式(
stream)加密:
GenericStreamCipher
-
3
.1
.1)
opaque
content
[SSLCompressed.length];
-
3
.1
.2)
opaque
MAC
[CipherSpec.hash_size];
-
3
.2) 分组(
block)加密:
GenericBlockCipher
-
3
.2
.1)
opaque
content
[SSLCompressed.length];
-
3
.2
.2)
opaque
MAC
[CipherSpec.hash_size];
-
3
.2
.3)
uint8
padding
[GenericBlockCipher.padding_length];
-
3
.2
.4)
uint8
padding_length;
-
6.
MAC(0、16、20位)
0x2: SSL握手协议
握手协议是客户机和服务器用SSL连接通信时使用的”第一个”子协议，握手协议包括客户机与服务器之间的一系列消息。SSL握手协议被封装在记录协议中，该协议允许服务器与客户机在应用程序传输和接收数据之前互相认证、协商加密算法和密钥。在初次建立SSL连接时，服务器与客户机交换一系列消息。
这些消息交换能够实现如下操作：
1. 客户机认证服务器
2. 协商客户机与服务器选择双方都支持的密码算法
3. 可选择的服务器认证客户
4. 使用公钥加密技术生成共享密钥
5. 建立加密SSL连接
SSL握手协议报文格式如下
1. 类型(Type)(1字节):
该字段指明使用的SSL握手协议报文类型
1) hello_request:
2) client_hello:
3) server_hello:
4) certificate:
5) server_key_exchange:
6) certificate_request:
7) server_done:
8) certificate_verify:
9) client_key_exchange:
10) finished:
2. 长度(Length)(3字节):
以字节为单位的报文长度。
3. 内容(Content)(≥1字节):
对应报文类型的的实际内容、参数
1) hello_request: 空
2) client_hello:
2.1) 版本(ProtocolVersion)
代表客户端可以支持的SSL最高版本号
2.1.1) 主版本: 3
2.1.2) 次版本: 0
2.2) 随机数(Random)
客户端产生的一个用于生成主密钥(master key)的32字节的随机数(主密钥由客户端和服务端的随机数共同生成)
2.2.1) uint32 gmt_unix_time;
2.2.2) opaque random_bytes[28];
4+28=32字节
2.3) 会话ID: opaque SessionID<0..32>;
2.4) 密文族(加密套件):
一个客户端可以支持的密码套件列表。这个列表会根据使用优先顺序排列，每个密码套件都指定了"密钥交换算法(Deffie-Hellman密钥交换算法、基于RSA的密钥交换和另一种实
现在Fortezza chip上的密钥交换)"、"加密算法(DES、RC4、RC2、3DES等)"、"认证算法(MD5或SHA-1)"、"加密方式(流、分组)"
2.4.1) CipherSuite SSL_RSA_WITH_NULL_MD5
2.4.2) CipherSuite SSL_RSA_WITH_NULL_SHA
2.4.3) CipherSuite SSL_RSA_EXPORT_WITH_RC4_40_MD5
2.4.4) CipherSuite SSL_RSA_WITH_RC4_128_MD5
2.4.5) CipherSuite SSL_RSA_WITH_RC4_128_SHA
2.4.6) CipherSuite SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
2.4.7) CipherSuite SSL_RSA_WITH_IDEA_CBC_SHA
2.4.8) CipherSuite SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
2.4.9) CipherSuite SSL_RSA_WITH_DES_CBC_SHA
2.4.10) CipherSuite SSL_RSA_WITH_3DES_EDE_CBC_SHA
2.4.11) CipherSuite SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
2.4.12) CipherSuite SSL_DH_DSS_WITH_DES_CBC_SHA
2.4.13) CipherSuite SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA
2.4.14) CipherSuite SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
2.4.15) CipherSuite SSL_DH_RSA_WITH_DES_CBC_SHA
2.4.16) CipherSuite SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA
2.4.17) CipherSuite SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
2.4.18) CipherSuite SSL_DHE_DSS_WITH_DES_CBC_SHA
2.4.19) CipherSuite SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
2.4.20) CipherSuite SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
2.4.21) CipherSuite SSL_DHE_RSA_WITH_DES_CBC_SHA
2.4.22) CipherSuite SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
2.4.23) CipherSuite SSL_DH_anon_EXPORT_WITH_RC4_40_MD5
2.4.24) CipherSuite SSL_DH_anon_WITH_RC4_128_MD5
2.4.25) CipherSuite SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
2.4.26) CipherSuite SSL_DH_anon_WITH_DES_CBC_SHA
2.4.27) CipherSuite SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
2.4.28) CipherSuite SSL_FORTEZZA_KEA_WITH_NULL_SHA
2.4.29) CipherSuite SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA
2.4.30) CipherSuite SSL_FORTEZZA_KEA_WITH_RC4_128_SHA
2.5) 压缩方法
3) server_hello:
3.1) 版本(ProtocolVersion)
代表服务端"采纳"的最高支持的SSL版本号
3.1.1) 主版本: 3
3.1.2) 次版本: 0
3.2) 随机数(Random)
服务端产生的一个用于生成主密钥(master key)的32字节的随机数(主密钥由客户端和服务端的随机数共同生成)
3.2.1) uint32 gmt_unix_time;
3.2.2) opaque random_bytes[28];
4+28=32字节
3.3) 会话ID: opaque SessionID<0..32>;
3.4) 密文族(加密套件):
代表服务端采纳的用于本次通讯的的加密套件
3.5) 压缩方法:
代表服务端采纳的用于本次通讯的的压缩方法
总体来看，server_hello就是服务端对客户端的的回应，表示采纳某个方案
4) certificate:
SSL服务器将自己的"服务端公钥证书(注意，是公钥整数)"发送给SSL客户端
ASN.1Cert certificate_list<1..2^24-1>;
5) server_key_exchange:
1) RSA
执行RSA密钥协商过程
1.1) RSA参数(ServerRSAParams)
1.1.1) opaque RSA_modulus<1..2^16-1>;
1.1.2) opaque RSA_exponent<1..2^16-1>;
1.2) 签名参数(Signature)
1.2.1) anonymous: null
1.2.2) rsa
1.2.2.1) opaque md5_hash[16];
1.2.2.2) opaque sha_hash[20];
1.2.3) dsa
1.2.3.1) opaque sha_hash[20];
2) diffie_hellman
执行DH密钥协商过程
2.1) DH参数(ServerDHParams)
2.1.1) opaque DH_p<1..2^16-1>;
2.1.2) opaque DH_g<1..2^16-1>;
2.1.3) opaque DH_Ys<1..2^16-1>;
2.2) 签名参数(Signature)
2.2.1) anonymous: null
2.2.2) rsa
2.2.2.1) opaque md5_hash[16];
2.2.2.2) opaque sha_hash[20];
2.2.3) dsa
2.2.3.1) opaque sha_hash[20];
3) fortezza_kea
执行fortezza_kea密钥协商过程
3.1) opaque r_s [128]
6) certificate_request:
6.1) 证书类型(CertificateType)
6.1.1) RSA_sign
6.1.2) DSS_sign
6.1.3) RSA_fixed_DH
6.1.4) DSS_fixed_DH
6.1.5) RSA_ephemeral_DH
6.1.6) DSS_ephemeral_DH
6.1.7) FORTEZZA_MISSI
6.2) 唯一名称(DistinguishedName)
certificate_authorities<3..2^16-1>;
7) server_done:
服务器总是发送server_hello_done报文，指示服务器的hello阶段结束
struct { } ServerHelloDone;
8) certificate_verify:
签名参数(Signature)
8.1) anonymous: null
8.2) rsa
8.2.1) opaque md5_hash[16];
8.2.2) opaque sha_hash[20];
8.3) dsa
8.3.1) opaque sha_hash[20];
9) client_key_exchange:
9.1) RSA
9.1.1) PreMasterSecret
9.1.1.1) ProtocolVersion
9.1.1.2) opaque random[46];
9.2) diffie_hellman: opaque DH_Yc<1..2^16-1>;
9.3) fortezza_kea
9.3.1) opaque y_c<0..128>;
9.3.2) opaque r_c[128];
9.3.3) opaque y_signature[40];
9.3.4) opaque wrapped_client_write_key[12];
9.3.5) opaque wrapped_server_write_key[12];
9.3.6) opaque client_write_iv[24];
9.3.7) opaque server_write_iv[24];
9.3.8) opaque master_secret_iv[24];
9.3.9) opaque encrypted_preMasterSecret[48];
10) finished:
10.1) opaque md5_hash[16];
10.2) opaque sha_hash[20];
0x3: SSL改变密码协议
SSL修改密文协议的报文由值为1的单一字节组成，只有一个”1”值
SSL修改密文协议的设计目的是为了保障SSL传输过程的安全性，因为SSL协议要求客户端或服务器端每隔一段时间必须改变其加解密参数。当某一方要改变其加解密参数时，就发送一个简单的消息通知对方下一个要传送的数据将采用新的加解密参数，也就是要求对方改变原来的安全参数。
0x4: SSL警告协议
SSL警告协议亦称SSL告警协议、SSL报警协议，是用来为对等实体传递SSL的相关警告。如果在通信过程中某一方发现任何异常，就需要给对方发送一条警示消息通告。
SSL报警协议报文由严重级别和警告代码两部分组成
1. 严重级别(AlertLevel )
1) Fatal
Fatal级报警即致命级报警，它要求通信双方都要采取紧急措施，并终止会话，同时消除自己缓冲区相应的会话记录
2) Waming
Warning级报警即警告级报警的处理，通常是通信双方都只进行日志记录，它对通信过程不造成影响
2. 警告代码
1) bad_record_mac：收到了不正确的MAC
2) unexpected_message：接收了不合适的报文
3) decompression_failure：解压缩函数收到不适当的输入。
4) illegal_parameter：握手报文中的一个字段超出范围或与其他字段不兼容。
5) certificate_revoked：证书已经被废弃。
6) bad_certificate：收到的证书是错误的。
7) certificate_expired：证书已经过期。
8) handshake_failer：握手过程失败。
9) no_certificate: 未提供证书
10) unsupported_certificate: 未支持的证书格式
11) certificate_unknown: 未知证书
2. TLS协议格式
TLS并不是一个新协议，它是SSL(准确的说是SSL v3)的强化版，在整个协议格式上，和SSL类似
http://www.rfc-editor.org/rfc/rfc2246.txt
1．TLS与SSL的差异
-
1. 版本号：
TLS记录格式与
SSL记录格式相同，但版本号的值不同，
TLS的版本1
.0使用的版本号为
SSLv3
.1。
-
2. 报文鉴别码：
SSLv3
.0和
TLS的
MAC算法及
MAC计算的范围不同。
TLS使用了
RFC-2104定义的
HMAC算法。
SSLv3
.0使用了相似的算法，两者差别在于
SSLv3
.0中，填充字节与密钥之间采用的是
-
连接运算，而
HMAC算法采用的是异或运算。但是两者的安全程度是相同的。
-
3. 伪随机函数：
TLS使用了称为
PRF的伪随机函数来将密钥扩展成数据块，是更安全的方式。
-
4. 报警代码：
TLS支持几乎所有的
SSLv3
.0报警代码，而且
TLS还补充定义了很多报警代码，如
-
1) 解密失败(
decryption_failed)
-
2) 记录溢出(
record_overflow)
-
3) 未知
CA(
unknown_ca)
-
4) 拒绝访问(
access_denied)等。
-
5. 密文族和客户证书：
SSLv3
.0和
TLS存在少量差别，即
TLS"不支持":
-
1)
Fortezza密钥交换
-
2) 加密算法
-
3) 客户证书。
-
6.
certificate_verify和
finished消息：
SSLv3
.0和
TLS在用
certificate_verify和
finished消息计算
MD5和
SHA-1散列码时，计算的输入有少许差别，但安全性相当。
-
7. 加密计算：
TLS与
SSLv3
.0在计算主密值(
master
secret)时采用的方式不同。但都是以客户端和服务端各自产生的随机数
Ramdom作为输入
-
8. 填充：用户数据加密之前需要增加的填充字节。在
SSL中，填充后的数据长度要达到密文块长度的最小整数倍。而在
TLS中，填充后的数据长度可以是密文块长度的任意整数倍
-
(但填充的最大长度为255字节)，这种方式可以防止基于对报文长度进行分析的攻击。
2．TLS的主要增强内容
TLS的主要目标是使SSL更安全，并使协议的规范更精确和完善。TLS 在SSL v3.0 的基础上，提供了以下增强内容：
1. 更安全的MAC算法
2. 更严密的警报
3. "灰色区域"规范的更明确的定义
3．TLS对于安全性的改进
1. 对于消息认证使用密钥散列法：TLS 使用"消息认证代码的密钥散列法"(HMAC)，当记录在开放的网络(如因特网)上传送时，该代码确保记录不会被变更。SSLv3.0还提供键控消息认证，但
HMAC比SSLv3.0使用的(消息认证代码)MAC 功能更安全。
2. 增强的伪随机功能(PRF)：PRF生成密钥数据。在TLS中，HMAC定义PRF。PRF使用两种散列算法保证其安全性。如果任一算法暴露了，只要第二种算法未暴露，则数据仍然是安全的。
3. 改进的已完成消息验证：TLS和SSLv3.0都对两个端点提供已完成的消息，该消息认证交换的消息没有被变更。然而，TLS将此已完成消息基于PRF和HMAC值之上，这也比SSLv3.0更安全。
4. 一致证书处理：与SSLv3.0不同，TLS试图指定必须在TLS之间实现交换的证书类型。
5. 特定警报消息：TLS提供更多的特定和附加警报，以指示任一会话端点检测到的问题。TLS还对何时应该发送某些警报进行记录。
3. HTTPS、SSL/TLS初始化协商过程
SSL通过握手过程在客户端和服务器之间协商会话参数，并建立会话。会话包含的主要参数有会话ID、对方的证书、加密套件（密钥交换算法、数据加密算法和MAC算法等）以及主密钥（master secret）。通过SSL会话传输的数据，都将采用该会话的主密钥和加密套件进行加密、计算MAC等处理。
不同情况下，SSL握手过程存在差异。下面将分别描述以下三种情况下的握手过程：
1. 只验证服务器的SSL握手过程
2. 验证服务器和客户端的SSL握手过程
3. 恢复原有会话的SSL握手过程
1. 只验证服务器的SSL握手过程
-
1. Client Hello
-
SSL客户端通过Client Hello消息向SSL服务端发送:
-
1) 支持的SSL版本
-
2) 客户端生成的一个用于生成主密钥(master key)的32字节的随机数(主密钥由客户端和服务端的随机数共同生成)
-
3) 会话ID
-
3) 加密套件
-
3.1) 加密算法
-
3.2) 密钥交换算法
-
3.3) MAC算法
-
3.4) 加密方式(流、分组)
-
4) 压缩算法(如果支持压缩的话)
-
2. Server Hello
-
SSL服务器确定本次通信采用的SSL版本和加密套件，并通过Server Hello消息通知给SSL客户端。如果SSL服务器允许SSL客户端在以后的通信中重用本次会话，则SSL服务器会为本次会话分配会
-
话ID，并通过Server Hello消息发送给SSL客户端。
-
1) 服务端采纳的本次通讯的SSL版本
-
2) 服务端生成的一个用于生成主密钥(master key)的32字节的随机数(主密钥由客户端和服务端的随机数共同生成)
-
3) 会话ID
-
3) 服务端采纳的用于本次通讯的加密套件(从客户端发送的加密套件列表中选出了一个)
-
3.1) 加密算法
-
3.2) 密钥交换算法
-
3.3) MAC算法
-
3.4) 加密方式(流、分组)
-
4) 压缩算法(如果支持压缩的话)
-
3. Certificate
-
SSL服务器将"携带自己公钥信息的数字证书"和到根CA整个链发给客户端通过Certificate消息发送给SSL客户端(整个公钥文件都发送过去)，客户端使用这个公钥完成以下任务:
-
1) 客户端可以使用该公钥来验证服务端的身份，因为只有服务端有对应的私钥能解密它的公钥加密的数据
-
2) 用于对"premaster secret"进行加密，这个"premaster secret"就是用客户端和服务端生成的Ramdom随机数来生成的，客户端用服务端的公钥对其进行了加密后发送给服务端
-
4. Server Key Exchange
-
密钥交换阶段(可选步骤)，之所以说是可选步骤，是因为只有在下列场景下这个步骤才会发生
-
1) 协商采用了RSA加密，但是服务端的证书没有提供RSA公钥
-
2) 协商采用了DH加密，但是服务端的证书没有提供DH参数
-
3) 协商采用了fortezza_kea加密，但是服务端的证书没有提供参数
-
总结来说，"Server Key Exchange"这个步骤是对上一步"Certificate"的一个补充，为了让整个SSL握手过程能正常进行
-
5. Server Hello Done
-
SSL服务器发送Server Hello Done消息，通知SSL客户端版本和加密套件协商结束
-
6. Client Key Exchange
-
SSL客户端验证SSL服务器的证书合法后，利用证书中的公钥加密SSL客户端随机生成的"premaster secret"(通过之前客户端、服务端分别生成的随机数生成的)，并通过
-
Client Key Exchange消息发送给SSL服务器。
-
注意，这一步完成后，客户端和服务端都已经保存了"主密钥"(之所以这里叫预备主密钥，是因为还没有投入使用)。这个"主密钥"会用于之后的SSL通信数据的加密
-
7.
Change Cipher Spec
-
SSL客户端发送
Change Cipher Spec消息，通知SSL服务器后续报文将采用协商好的
"主密钥"和加密套件进行加密和MAC计算。
-
8. Finished
-
SSL客户端计算已交互的握手消息(除
Change Cipher Spec消息外所有已交互的消息)的
Hash值，利用协商好的密钥和加密套件处理
Hash值(计算并添加MAC值、加密等)，并通过Finished消息
-
发送给SSL服务器。SSL服务器利用同样的方法计算已交互的握手消息的
Hash值，并与Finished消息的解密结果比较，如果二者相同，且MAC值验证成功，则证明密钥和加密套件协商成功。
-
9.
Change Cipher Spec
-
同样地，SSL服务器发送
Change Cipher Spec消息，通知SSL客户端后续报文将采用协商好的密钥和加密套件进行加密和MAC计算。
-
10. Finished
-
SSL服务器计算已交互的握手消息的
Hash值，利用协商好的密钥和加密套件处理
Hash值(计算并添加MAC值、加密等)，并通过Finished消息发送给SSL客户端。SSL客户端利用同样的方法计算已
-
交互的握手消息的
Hash值，并与Finished消息的解密结果比较，如果二者相同，且MAC值验证成功，则证明密钥和加密套件协商成功。
-
SSL客户端接收到SSL服务器发送的Finished消息后，如果解密成功，则可以判断SSL服务器是数字证书的拥有者，即SSL服务器身份验证成功，因为只有拥有私钥的SSL服务器才能从
-
Client
Key
Exchange消息中解密得到premaster secret，从而间接地实现了SSL客户端对SSL服务器的身份验证。
2. 验证服务器和客户端的SSL握手过程
“验证服务器和客户端的SSL握手过程”和”只验证服务器的SSL握手过程”整体过程类似，只是多了服务端向客户端要求发送证明客户端身份的证书、以及客户端发送证书的过程
-
1. Client Hello
-
SSL客户端通过Client Hello消息向SSL服务端发送:
-
1) 支持的SSL版本
-
2) 客户端生成的一个用于生成主密钥(master
key)的
32字节的随机数(主密钥由客户端和服务端的随机数共同生成)
-
3) 会话ID
-
3) 加密套件
-
3.1) 加密算法
-
3.2) 密钥交换算法
-
3.3) MAC算法
-
3.4) 加密方式(流、分组)
-
4) 压缩算法(如果支持压缩的话)
-
2.
Server Hello
-
SSL服务器确定本次通信采用的SSL版本和加密套件，并通过
Server Hello消息通知给SSL客户端。如果SSL服务器允许SSL客户端在以后的通信中重用本次会话，则SSL服务器会为本次会话分配
-
会话ID，并通过
Server Hello消息发送给SSL客户端。
-
1) 服务端采纳的本次通讯的SSL版本
-
2) 服务端生成的一个用于生成主密钥(master
key)的
32字节的随机数(主密钥由客户端和服务端的随机数共同生成)
-
3) 会话ID
-
3) 服务端采纳的用于本次通讯的加密套件(从客户端发送的加密套件列表中选出了一个)
-
3.1) 加密算法
-
3.2) 密钥交换算法
-
3.3) MAC算法
-
3.4) 加密方式(流、分组)
-
4) 压缩算法(如果支持压缩的话)
-
3. Certificate
-
SSL服务器将
"携带自己公钥信息的数字证书"和到根CA整个链发给客户端通过Certificate消息发送给SSL客户端(整个公钥文件都发送过去)，客户端使用这个公钥完成以下任务:
-
1) 客户端可以使用该公钥来验证服务端的身份，因为只有服务端有对应的私钥能解密它的公钥加密的数据
-
2) 用于对
"premaster secret"进行加密，这个
"premaster secret"就是用客户端和服务端生成的Ramdom随机数来生成的，客户端用服务端的公钥对其进行了加密后发送给服务端
-
4.
Server
Key Exchange
-
密钥交换阶段(可选步骤)，之所以说是可选步骤，是因为只有在下列场景下这个步骤才会发生
-
1) 协商采用了RSA加密，但是服务端的证书没有提供RSA公钥
-
2) 协商采用了DH加密，但是服务端的证书没有提供DH参数
-
3) 协商采用了fortezza_kea加密，但是服务端的证书没有提供参数
-
总结来说，
"Server Key Exchange"这个步骤是对上一步
"Certificate"的一个补充，为了让整个SSL握手过程能正常进行
-
5. Client Certificate
Request
-
服务器可以向客户发送certificate_request请求证书，即服务端需要客户端证明自己的身份
-
6.
Server Hello Done
-
SSL服务器发送
Server Hello Done消息，通知SSL客户端版本和加密套件协商结束
-
7. Client Certificate
-
客户端(浏览器)向服务器发送自己的客户端证书，以证明自己的身份
-
8. Client
Key Exchange
-
SSL客户端验证SSL服务器的证书合法后，利用证书中的公钥加密SSL客户端随机生成的
"premaster secret"(通过之前客户端、服务端分别生成的随机数生成的)，并通过
-
Client
Key Exchange消息发送给SSL服务器。
-
注意，这一步完成后，客户端和服务端都已经保存了
"主密钥"(之所以这里叫预备主密钥，是因为还没有投入使用)。这个
"主密钥"会用于之后的SSL通信数据的加密
-
9. Certificate Verify
-
客户可能发送client_verify报文来校验客户端发送的证书
-
10. Change Cipher Spec
-
SSL客户端发送Change Cipher Spec消息，通知SSL服务器后续报文将采用协商好的
"主密钥"和加密套件进行加密和MAC计算。
-
11. Finished
-
SSL客户端计算已交互的握手消息(除Change Cipher Spec消息外所有已交互的消息)的Hash值，利用协商好的密钥和加密套件处理Hash值(计算并添加MAC值、加密等)，并通过Finished
-
消息发送给SSL服务器。SSL服务器利用同样的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比较，如果二者相同，且MAC值验证成功，则证明密钥和加密套件协商成功。
-
12. Change Cipher Spec
-
同样地，SSL服务器发送Change Cipher Spec消息，通知SSL客户端后续报文将采用协商好的密钥和加密套件进行加密和MAC计算。
-
13. Finished
-
SSL服务器计算已交互的握手消息的Hash值，利用协商好的密钥和加密套件处理Hash值(计算并添加MAC值、加密等)，并通过Finished消息发送给SSL客户端。SSL客户端利用同样的方法计算已
-
交互的握手消息的Hash值，并与Finished消息的解密结果比较，如果二者相同，且MAC值验证成功，则证明密钥和加密套件协商成功。
-
SSL客户端接收到SSL服务器发送的Finished消息后，如果解密成功，则可以判断SSL服务器是数字证书的拥有者，即SSL服务器身份验证成功，因为只有拥有私钥的SSL服务器才能从
-
Client
Key Exchange消息中解密得到premaster secret，从而间接地实现了SSL客户端对SSL服务器的身份验证。
3. 只验证服务端的TLS握手过程
SSL握手阶段1: Clien Hello
SSL握手阶段2: Server Hello、Certificate、Server Key Exchange、Server Hello Done
可以看到，正如我们在学习协议格式的时候看到的，SSL/TLS的高层协议数据都被封装在了下层的”记录协议数据包”中，统一封装发送给客户端
Server Hello
重点注意几点，服务端生成了一个和客户端不同的随机数，同时，服务端在客户端提供的加密套件列表中选择了一个加密套件
Certificate
服务端将根证书全部发送给了客户端
Server Key Exchange
服务端向客户端发送了DH过程所需要的参数(因为这个参数证书中没有提供，所以需要”Server Key Exchange”来发送)
Server Hello Done
服务端发送”Server Hello Done”消息，标志着握手阶段2结束
SSL握手阶段3: Client Key Exchange、Change Cipher Spec
Client Key Exchange
客户端和服务端共同完成DH过程(上以阶段中Serer Key Exchange已经发送了DH的一半参数)
Change Cipher Spec
客户端发送”Change Cipher Spec”(密钥改变协议)通知服务端密钥已经协商好了，以后咱们都用这个密钥进行通信数据的加密吧
使用HTTS加密通道发送WEB数据
此时，所有的HTTPS通信数据都是处于加密状态了，即使中间人在网络中嗅探，也无法简单地获取明文
Copyright (c) 2014 LittleHann All rights reserved