SSL/TLS详解

该文章主要提供一个详细的解释关于SSL/TLS协议，特别是握手协议，它关联到信息，警告以及记录协议。

1.握手协议(The handshake protocol）

初始化发给服务器的客户端消息

client Hello：

客户端通过发送hello消息给服务器来初始化一个会话（简单的说就是客户端想要连上服务器，就必须经历这个会话过程），hello消息包括：

• Version Number(版本号):客户端发送他支持的最高的版本号。2表示SSL2.0， 3表示SSL3.0， 3.1表示TLS。虽然在IETF RFC中TLS版本为1.0，1.1或者1.2， 但是这里用3.1表示TLS只是想表达出比SSLv3更高级别。
  
• Randomly Generated Data(随机生成的数据):ClientRandom[32]，由4个字节的日期时间加上28个字节的随机生成数组成。这个28字节的随机生成数最后和服务器的随机生成数一起来生成一个主密(master key)。
  
• Session Identification(sessionID-会话标识):sessionID用于恢复上一个会话。这个恢复功能是很有用的，因为创建一个新的会话需要一系列处理器密集操作才能完成。会话信息通过sessionID来标识，它被保存在各自的会话缓存中(服务器和客户端都保存)。
  
• Cipher Suit(密码):客户端可用的密码清单，例如TLS_RSA_WITH_DES_CBC_SHA，TLS是协议版本，RSA是算法(用于交换key)，DES_CBC是加密算法，SHA是hash函数。
  
• Compression Algorithm(压缩算法)
  

client hello消息实例

ClientVersion 3,1
ClientRandom[32]
SessionID: None (new session)
Suggested Cipher Suites:
   TLS_RSA_WITH_3DES_EDE_CBC_SHA
   TLS_RSA_WITH_DES_CBC_SHA
Suggested Compression Algorithm: NONE

服务器回应客户端

Server Hello.包括：

• Version Number:双方都支持的最高版本。
  
• Randomly Generated Data:ServerRandom[32],由4字节的日期时间和28字节的随机生成数组成，这个28字节的随机生成数和客户端的随机生成数一起生成主密(master key).
  
• Session Identification(SessionID):有3个选择
  

1. 新的sessionID:如果客户端没有要求用前一个session，服务器将生成一个新的sessionID，或者服务器无法恢复客户端指定的session，也将生成一个新的。
   
2. 恢复的sessionID:和client发送过来的sessionID一样，服务器将会尝试恢复这个session
   
3. NULL:表示新的session，并且服务器不希望这个session被恢复在以后，所以没有指定id
   

• Cipher Suit:服务器选择双方都支持的最强密码。如果没有双发都支持的密码，session将以"handshake failure"警告结束。
  
• Compression Algorithm:压缩算法。

server hello实例:

Version 3,1
ServerRandom[32]
SessionID: bd608869f0c629767ea7e3ebf7a63bdcffb0ef58b1b941e6b0c044acb6820a77
Use Cipher Suite:
TLS_RSA_WITH_3DES_EDE_CBC_SHA
Compression Algorithm: NONE

Server Certificate.服务器发送它自己的证书给客户端，这个证书包含了服务器的公钥，客户端将使用这个公钥来认证服务器以及加密premaster secret(预置密码)。

客户端也会检查服务器证书中包含的名字，检查是否和client连接的一样，如果用户在浏览器中输入www.test.com，那么服务器证书应该也包含一个结构名为www.test.com 或者*.test.com.如果不匹配，浏览器将会发出警告。

Server Key Exchange.这是可选的一步(服务器创建一个临时的key发给客户端)，这个key被客户端用于加密client key exchange message，这一步当且仅当公钥算法无法提供关键的必要材料时被执行，例如服务器证书不包含公钥。

Client Certificate Request:这也是可选的一步，当服务器需要认证客户端的时候。像银行的网站之类的需要用到这个，只有认证成功后才会提供敏感信息。

Server Hello Done:表示服务器消息结束并且等待客户端的回复。

客户端回应服务器

Client certificate:如果服务器发送了client certificate request，客户端将发送它的的证书给服务器，用于让服务器认证客户端，该证书包含了客户端的公钥。

Client Key Exchange:客户端用双方的28字节随机数来生成一个premaster secret(预置密码),然后用客户端发送过来的服务器公钥来加密这个premaster secret，最后发送给server。

只有拥有与服务器公钥匹配的密钥来能解密这个premaster secret.解密成功后来才能继续协商.

这个消息也包含协议版本，服务器将验证该版本与client hello message中包含的版本是否吻合，该措施用于防止rollback attacks(通过操纵消息来降低双方使用协议的安全性,早期版本的协议)。

Certificate Verify:只有当client发送了client certificate message后才会发送这个消息.客户端用自己的私钥来加密消息的做法到此为止(后面将使用双发协商的算法和密码来加密消息,不在使用客户端的私钥)，服务器通过client的公钥来验证签名,从而确保了该消息是由客户端私钥签名过的。

Change Cipher Spec:该消息告诉服务器在client Finished message之后的所有信息将用双方协商的密码和算法来加密。

Client Finished:该消息是整个会谈的哈希，用于提供对client的进一步认证，它是第一个记录层加密和散列(之前的消息都在在协商).

服务器回复给客户端的最终消息

Change Cipher Spec Message:服务器告诉客户端，将开始使用双方协商的key来加密数据了

Server Finished Messge:该消息是真个信息交换的哈希值(这个信息交换过程使用session key和MAC secret)。如果客户端能够解密这个消息并且验证哈希值的有效性，那么SSL/TLS协商过程才算成功。

2.告警协议(The alert Sub-protocol)

告警协议是握手协议的组成部分，它包含一些事件驱动消息，可以被双发发送。根据警告消息，双发可以决定是否结束该会话或者继续，TLS specification in RFC 2246定义了这些警告，如下表:

Table 1.   Event-Driven Alert Messages from the Alert Sub-Protocol

 

Alert Message	Fatal?	Description
unexpected_message	Yes	Inappropriate message
bad_record_mac	Yes	Incorrect MAC
decryption_failed	Yes	Unable to decrypt TLSCiphertext correctly
record_overflow	Yes	Record is more than 2^14+1024 bytes
handshake_failure	Yes	Unacceptable security parameters
bad_certificate	Yes	There is a problem with the Certificate
unsupported_certificate	No	Certificate is unsupported
certificate_revoked	No	Certificate has been revoked
certificate_expired	No	Certificate has expired
certificate_unknown	No	Certificate is unknown
illegal_parameter	Yes	Security parameters violated
unknown_ca	Yes	CA unknown
access_denied	Yes	Sender does not want to negotiate
decode_error	Yes	Unable to decode message
decrypt_error	Yes	Handshake cryptographic operation failed
export_restriction	Yes	Not in compliance with export regulations
protocol_version	Yes	Protocol version not supported by both parties
insufficient_security	Yes	Security requirements no met
internal_error	Yes	Error not related to protocol
user_canceled	Yes	Not related to protocol failure
no_renegotiation	No	Negotiation request rejected.

3.数据层协议(the record protocol)

the record protocol 从应用层收到消息,包括:

• 合并碎片数据
  
• 通过数据块的序列号来保护数据
  
• 用协商的压缩算法压缩或者解压数据
  
• 加密或者解密数据
  
• 提供HMAC(SSLv3 使用MAC)给发送出去的数据，用于数据被接收后来检查数据的完整性
  

一旦在数据上完成了它的操作后，数据发送个tcp/ip传输层。如果数据是进来的，它将被发送给相应的进程进行处理。