相关学习资料php
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
目录css
1. SSL协议格式 2. TLS协议格式 3. HTTPS、SSL/TLS初始化协商过程 4. RDP SSL通讯过程
1. SSL协议格式html
SSL(Secure socket Layer 安全套接层协议)指使用公钥和私钥技术组合的安全网络通信协议。SSL协议是网景公司(Netscape)推出的基于WEB应用的安全协议，SSL协议指定了一种在应用程序协议(如Http、Telenet、NMTP和FTP等)和TCP/IP协议之间提供数据安全性分层的机制，它为TCP/IP链接提供数据加密、服务器认证、消息完整性以及可选的客户机认证，主要用于提升应用程序之间数据的安全性，对传送的数据进行加密和隐藏，确保数据在传送中不被改变,即确保数据的完整性。
SSL 以对称密码技术和公开密码技术相结合，能够实现以下三个通讯目标：vue
1. 秘密性: SSL客户机和服务器之间传送的数据都通过了加密处理,网络中的非法窃听者所获取的信息都将是无心义的密文信息 2. 完整性: SSL利用密码算法和散列(HASH)函数,经过对传输信息特征值的提取来保证信息的完整性,确保要传输的信息所有到达目的地,能够避免服务器和客户机之间的信息受到破坏。 3. 认证性:利用证书技术和可信的第三方认证，可让客户机和服务器相互识别对方的身份。为了验证证书持有者是其合法用户(而不是冒名用户)，SSL要求证书持有者在握手时相互交换数字证
书，经过验证来保证对方身份的合法性。
SSL协议位于TCP/IP协议模型的网络层和应用层之间，使用TCP来提供一种可靠的端到端的安全服务，它是客户/服务器应用之间的通讯不被攻击窃听，而且始终对服务器进行认证，还能够选择对客户进行认证。
SSL协议应用层来讲是透明的，咱们在编写基于SSL的HTTPS应用时，不管客户端仍是服务端都不须要考虑SSL的存在
SSL协议在应用层通讯以前就已经完成:ios
1) 加密算法 2) 通讯密钥的协商 3) 服务器认证工做
在此以后,应用层协议所传送的数据都被加密。SSL其实是共同工做的两层协议组成，以下图所示c++
对于这张SSL的层次结构图，咱们须要牢记几点:git
1. 无论是TCP/IP的4层协议、仍是ISO的7层协议，它们都是基于接口式的松耦合层次结构的协议，也就是说，只要遵循接口的格式，中间能够插入任意的协议层，这也是SSL能存在的理论依据 2. 所谓的高层次、低层次，本质上是一种"数据封装"的概念，高层的数据封装进底层的数据包，而后加上某些数据包的头部，仅此而已 3. "SSL握手协议"、"SSL改变密码格式协议"、"SSL警告协议"、"HTTP.."咱们均可以当作是"SSL记录协议"封装的上层应用层数据，它们都基于下层的"SSL记录协议"进行封装，从而实现本身
的功能。至于为何会有这么多的上层协议，也很容易理解，由于SSL是一种加密目的的协议，这类密码学相关的协议在初始化(握手)的过程当中广泛都须要一些列的交互过程，握手协议来支持
对整体的结构有了初步认识以后，咱们接下来开始深刻学习SSL的协议格式，在学习的过程当中，咱们应该时常回忆上面的这张总体结构图，理解它们的层次关系es6
0x1: SSL记录协议web
咱们知道，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、1六、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、RC四、RC二、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通讯数据都是处于加密状态了，即便中间人在网络中嗅探，也没法简单地获取明文