参考

The First Few Milliseconds of an HTTPS Connection

SSL/TLS in Detail

Transport Layer Security (TLS) and Secure Sockets Layer (SSL) 

测试环境:
server: https://www.google.com.hk
client: ie/win7

wireshark 1.10.1 表达式:
tcp.port==443 && ip.addr=172.194.127.19 && ssl

1, Client –> Server: 握手[ Client Hello ]

主要功能 （1）提供一个随机数random （2）提供一组加密套餐共服务器选择，本例共有21个套餐

2, Server –> Client: 握手[ Server Hello ]

（1）提供一个随机数 （2）选择一个安全组件套餐，本例google选择了TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 参考： 
迪菲－赫尔曼密钥交换

建立安全连接需要一组安全组件，所以用套餐来命名比较合适：

[Key Exchange]_[Authentication]_WITH_[Data Transfer Cipher]_[MAC Digest]

Key Exchange: 密钥交换算法，就是协商对称加密传输应用数据时候的公钥应该用什么方法，常见的有rsa和diff-helliman Authentication：认证算法 Data Transfer Cipher：对称加密算法 Mac Digest：消息摘要算法

3, Server –> Client: 握手[ Certificate ] （可选）

提供服务器的身份证书给客户端鉴定，如果不用公钥证书体系验证身份和交换密钥，改步骤可选，比如在用DH方法交换的时候。

4, Server –> Client: 握手 [ Server Key Exchange ] （可选）

密钥交换用到的服务器方的信息，一般是补充 上次的 [Certificate]指令的信息，一般是给client一个公钥或者临时公钥，用于client来传输premaster key。

如果上一步已经提供了足够的信息，或者根本不用rsa方法来交换的话，这个步骤可以省略。

5, Server –> Client: 握手 [Server Hello Done]

结束服务器端的握手过程

参考：
makecert 制作数字证书

6, Client –> Server: 握手[ Client Key Exchange ]

client偷偷生成一个秘密数字premaster key, 然后加密发给服务器，供服务器生成masterkey，同时客户端这边也开始用这个premasterkey来生成masterkey，服务器和客户端生成的masterkey肯定（必须的）是一样的。

7, Client –> Server: 密钥交换 [Change Cipher Spec]

通知服务器，接下来传输的所有信息都是用masterkey加密的，你server赶紧切换到对称加解密模式吧。

8, Client –> Server: 握手 [Encrypted Handshake Message]

真的哦，client紧跟着上个通知消息，立刻发送了一个加密的消息给服务器，服务器应该能够解开，并且验证消息的合法性。

这个加密的消息解密以后是有固定格式的，符合这个格式，或则满足一些字符匹配，才是合法的。

[cpp]
view plain
copy
print
?

1. 7.4.9. Finished  
2.   
3.    When this message will be sent:  
4.        A finished message is always sent immediately after a change  
5.        cipher spec message to verify that the key exchange and  
6.        authentication processes were successful. It is essential that a  
7.        change cipher spec message be received between the other  
8.        handshake messages and the Finished message.  
9.   
10.    Meaning of this message:  
11.        The finished message is the first protected with the just-  
12.        negotiated algorithms, keys, and secrets. Recipients of finished  
13.        messages must verify that the contents are correct.  Once a side  
14.        has sent its Finished message and received and validated the  
15.        Finished message from its peer, it may begin to send and receive  
16.        application data over the connection.  
17.   
18.        struct {  
19.            opaque verify_data[12];  
20.        } Finished;  
21.   
22.        verify_data  
23.            PRF(master_secret, finished_label, MD5(handshake_messages) +  
24.            SHA-1(handshake_messages)) [0..11];  
25.   
26.        finished_label  
27.            For Finished messages sent by the client, the string “client  
28.            finished”. For Finished messages sent by the server, the  
29.            string “server finished”.  
30.   
31.        handshake_messages  
32.            All of the data from all handshake messages up to but not  
33.            including this message. This is only data visible at the  
34.            handshake layer and does not include record layer headers.  

7.4.9. Finished

   When this message will be sent:
       A finished message is always sent immediately after a change
       cipher spec message to verify that the key exchange and
       authentication processes were successful. It is essential that a
       change cipher spec message be received between the other
       handshake messages and the Finished message.

   Meaning of this message:
       The finished message is the first protected with the just-
       negotiated algorithms, keys, and secrets. Recipients of finished
       messages must verify that the contents are correct.  Once a side
       has sent its Finished message and received and validated the
       Finished message from its peer, it may begin to send and receive
       application data over the connection.

       struct {
           opaque verify_data[12];
       } Finished;

       verify_data
           PRF(master_secret, finished_label, MD5(handshake_messages) +
           SHA-1(handshake_messages)) [0..11];

       finished_label
           For Finished messages sent by the client, the string "client
           finished". For Finished messages sent by the server, the
           string "server finished".

       handshake_messages
           All of the data from all handshake messages up to but not
           including this message. This is only data visible at the
           handshake layer and does not include record layer headers.

9, Server –> Client: 密钥交换[ Change Cipher Spec ]

通知客户端，接下来我服务器发送的消息都是对称加密的，你切换到masterkey通信的模式吧。

10, Server –> Client: 握手 [Encrypted Handshake Message]

同样的，也紧随通知消息其后发送了一个加密消息给客户端验证。客户端理论上应该可以验证服务器的消息合法性。

11, Client –> Server: 应用[ HTTP ]

两个encrypted message过后（Finished in rfc2246），开始业务层的应用通信。

关于证书验证的一些思考：

（1）如果域名解析被污染，证书的验证还有意义吗？ 证书验证的过程，只是检查提供这个公钥的服务器名字是否在CN字段里面，并且这个证书是有效的CA签发的。域名是可以被篡改，但是仿冒的HACK_IP并不能够代替真正的REAL_IP进行一下的密钥交换过程，后续的加密通信也无法继续。

（2）如果使用TLS代理服务器，信息还安全吗？ TLS代理服务器本身需要作为CA，并且临时签发证书给客户端要访问的HTTPSERVER_S，然后出具这个证书给客户端，另外客户端是信任TLS的CA的。你们证书验证过程有效。 好吧，既然你是信任这个代理服务器的，它当然可以解密你的数据，并重新加密发送给真正的HTTPSERVER_S。

（3）go——agent只是重试多个ip获取真正可用的app–spot服务器 app—spot只是域名被污染了，gagent只是重试多组ip，指定特定的xxx.app《敏感词隔断》spot.com去访问，所以其实你指定host文件，有时候是可以访问你的gae的。gagent就是一个本地的tls代理服务器，当你访问某些国外的secure web的时候，前提是你安装并信任它的根证书。所以这个本地的代理服务器可以看见你的所有https加密请求的内容（但是它发出去的到gae的fetch服务的内容应该是加密的）。如果这个代理服务器运行在其他人的其他机器上，你还敢轻易的trust它的跟证书吗？