TLS握手

http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html

1994年，NetScape公司设计了SSL协议（Secure Sockets Layer）的1.0版，但是未发布。

1995年，NetScape公司发布SSL 2.0版，很快发现有严重漏洞。

1996年，SSL 3.0版问世，得到大规模应用。

1999年，互联网标准化组织ISOC接替NetScape公司，发布了SSL的升级版TLS 1.0版。

2006年和2008年，TLS进行了两次升级，分别为TLS 1.1版和TLS 1.2版。最新的变动是2011年TLS 1.2的修订版。

http://blog.csdn.net/fw0124/article/details/40983787

http://blog.csdn.net/liangyihuai/article/details/53098482

使用如下语法，过滤指定ip的通讯，以及协议类型

ssl and ip.dst== 24.105.29.76

ssl一共有11个步骤，但是区分双向认证和单向认证。

SSL/TLS握手过程可以分成两种类型：

1）SSL/TLS 双向认证，就是双方都会互相认证，也就是两者之间将会交换证书。
2）SSL/TLS 单向认证，客户端会认证服务器端身份，而服务器端不会去对客户端身份进行验证。

我们知道，握手过程实际上就是通信双方协商交换一个用于对称加密的密钥的过程，而且握手过程是明文的。

Client	Server
1 Client Hello
	2 Server Hello 3 certificate 4 (server_key_exchange) 5 (certificate_request) 6 server_hello_done
7 (certificate) 8 client_key_exchange 9 (certifiate_verify) 10 change_cypher_spec ----finished----
	11 change_cypher_spec ----finished----

下面是一个单向认证的截图，风暴英雄和服务器的数据交互

(5,7,9是跳过的)

4.1 客户端发出请求（ClientHello）

第一步  Client Hello

首先，客户端（通常是浏览器）先向服务器发出加密通信的请求，这被叫做ClientHello请求。

在这一步，客户端主要向服务器提供以下信息。

（1） 支持的协议版本，比如TLS 1.0版。  Version

Version: TLS 1.2 (0x0303)

（2） 一个客户端生成的随机数，稍后用于生成"对话密钥"。 Random

这部分由时间和随机数组成。

Random: 5a18eca2df1b4246ec96ba558213d4eeeebf802a9e7e3470...
GMT Unix Time: Nov 25, 2017 12:08:02.000000000 China Standard Time
Random Bytes: df:1b:42:46:ec:96:ba:55:82:13:d4:ee:ee:bf:80:2a:9e:7e:34:70:38:00:76:56:f0:c5:f7:1a

（3） 支持的加密方法，比如RSA公钥加密。 Cipher Suites

Cipher Suites (30 suites)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x006a)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x0040)
Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)

（4） 支持的压缩方法。CompressionMethod

Compression Methods (1 method)
Compression Method: null (0)

4.2 服务器回应（SeverHello）

第二步   Server Hello

服务器收到客户端请求后，向客户端发出回应，这叫做SeverHello。

服务器的回应包含以下内容。

（1） 确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。

Version: TLS 1.2 (0x0303)

（2） 一个服务器生成的随机数，稍后用于生成"对话密钥"。

GMT Unix Time: Jan 11, 2050 11:55:48.000000000 China Standard Time
Random Bytes: 33:17:b7:9e:8d:37:b5:01:80:5c:f4:fc:3d:9f:de:1b:5d:86:11:cc:27:5e:ee:69:57:72:b3:97

（3） 确认使用的加密方法，比如RSA公钥加密。

Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)

（4） 服务器证书。

Compression Method: null (0)

第三步 Server Certificate

服务端将证书发送给客户端

有2个证书，分别来自Blizzard Entertainment, Inc.和DigiCert Inc

Certificate: 308205543082043ca00302010202100ebfca8ebf6dfa37ea... (id-at-commonName=*.battle.net,id-at-organizationName=Blizzard Entertainment, Inc.,id-at-localityName=Irvine,id-at-stateOrProvinceName=California,id-at-countryName=US)

Certificate: 308204b130820399a003020102021004e1e7a4dc5cf2f36d... (id-at-commonName=DigiCert SHA2 High Assurance Server CA,id-at-organizationalUnitName=www.digicert.com,id-at-organizationName=DigiCert Inc,id-at-countryName=US)

第四步 ServerKeyExchange

What's the purpose of Server Key Exchange when using Ephemeral Diffie-Hellman?

Diffie-Hellman（迪菲-赫尔曼）秘钥交换

In Diffie-Hellman, the client can't compute a premaster secret on its own;

both sides contribute to computing it, so the client needs to get a Diffie-Hellman public key from the server.

In ephemeral Diffie-Hellman, that public key isn't in the certificate (that's what ephemeral Diffie-Hellman means).

So the server has to send the client its ephemeral DH public key in a separate message so that the client can compute the premaster secret (remember, both parties need to know the premaster secret, because that's how they derive the master secret).

That message is the ServerKeyExchange.

EC Diffie-Hellman Server Params
Curve Type: named_curve (0x03)
Named Curve: secp256r1 (0x0017)
Pubkey Length: 65
Pubkey: 04:90:67:17:d1:ef:4d:3f:55:23:6b:69:f2:bf:9e:be:af:73:a3:e2:d5:3a:28:18:15:2a:5b:8f:62:d3:41:7b:0b:f9:bc:54:d9:32:60:49:01:17:43:31:ff:94:df:a0:d8:61:74:11:ba:a0:8e:54:73:a2:fb:df:1c:43:14:72:dc
Signature Hash Algorithm: 0x0201
Signature Hash Algorithm Hash: SHA1 (2)
Signature Hash Algorithm Signature: RSA (1)

第五步 Certificate Request[单向认证中没有这个]

第六步 Server Hello Done

4.3 客户端回应

客户端收到服务器回应以后，首先验证服务器证书。

如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。

如果证书没有问题，客户端就会从证书中取出服务器的公钥。

然后，向服务器发送下面三项信息。

（1） 一个随机数。该随机数用服务器公钥加密，防止被窃听。

（2） 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。

（3） 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。

第七步   Client Certificate  单向认证中也没有这个

第八步 Client Key Exchange

04:90:67:17:d1:ef:4d:3f:55:23:6b:69:f2:bf:9e:be:af:73:a3:e2:d5:3a:28:18:15:2a:5b:8f:62:d3:41:7b:0b:f9:bc:54:d9:32:60:49:01:17:43:31:ff:94:df:a0:d8:61:74:11:ba:a0:8e:54:73:a2:fb:df:1c:43:14:72:dc

第九步  Certificate Verify[单向认证中也没有这个]

第十步  Change Cipher Spec

4.4 服务器的最后回应

服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的"会话密钥"。然后，向客户端最后发送下面信息。

(1）编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。

（2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。

第十一步   Change Cipher Spec