devbox
知新_RL
这个屌丝很懒，什么也没留下！
关注作者
热门标签
热门文章
当前位置:   article > 正文

SSL、TLS协议格式、HTTPS通信过程、RDP SSL通信过程

作者：知新_RL | 2024-05-12 22:33:55

赞

踩

rdp ssl

目录

1. SSL协议格式

2. TLS协议格式

3. HTTPS、SSL/TLS初始化协商过程

4. RDP SSL通信过程

 

1. SSL协议格式

        SSL(Secure socket Layer 安全套接层协议)指使用公钥和私钥技术组合的安全网络通讯协议。SSL协议是网景公司(Netscape)推出的基于WEB应用的安全协议，SSL协议指定了一种在应用程序协议(如Http、Telenet、NMTP和FTP等)和TCP/IP协议之间提供数据安全性分层的机制，它为TCP/IP连接提供数据加密、服务器认证、消息完整性以及可选的客户机认证，主要用于提高应用程序之间数据的安全性，对传送的数据进行加密和隐藏，确保数据在传送中不被改变,即确保数据的完整性。
SSL 以对称密码技术和公开密码技术相结合，可以实现如下三个通信目标：

  1. 1. 秘密性: SSL客户机和服务器之间传送的数据都经过了加密处理,网络中的非法窃听者所获取的信息都将是无意义的密文信息
  2. 2. 完整性: SSL利用密码算法和散列(HASH)函数,通过对传输信息特征值的提取来保证信息的完整性,确保要传输的信息全部到达目的地,可以避免服务器和客户机之间的信息受到破坏。
  3. 3. 认证性:利用证书技术和可信的第三方认证，可以让客户机和服务器相互识别对方的身份。为了验证证书持有者是其合法用户(而不是冒名用户)，SSL要求证书持有者在握手时相互交换数字证
  4. 书，通过验证来保证对方身份的合法性。

        SSL协议位于TCP/IP协议模型的网络层和应用层之间，使用TCP来提供一种可靠的端到端的安全服务，它是客户/服务器应用之间的通信不被攻击窃听，并且始终对服务器进行认证，还可以选择对客户进行认证。
        SSL协议应用层来说是透明的，我们在编写基于SSL的HTTPS应用时，无论客户端还是服务端都不需要考虑SSL的存在SSL协议在应用层通信之前就已经完成:

  1. 1) 加密算法
  2. 2) 通信密钥的协商
  3. 3) 服务器认证工作

        在此之后,应用层协议所传送的数据都被加密。SSL实际上是共同工作的两层协议组成，如下图所示

        对于这张SSL的层次结构图，我们需要牢记几点:

  1. 1. 不管是TCP/IP的4层协议、还是ISO的7层协议，它们都是基于接口式的松耦合层次结构的协议，也就是说，只要遵循接口的格式，中间可以插入任意的协议层，这也是SSL能存在的理论依据
  2. 2. 所谓的高层次、低层次，本质上是一种"数据封装"的概念，高层的数据封装进底层的数据包，然后加上某些数据包的头部，仅此而已
  3. 3. "SSL握手协议"、"SSL改变密码格式协议"、"SSL警告协议"、"HTTP.."我们都可以看成是"SSL记录协议"封装的上层应用层数据，它们都基于下层的"SSL记录协议"进行封装，从而实现自己的功能。至于为什么会有这么多的上层协议，也很容易理解，因为SSL是一种加密目的的协议，这类密码学相关的协议在初始化(握手)的过程中普遍都需要一些列的交互过程，握手协议来支持

        对总体的结构有了初步认识之后，我们接下来开始深入学习SSL的协议格式，在学习的过程中，我们应该时常回忆上面的这张整体结构图，理解它们的层次关系

1.1: SSL记录协议

        我们知道，SSL记录协议是用来封装上层协议数据的协议，在SSL协议中，所有的传输数据都被封装在记录中。记录是由:

  1. 1) 记录头
  2. 2) 长度不为0的记录数据

组成的。"所有"的SSL通信都使用SSL记录层，记录协议封装上层的:

  1. 1) 握手协议
  2. 2) 警告协议
  3. 3) 改变密码格式协议
  4. 4) 应用数据协议

        SSL记录协议定义了要传输数据的格式，它位于一些可靠的的传输协议之上(如TCP)，用于各种更高层协议的封装，记录协议主要完成:

  1. 1) 分组、组合
  2. 2) 压缩、解压缩
  3. 3) 以及消息认证
  4. 4) 加密传输等

 

 

  1. 1. 分段
  2.         每个上层应用数据被分成2^14字节或更小的数据块 
  3. 2. 压缩
  4.         压缩是可选的，并且是无损压缩，压缩后内容长度的增加不能超过1024字节。
  5. 3. 在压缩数据上计算消息认证MAC。
  6. 4. 对压缩数据及MAC进行加密。
  7. 5. 增加SSL记录头(内容类型、主版本、次版本、压缩长度)

        最终经过封装后的SSL记录数据包格式如下

 

  1. 1. 内容类型(8位):
  2. 封装的高层协议
  3.     1) 握手协议(handshake): 22
  4.     2) 警告协议(alert): 21
  5.     3) 改变密码格式协议(change_cipher_spec): 20
  6.     4) 应用数据协议(application_data): 23
  7. 2. 主要版本(8位):
  8. 使用的SSL主要版本，目前的SSL版本是SSL v3，所以这个字段的值只有3这个值
  9. 3. 次要版本(8位):
  10. 使用的SSL次要版本。对于SSL v3.0，值为0。
  11. 4. 数据包长度(16位):
  12.     1) 明文数据包: 
  13.     这个字段表示的是明文数据以字节为单位的长度
  14.     2) 压缩数据包
  15.     这个字段表示的是压缩数据以字节为单位的长度 
  16.     3) 加密数据包
  17.     这个字段表示的是加密数据以字节为单位的长度 
  18. 5. 记录数据 
  19. 这个区块封装了上层协议的数据
  20.     1) 明文数据包: 
  21.     opaque fragment[SSLPlaintext.length];
  22.     2) 压缩数据包
  23.     opaque fragment[SSLCompressed.length];
  24.     3) 加密数据包
  25.         3.1) 流式(stream)加密: GenericStreamCipher
  26.             3.1.1) opaque content[SSLCompressed.length];
  27.             3.1.2) opaque MAC[CipherSpec.hash_size];
  28.         3.2) 分组(block)加密: GenericBlockCipher
  29.             3.2.1) opaque content[SSLCompressed.length];
  30.             3.2.2) opaque MAC[CipherSpec.hash_size];
  31.             3.2.3) uint8 padding[GenericBlockCipher.padding_length];
  32.             3.2.4) uint8 padding_length;
  33. 6. MAC(0、16、20位)

1.2 SSL握手协议

        握手协议是客户机和服务器用SSL连接通信时使用的"第一个"子协议，握手协议包括客户机与服务器之间的一系列消息。
SSL握手协议被封装在记录协议中，该协议允许服务器与客户机在应用程序传输和接收数据之前互相认证、协商加密算法和密钥。在初次建立SSL连接时，服务器与客户机交换一系列消息。
这些消息交换能够实现如下操作：

  1. 1. 客户机认证服务器
  2. 2. 协商客户机与服务器选择双方都支持的密码算法
  3. 3. 可选择的服务器认证客户
  4. 4. 使用公钥加密技术生成共享密钥
  5. 5. 建立加密SSL连接

        SSL握手协议报文格式如下

 

  1. 1. 类型(Type)(1字节):
  2. 该字段指明使用的SSL握手协议报文类型
  3.     1) hello_request:
  4.     2) client_hello:  
  5.     3) server_hello: 
  6.     4) certificate: 
  7.     5) server_key_exchange:  
  8.     6) certificate_request:  
  9.     7) server_done: 
  10.     8) certificate_verify:  
  11.     9) client_key_exchange:  
  12.     10) finished:  
  13. 2. 长度(Length)(3字节):
  14. 以字节为单位的报文长度。
  15. 3. 内容(Content)(≥1字节):
  16. 对应报文类型的的实际内容、参数
  17.     　　1) hello_request: 空
  18.         2) client_hello:  
  19.         　　2.1) 版本(ProtocolVersion)
  20.         　　代表客户端可以支持的SSL最高版本号
  21.             　　2.1.1) 主版本: 3
  22.             　　2.1.2) 次版本: 0
  23.         　　2.2) 随机数(Random)
  24.         　　客户端产生的一个用于生成主密钥(master key)的32字节的随机数(主密钥由客户端和服务端的随机数共同生成)
  25.             　　2.2.1) uint32 gmt_unix_time;
  26.             　　2.2.2) opaque random_bytes[28];
  27.         　　4+28=32字节
  28.         　　2.3) 会话ID: opaque SessionID<0..32>;
  29.         　　2.4) 密文族(加密套件): 
  30.         　　一个客户端可以支持的密码套件列表。这个列表会根据使用优先顺序排列，每个密码套件都指定了"密钥交换算法(Deffie-Hellman密钥交换算法、基于RSA的密钥交换和另一种实现在Fortezza chip上的密钥交换)"、"加密算法(DES、RC4、RC2、3DES等)"、"认证算法(MD5或SHA-1)"、"加密方式(流、分组)"
  31.             　　2.4.1) CipherSuite SSL_RSA_WITH_NULL_MD5                  
  32.             　　2.4.2) CipherSuite SSL_RSA_WITH_NULL_SHA                   
  33.             　　2.4.3) CipherSuite SSL_RSA_EXPORT_WITH_RC4_40_MD5          
  34.             　　2.4.4) CipherSuite SSL_RSA_WITH_RC4_128_MD5                
  35.             　　2.4.5) CipherSuite SSL_RSA_WITH_RC4_128_SHA                
  36.             　　2.4.6) CipherSuite SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5     
  37.             　　2.4.7) CipherSuite SSL_RSA_WITH_IDEA_CBC_SHA              
  38.             　　2.4.8) CipherSuite SSL_RSA_EXPORT_WITH_DES40_CBC_SHA     
  39.             　　2.4.9) CipherSuite SSL_RSA_WITH_DES_CBC_SHA               
  40.             　　2.4.10) CipherSuite SSL_RSA_WITH_3DES_EDE_CBC_SHA       
  41.             　　2.4.11) CipherSuite SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA    
  42.             　　2.4.12) CipherSuite SSL_DH_DSS_WITH_DES_CBC_SHA             
  43.             　　2.4.13) CipherSuite SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA        
  44.             　　2.4.14) CipherSuite SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA    
  45.             　　2.4.15) CipherSuite SSL_DH_RSA_WITH_DES_CBC_SHA             
  46.             　　2.4.16) CipherSuite SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA       
  47.             　　2.4.17) CipherSuite SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA   
  48.             　　2.4.18) CipherSuite SSL_DHE_DSS_WITH_DES_CBC_SHA            
  49.             　　2.4.19) CipherSuite SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA       
  50.             　　2.4.20) CipherSuite SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA   
  51.             　　2.4.21) CipherSuite SSL_DHE_RSA_WITH_DES_CBC_SHA           
  52.             　　2.4.22) CipherSuite SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA  
  53.             　　2.4.23) CipherSuite SSL_DH_anon_EXPORT_WITH_RC4_40_MD5     
  54.             　　2.4.24) CipherSuite SSL_DH_anon_WITH_RC4_128_MD5            
  55.             　　2.4.25) CipherSuite SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA  
  56.             　　2.4.26) CipherSuite SSL_DH_anon_WITH_DES_CBC_SHA           
  57.             　　2.4.27) CipherSuite SSL_DH_anon_WITH_3DES_EDE_CBC_SHA    
  58.             　　2.4.28) CipherSuite SSL_FORTEZZA_KEA_WITH_NULL_SHA          
  59.             　　2.4.29) CipherSuite SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA  
  60.             　　2.4.30) CipherSuite SSL_FORTEZZA_KEA_WITH_RC4_128_SHA      
  61.         　　2.5) 压缩方法
  62.         3) server_hello: 
  63.         　　3.1) 版本(ProtocolVersion)
  64.         　　代表服务端"采纳"的最高支持的SSL版本号
  65.             　　3.1.1) 主版本: 3
  66.             　　3.1.2) 次版本: 0
  67.         　　3.2) 随机数(Random)
  68.         　　服务端产生的一个用于生成主密钥(master key)的32字节的随机数(主密钥由客户端和服务端的随机数共同生成)
  69.             　　3.2.1) uint32 gmt_unix_time;
  70.             　　3.2.2) opaque random_bytes[28];
  71.         　　4+28=32字节
  72.         　　3.3) 会话ID: opaque SessionID<0..32>;
  73.         　　3.4) 密文族(加密套件): 
  74.         　　代表服务端采纳的用于本次通讯的的加密套件
  75.         　　3.5) 压缩方法:
  76.         　　代表服务端采纳的用于本次通讯的的压缩方法
  77.     　　总体来看，server_hello就是服务端对客户端的的回应，表示采纳某个方案
  78.         4) certificate: 
  79.     　　SSL服务器将自己的"服务端公钥证书(注意，是公钥整数)"发送给SSL客户端  
  80.     　　ASN.1Cert certificate_list<1..2^24-1>;
  81.         5) server_key_exchange:   
  82.         　　1) RSA
  83.         　　执行RSA密钥协商过程
  84.             　　1.1) RSA参数(ServerRSAParams)
  85.                 　　1.1.1) opaque RSA_modulus<1..2^16-1>;
  86.                 　　1.1.2) opaque RSA_exponent<1..2^16-1>;
  87.            　　 1.2) 签名参数(Signature)
  88.                 　　1.2.1) anonymous: null
  89.                 　　1.2.2) rsa
  90.                     　　1.2.2.1) opaque md5_hash[16];
  91.                     　　1.2.2.2) opaque sha_hash[20];
  92.                 　　1.2.3) dsa
  93.                     　　1.2.3.1) opaque sha_hash[20];
  94.         　　2) diffie_hellman
  95.         　　执行DH密钥协商过程
  96.             　　2.1) DH参数(ServerDHParams)
  97.                 　　2.1.1) opaque DH_p<1..2^16-1>;
  98.                 　　2.1.2) opaque DH_g<1..2^16-1>;
  99.                 　　2.1.3) opaque DH_Ys<1..2^16-1>;
  100.             　　2.2) 签名参数(Signature)
  101.                 　　2.2.1) anonymous: null
  102.                 　　2.2.2) rsa
  103.                     　　2.2.2.1) opaque md5_hash[16];
  104.                     　　2.2.2.2) opaque sha_hash[20];
  105.                 　　2.2.3) dsa
  106.                     　　2.2.3.1) opaque sha_hash[20];
  107.         　　3) fortezza_kea
  108.         　　执行fortezza_kea密钥协商过程
  109.             　　3.1) opaque r_s [128]
  110.     6) certificate_request:   
  111.         6.1) 证书类型(CertificateType)
  112.             6.1.1) RSA_sign
  113.             6.1.2) DSS_sign
  114.             6.1.3) RSA_fixed_DH
  115.             6.1.4) DSS_fixed_DH
  116.             6.1.5) RSA_ephemeral_DH
  117.             6.1.6) DSS_ephemeral_DH  
  118.             6.1.7) FORTEZZA_MISSI
  119.         6.2) 唯一名称(DistinguishedName)
  120.         certificate_authorities<3..2^16-1>;
  121.     7) server_done: 
  122.     服务器总是发送server_hello_done报文，指示服务器的hello阶段结束
  123.     struct { } ServerHelloDone;
  124.     8) certificate_verify:  
  125.     签名参数(Signature)
  126.         8.1) anonymous: null
  127.         8.2) rsa
  128.             8.2.1) opaque md5_hash[16];
  129.             8.2.2) opaque sha_hash[20];
  130.         8.3) dsa
  131.             8.3.1) opaque sha_hash[20];
  132.     9) client_key_exchange:  
  133.         9.1) RSA
  134.             9.1.1) PreMasterSecret
  135.                 9.1.1.1) ProtocolVersion 
  136.                 9.1.1.2) opaque random[46];
  137.         9.2) diffie_hellman: opaque DH_Yc<1..2^16-1>;
  138.         9.3) fortezza_kea
  139.             9.3.1) opaque y_c<0..128>;
  140.             9.3.2) opaque r_c[128];
  141.             9.3.3) opaque y_signature[40];
  142.             9.3.4) opaque wrapped_client_write_key[12];
  143.             9.3.5) opaque wrapped_server_write_key[12];
  144.             9.3.6) opaque client_write_iv[24];
  145.             9.3.7) opaque server_write_iv[24];
  146.             9.3.8) opaque master_secret_iv[24];
  147.             9.3.9) opaque encrypted_preMasterSecret[48];
  148.     10) finished:  
  149.         10.1) opaque md5_hash[16];
  150.         10.2) opaque sha_hash[20];

1.3 SSL改变密码协议

        SSL修改密文协议的报文由值为1的单一字节组成，只有一个"1"值

        SSL修改密文协议的设计目的是为了保障SSL传输过程的安全性，因为SSL协议要求客户端或服务器端每隔一段时间必须改变其加解密参数。当某一方要改变其加解密参数时，就发送一个简单的消息通知对方下一个要传送的数据将采用新的加解密参数，也就是要求对方改变原来的安全参数。

1.4 SSL警告协议

        SSL警告协议亦称SSL告警协议、SSL报警协议，是用来为对等实体传递SSL的相关警告。如果在通信过程中某一方发现任何异常，就需要给对方发送一条警示消息通告。
        SSL报警协议报文由严重级别和警告代码两部分组成

 

  1. 1. 严重级别(AlertLevel )
  2.     1) Fatal
  3.     Fatal级报警即致命级报警，它要求通信双方都要采取紧急措施，并终止会话，同时消除自己缓冲区相应的会话记录 
  4.     2) Waming
  5.     Warning级报警即警告级报警的处理，通常是通信双方都只进行日志记录，它对通信过程不造成影响
  6. 2. 警告代码 
  7.     1) bad_record_mac：收到了不正确的MAC 
  8. 　　    2) unexpected_message：接收了不合适的报文 
  9.     3) decompression_failure：解压缩函数收到不适当的输入。
  10.     4) illegal_parameter：握手报文中的一个字段超出范围或与其他字段不兼容。
  11.     5) certificate_revoked：证书已经被废弃。
  12.     6) bad_certificate：收到的证书是错误的。
  13.     7) certificate_expired：证书已经过期。
  14.     8) handshake_failer：握手过程失败。
  15.     9) no_certificate: 未提供证书
  16.     10) unsupported_certificate: 未支持的证书格式
  17.     11) certificate_unknown: 未知证书

2. TLS协议格式

        TLS并不是一个新协议，它是SSL(准确的说是SSL v3)的强化版，在整个协议格式上，和SSL类似

http://www.rfc-editor.org/rfc/rfc2246.txt

2.1 TLS与SSL的差异

  1. 1. 版本号：TLS记录格式与SSL记录格式相同，但版本号的值不同，TLS的版本1.0使用的版本号为SSLv3.1。
  2. 2. 报文鉴别码：SSLv3.0和TLS的MAC算法及MAC计算的范围不同。TLS使用了RFC-2104定义的HMAC算法。SSLv3.0使用了相似的算法，两者差别在于SSLv3.0中，填充字节与密钥之间采用的是
  3. 连接运算，而HMAC算法采用的是异或运算。但是两者的安全程度是相同的。
  4. 3. 伪随机函数：TLS使用了称为PRF的伪随机函数来将密钥扩展成数据块，是更安全的方式。
  5. 4. 报警代码：TLS支持几乎所有的SSLv3.0报警代码，而且TLS还补充定义了很多报警代码，如
  6.     1) 解密失败(decryption_failed)
  7.     2) 记录溢出(record_overflow)
  8.     3) 未知CA(unknown_ca)
  9.     4) 拒绝访问(access_denied)等。
  10. 5. 密文族和客户证书：SSLv3.0和TLS存在少量差别，即TLS"不支持":
  11.     1) Fortezza密钥交换
  12.     2) 加密算法
  13.     3) 客户证书。
  14. 6. certificate_verify和finished消息：SSLv3.0和TLS在用certificate_verify和finished消息计算MD5和SHA-1散列码时，计算的输入有少许差别，但安全性相当。
  15. 7. 加密计算：TLS与SSLv3.0在计算主密值(master secret)时采用的方式不同。但都是以客户端和服务端各自产生的随机数Ramdom作为输入
  16. 8. 填充：用户数据加密之前需要增加的填充字节。在SSL中，填充后的数据长度要达到密文块长度的最小整数倍。而在TLS中，填充后的数据长度可以是密文块长度的任意整数倍
  17. (但填充的最大长度为255字节)，这种方式可以防止基于对报文长度进行分析的攻击。

2.2．TLS的主要增强内容

        TLS的主要目标是使SSL更安全，并使协议的规范更精确和完善。TLS 在SSL v3.0 的基础上，提供了以下增强内容：

  1. 1. 更安全的MAC算法
  2. 2. 更严密的警报
  3. 3. "灰色区域"规范的更明确的定义

2.3 TLS对于安全性的改进

  1. 1. 对于消息认证使用密钥散列法：TLS 使用"消息认证代码的密钥散列法"(HMAC)，当记录在开放的网络(如因特网)上传送时，该代码确保记录不会被变更。SSLv3.0还提供键控消息认证，但HMAC比SSLv3.0使用的(消息认证代码)MAC 功能更安全。
  2. 2. 增强的伪随机功能(PRF)：PRF生成密钥数据。在TLS中，HMAC定义PRF。PRF使用两种散列算法保证其安全性。如果任一算法暴露了，只要第二种算法未暴露，则数据仍然是安全的。
  3. 3. 改进的已完成消息验证：TLS和SSLv3.0都对两个端点提供已完成的消息，该消息认证交换的消息没有被变更。然而，TLS将此已完成消息基于PRF和HMAC值之上，这也比SSLv3.0更安全。
  4. 4. 一致证书处理：与SSLv3.0不同，TLS试图指定必须在TLS之间实现交换的证书类型。
  5. 5. 特定警报消息：TLS提供更多的特定和附加警报，以指示任一会话端点检测到的问题。TLS还对何时应该发送某些警报进行记录。

3. HTTPS、SSL/TLS初始化协商过程

        SSL通过握手过程在客户端和服务器之间协商会话参数，并建立会话。会话包含的主要参数有会话ID、对方的证书、加密套件（密钥交换算法、数据加密算法和MAC算法等）以及主密钥（master secret）。通过SSL会话传输的数据，都将采用该会话的主密钥和加密套件进行加密、计算MAC等处理。
不同情况下，SSL握手过程存在差异。下面将分别描述以下三种情况下的握手过程：

  1. 1. 只验证服务器的SSL握手过程
  2. 2. 验证服务器和客户端的SSL握手过程
  3. 3. 恢复原有会话的SSL握手过程

3.1 只验证服务器的SSL握手过程

1. Client Hello

  1. SSL客户端通过Client Hello消息向SSL服务端发送:
  2.     1) 支持的SSL版本
  3.     2) 客户端生成的一个用于生成主密钥(master key)的32字节的随机数(主密钥由客户端和服务端的随机数共同生成)
  4.     3) 会话ID
  5.     3) 加密套件
  6.         3.1) 加密算法
  7.         3.2) 密钥交换算法
  8.         3.3) MAC算法
  9.         3.4) 加密方式(流、分组)
  10.     4) 压缩算法(如果支持压缩的话)
  11. 2. Server Hello
  12.        SSL服务器确定本次通信采用的SSL版本和加密套件，并通过Server Hello消息通知给SSL客户端。如果SSL服务器允许SSL客户端在以后的通信中重用本次会话，则SSL服务器会为本次会话分配会话ID，并通过Server Hello消息发送给SSL客户端。
  13.     1) 服务端采纳的本次通讯的SSL版本
  14.     2) 服务端生成的一个用于生成主密钥(master key)的32字节的随机数(主密钥由客户端和服务端的随机数共同生成)
  15.     3) 会话ID
  16.     3) 服务端采纳的用于本次通讯的加密套件(从客户端发送的加密套件列表中选出了一个)
  17.         3.1) 加密算法
  18.         3.2) 密钥交换算法
  19.         3.3) MAC算法
  20.         3.4) 加密方式(流、分组)
  21.     4) 压缩算法(如果支持压缩的话)
  22. 3. Certificate
  23.         SSL服务器将"携带自己公钥信息的数字证书"和到根CA整个链发给客户端通过Certificate消息发送给SSL客户端(整个公钥文件都发送过去)，客户端使用这个公钥完成以下任务:
  24.     1) 客户端可以使用该公钥来验证服务端的身份，因为只有服务端有对应的私钥能解密它的公钥加密的数据
  25.     2) 用于对"premaster secret"进行加密，这个"premaster secret"就是用客户端和服务端生成的Ramdom随机数来生成的，客户端用服务端的公钥对其进行了加密后发送给服务端
  26. 4. Server Key Exchange
  27.         密钥交换阶段(可选步骤)，之所以说是可选步骤，是因为只有在下列场景下这个步骤才会发生
  28.     1) 协商采用了RSA加密，但是服务端的证书没有提供RSA公钥
  29.     2) 协商采用了DH加密，但是服务端的证书没有提供DH参数
  30.     3) 协商采用了fortezza_kea加密，但是服务端的证书没有提供参数
  31.         总结来说，"Server Key Exchange"这个步骤是对上一步"Certificate"的一个补充，为了让整个SSL握手过程能正常进行
  32. 5. Server Hello Done
  33.         SSL服务器发送Server Hello Done消息，通知SSL客户端版本和加密套件协商结束 
  34. 6. Client Key Exchange
  35.         SSL客户端验证SSL服务器的证书合法后，利用证书中的公钥加密SSL客户端随机生成的"premaster secret"(通过之前客户端、服务端分别生成的随机数生成的)，并通过Client Key Exchange消息发送给SSL服务器。
  36.         注意，这一步完成后，客户端和服务端都已经保存了"主密钥"(之所以这里叫预备主密钥，是因为还没有投入使用)。这个"主密钥"会用于之后的SSL通信数据的加密
  37. 7. Change Cipher Spec
  38.         SSL客户端发送Change Cipher Spec消息，通知SSL服务器后续报文将采用协商好的"主密钥"和加密套件进行加密和MAC计算。
  39. 8. Finished
  40.         SSL客户端计算已发送和接受的握手消息(除Change Cipher Spec消息外所有已交互的消息)的Hash值，利用协商好的密钥和加密套件处理Hash值(计算并添加MAC值、加密等)，并通过Finished消息发送给SSL服务器。SSL服务器利用同样的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比较，如果二者相同，且MAC值验证成功，则证明密钥和加密套件协商成功。
  41. 9. Change Cipher Spec
  42.         同样地，SSL服务器发送Change Cipher Spec消息，通知SSL客户端后续报文将采用协商好的密钥和加密套件进行加密和MAC计算。
  43. 10. Finished
  44.         SSL服务器计算已交互的握手消息的Hash值，利用协商好的密钥和加密套件处理Hash值(计算并添加MAC值、加密等)，并通过Finished消息发送给SSL客户端。SSL客户端利用同样的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比较，如果二者相同，且MAC值验证成功，则证明密钥和加密套件协商成功。
  45.         SSL客户端接收到SSL服务器发送的Finished消息后，如果解密成功，则可以判断SSL服务器是数字证书的拥有者，即SSL服务器身份验证成功，因为只有拥有私钥的SSL服务器才能从
  46.         Client Key Exchange消息中解密得到premaster secret，从而间接地实现了SSL客户端对SSL服务器的身份验证。

3.2 验证服务器和客户端的SSL握手过程

        "验证服务器和客户端的SSL握手过程"和"只验证服务器的SSL握手过程"整体过程类似，只是多了服务端向客户端要求发送证明客户端身份的证书、以及客户端发送证书的过程

  1. 1. Client Hello
  2. SSL客户端通过Client Hello消息向SSL服务端发送:
  3.     1) 支持的SSL版本
  4.     2) 客户端生成的一个用于生成主密钥(master key)的32字节的随机数(主密钥由客户端和服务端的随机数共同生成)
  5.     3) 会话ID
  6.     3) 加密套件
  7.         3.1) 加密算法
  8.         3.2) 密钥交换算法
  9.         3.3) MAC算法
  10.         3.4) 加密方式(流、分组)
  11.     4) 压缩算法(如果支持压缩的话)
  12. 2. Server Hello
  13.          SSL服务器确定本次通信采用的SSL版本和加密套件，并通过Server Hello消息通知给SSL客户端。如果SSL服务器允许SSL客户端在以后的通信中重用本次会话，则SSL服务器会为本次会话分配
  14. 会话ID，并通过Server Hello消息发送给SSL客户端。
  15.     1) 服务端采纳的本次通讯的SSL版本
  16.     2) 服务端生成的一个用于生成主密钥(master key)的32字节的随机数(主密钥由客户端和服务端的随机数共同生成)
  17.     3) 会话ID
  18.     3) 服务端采纳的用于本次通讯的加密套件(从客户端发送的加密套件列表中选出了一个)
  19.         3.1) 加密算法
  20.         3.2) 密钥交换算法
  21.         3.3) MAC算法
  22.         3.4) 加密方式(流、分组)
  23.     4) 压缩算法(如果支持压缩的话)
  24. 3. Certificate
  25.          SSL服务器将"携带自己公钥信息的数字证书"和到根CA整个链发给客户端通过Certificate消息发送给SSL客户端(整个公钥文件都发送过去)，客户端使用这个公钥完成以下任务:
  26.     1) 客户端可以使用该公钥来验证服务端的身份，因为只有服务端有对应的私钥能解密它的公钥加密的数据
  27.     2) 用于对"premaster secret"进行加密，这个"premaster secret"就是用客户端和服务端生成的Ramdom随机数来生成的，客户端用服务端的公钥对其进行了加密后发送给服务端
  28. 4. Server Key Exchange
  29.          密钥交换阶段(可选步骤)，之所以说是可选步骤，是因为只有在下列场景下这个步骤才会发生
  30.     1) 协商采用了RSA加密，但是服务端的证书没有提供RSA公钥
  31.     2) 协商采用了DH加密，但是服务端的证书没有提供DH参数
  32.     3) 协商采用了fortezza_kea加密，但是服务端的证书没有提供参数
  33.         总结来说，"Server Key Exchange"这个步骤是对上一步"Certificate"的一个补充，为了让整个SSL握手过程能正常进行
  34. 5. Client Certificate Request
  35.         服务器可以向客户发送certificate_request请求证书，即服务端需要客户端证明自己的身份
  36. 6. Server Hello Done
  37.         SSL服务器发送Server Hello Done消息，通知SSL客户端版本和加密套件协商结束 
  38. 7. Client Certificate
  39.         客户端(浏览器)向服务器发送自己的客户端证书，以证明自己的身份
  40. 8. Client Key Exchange
  41.         SSL客户端验证SSL服务器的证书合法后，利用证书中的公钥加密SSL客户端随机生成的"premaster secret"(通过之前客户端、服务端分别生成的随机数生成的)，并通过Client Key Exchange消息发送给SSL服务器。
  42.         注意，这一步完成后，客户端和服务端都已经保存了"主密钥"(之所以这里叫预备主密钥，是因为还没有投入使用)。这个"主密钥"会用于之后的SSL通信数据的加密
  43. 9. Certificate Verify
  44.         客户可能发送client_verify报文来校验客户端发送的证书
  45. 10. Change Cipher Spec
  46.         SSL客户端发送Change Cipher Spec消息，通知SSL服务器后续报文将采用协商好的"主密钥"和加密套件进行加密和MAC计算。
  47. 11. Finished
  48.         SSL客户端计算已交互的握手消息(除Change Cipher Spec消息外所有已交互的消息)的Hash值，利用协商好的密钥和加密套件处理Hash值(计算并添加MAC值、加密等)，并通过Finished消息发送给SSL服务器。SSL服务器利用同样的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比较，如果二者相同，且MAC值验证成功，则证明密钥和加密套件协商成功。
  49. 12. Change Cipher Spec
  50.         同样地，SSL服务器发送Change Cipher Spec消息，通知SSL客户端后续报文将采用协商好的密钥和加密套件进行加密和MAC计算。
  51. 13. Finished
  52.         SSL服务器计算已交互的握手消息的Hash值，利用协商好的密钥和加密套件处理Hash值(计算并添加MAC值、加密等)，并通过Finished消息发送给SSL客户端。SSL客户端利用同样的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比较，如果二者相同，且MAC值验证成功，则证明密钥和加密套件协商成功。
  53.         SSL客户端接收到SSL服务器发送的Finished消息后，如果解密成功，则可以判断SSL服务器是数字证书的拥有者，即SSL服务器身份验证成功，因为只有拥有私钥的SSL服务器才能从
  54.         Client Key Exchange消息中解密得到premaster secret，从而间接地实现了SSL客户端对SSL服务器的身份验证。

3.3 只验证服务端的TLS握手过程

TLS握手阶段1: Clien Hello

TLS握手阶段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结束

TLS握手阶段3: Client Key Exchange、Change Cipher Spec

Client Key Exchange

客户端和服务端共同完成DH过程(上以阶段中Serer Key Exchange已经发送了DH的一半参数)

Change Cipher Spec

客户端发送"Change Cipher Spec"(密钥改变协议)通知服务端密钥已经协商好了，以后咱们都用这个密钥进行通信数据的加密吧

3.4 使用HTTS加密通道发送WEB数据

此时，所有的HTTPS通信数据都是处于加密状态了，即使中间人在网络中嗅探，也无法简单地获取明文

3.5 RDP SSL通信过程

  1. 1. SSL: (Secure Socket Layer 安全套接字层)，为Netscape所研发，用以保障在Internet上数据传输之安全，利用数据加密(Encryption)技术，可确保数据在网络上之传输过程中不会被截取。当前版本为3.0。它已被广泛地用于Web浏览器与服务器之间的身份认证和加密数据传输 
  2. SSL协议位于TCP/IP协议与各种应用层协议之间，为数据通讯提供安全支持。SSL协议可分为两层
  3.     1) SSL记录协议(SSL Record Protocol): 它建立在可靠的传输协议(如TCP)之上，为高层协议提供数据封装、压缩、加密等基本功能的支持
  4.     2) SSL握手协议(SSL Handshake Protocol): 它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等 
  5.  
  6. 2. TLS: (Transport Layer Security，传输层安全协议)，用于两个应用程序之间提供保密性和数据完整性 
  7. TLS 1.0是IETF(Internet Engineering Task Force Internet工程任务组)制定的一种新的协议，它建立在SSL 3.0协议规范之上，是SSL 3.0的后续版本，可以理解为SSL 3.1，它是写入了 RFC 的。该协议由两层组成 \
  8.     1) TLS 记录协议(TLS Record): 较低的层为 TLS 记录协议，位于某个可靠的传输协议(例如 TCP)上面
  9.     2) TLS 握手协议(TLS Handshake)

0x1: 密钥协商过程——TLS握手(HANDSHAKE)

Handshake Protocol用来协商密钥，协议的大部分内容就是通信双方如何利用它来安全的协商出一份密钥，There are 10 handshake message types in the TLS specification

                          |
                           |
                           |
         Record Layer      |  Handshake Layer
                           |                                  |
                           |                                  |  ...more messages
  +----+----+----+----+----+----+----+----+----+------ - - - -+--
  | 22 |vers|    |    |    |    |    |    |    |              |
  |0x16|sion|    |    |    |    |    |    |    |message       |
  +----+----+----+----+----+----+----+----+----+------ - - - -+--
    /               /      | \    \----\-----\                |
   /               /       |  \         \
  type: 22        /        |   \         handshake message length
                 /              type
                /
           length: arbitrary (up to 16k)

  1. 1. Record Type Values
  2.     1) CHANGE_CIPHER_SPEC        20     0x14
  3.     2) ALERT                     21     0x15
  4.     3) HANDSHAKE                 22     0x16
  5.     4) APPLICATION_DATA          23     0x17
  6.  
  7. 2. Version Values 
  8.     1) SSL 3.0                   3,0  0x0300
  9.     2) TLS 1.0                   3,1  0x0301
  10.     3) TLS 1.1                   3,2  0x0302
  11.     4) TLS 1.2                   3,3  0x0303
  12.  
  13. 3. length(2 bytes)
  14.  
  15. 4. Handshake Type Values
  16.     1) HELLO_REQUEST              0     0x00
  17.     2) CLIENT_HELLO               1     0x01
  18.     3) SERVER_HELLO               2     0x02
  19.     4) CERTIFICATE               11     0x0b
  20.     5) SERVER_KEY_EXCHANGE       12     0x0c
  21.     6) CERTIFICATE_REQUEST       13     0x0d
  22.     7) SERVER_DONE               14     0x0e
  23.     8) CERTIFICATE_VERIFY        15     0x0f
  24.     9) CLIENT_KEY_EXCHANGE       16     0x10
  25.     10) FINISHED                  20     0x14

1. CLIENT_HELLO

2. SERVER_HELLO

3. CLIENT_KEY_EXCHANGE

0x2: 密钥协商过程——算法协商(CHANGE_CIPHER_SPEC)

1. CLIENT_HELLO

0x3: APPLICATION_DATA

0x4: ALERT

  1.                            |
  2.                            |
  3.                            |
  4.          Record Layer      |  Alert Layer
  5.                            |
  6.                            |
  7.   +----+----+----+----+----+----+----+
  8.   | 21 |    |    |    |    |    |    |
  9.   |0x15|    |    |  0 |  2 |    |    |
  10.   +----+----+----+----+----+----+----+
  11.     /               /      |
  12.    /               /       |
  13.   type: 21        /        |
  14.                  /
  15.                 /
  16.            length: 2

 

  1. Alert severity               dec     hex
  2.   ----------------------------------------
  3.   WARNING                        1    0x01
  4.   FATAL                          2    0x02
  5.  
  6.  
  7.  
  8.   TLS 1.0 Alert descriptions   dec     hex
  9.   ----------------------------------------
  10.  
  11.   CLOSE_NOTIFY                   0    0x00
  12.   UNEXPECTED_MESSAGE            10    0x0A
  13.   BAD_RECORD_MAC                20    0x14
  14.   DECRYPTION_FAILED             21    0x15
  15.   RECORD_OVERFLOW               22    0x16
  16.   DECOMPRESSION_FAILURE         30    0x1E
  17.   HANDSHAKE_FAILURE             40    0x28
  18.   NO_CERTIFICATE                41    0x29
  19.   BAD_CERTIFICATE               42    0x2A
  20.   UNSUPPORTED_CERTIFICATE       43    0x2B
  21.   CERTIFICATE_REVOKED           44    0x2C
  22.   CERTIFICATE_EXPIRED           45    0x2D
  23.   CERTIFICATE_UNKNOWN           46    0x2E
  24.   ILLEGAL_PARAMETER             47    0x2F
  25.   UNKNOWN_CA                    48    0x30
  26.   ACCESS_DENIED                 49    0x31
  27.   DECODE_ERROR                  50    0x32
  28.   DECRYPT_ERROR                 51    0x33
  29.   EXPORT_RESTRICTION            60    0x3C
  30.   PROTOCOL_VERSION              70    0x46
  31.   INSUFFICIENT_SECURITY         71    0x47
  32.   INTERNAL_ERROR                80    0x50
  33.   USER_CANCELLED                90    0x5A
  34.   NO_RENEGOTIATION             100    0x64

在RDP TLS1.0模式下，当密码错误认证失败时(应用层认证)，Server会返回ALERT包

 

相关学习资料

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

声明：本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：【wpsshop博客】
推荐阅读
相关标签

Copyright © 2003-2013 www.wpsshop.cn 版权所有，并保留所有权利。

  

闽ICP备14008679号