我们在这个结果的前面加上一个记录头字节“0x14”指明“完成”和长度字节“00 00 0c”指明我们将发送12字节的“verify data”。然后，像所有接下来的加密消息一样， 我们要确保解密后的内容没有被篡改。因为选择使用的密码套件是TLS_RSA_WITH_RC4_128_MD5，所以我们将使用MD5哈希函数。
有些人一听到MD5就感到恐慌，因为它存在一些弱点，我原先也很不提倡使用它。然而，TLS很聪明，他并不直接使用MD5，而使用它的HMAC版本。TLS是这样使用MDB进行计算的：
HMAC_MD5(Key, m) = MD5((Key ⊕ opad) ++ MD5((Key ⊕ ipad) ++ m)
（⊕指的是异或（XOR），++指的是拼接，“opad”是一串“5c 5c ... 5c”字节，“ipad”是另一串“36 36 ... 36”）。
这里我们对以下内容进行计算：
HMAC_MD5(client_write_MAC_secret, seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length + TLSCompressed.fragment));
也许你已经看到，我们加入了一个序列号（“seq_num”）和明文消息（这里被称为TLSCompressed）的一些其他属性。序列号可以迷惑 攻击者，他可能会在中途把一个先前加密的消息插入。如果他这么干，则序列号一定和我们所期待的不一样，这就保护了我们不受攻击者们扔消息的攻击。
剩下就是加密消息了。
RC4加密算法
从前文已知双方协商的密码套件是TLS_RSA_WITH_RC4_128_MD5。这就意味着我们将使用Ron's Code #4 (RC4)对传输信息进行加密。Ron Rivest开发了基于256字节的密钥生成随机数的RC4加密算法。这个算法非常简单，以至于几分钟内你就可以记住它。
RC4从创建一个256字节的数组“S”开始，并从0到255对其进行填充。然后从“S”的第0位开始循环，将“S”和密钥中的字节进行混合，这样做是为了创建用于产生“随机”数的状态机。为了生成随机数，我们将“S”数组进行洗牌（译注：参考百度百科RC4）
图形化描述是这样的：
对一个字节进行加密，我们对伪随机字节和要加密的字节进行异或运算。记住将一个比特和1进行异或的话是使这个比特反转（译注：0^1=1, 1^1=0）。因为前面产生的是随机数，所以大约会有一半的比特码会被反转，这种随机的比特反转在加密数据时非常有效。你已经看到，这并不复杂，而且运行起来很快。我想这也许就是Amazon用它的原因吧。
回想一下，我们有“client_write_key”和“server_write_key”。这意味这我们需要创建两个RC4实例，一个用于加密浏览器发送的消息，另一个用于解密服务器返回的消息。.
“client_write”最前面的随机字节是“E 20 7A 4D FE FB 78 A7 33 ...”，如果我们用这些字节和未加密的消息头（经查证，该消息的字节为“4 00 00 0C 98 F0 AE CB C4 ...”）进行异或运算的话，我们将得到在Wireshark中看到的已加密的部分：
服务器做的事情几乎一样。它发出一条“Change Cipher Spec”消息，然后发出的“Finished Message”消息，这条消息包括所有的“握手”消息，以及解密的客户端发过来的“Finished Message”，这也向客户端表明了服务端可以正确解密客户端发过来的消息。
欢迎回到应用层！
现在，220毫秒过去了，我们最终为应用层准备好了，现在我们可以发送通过TLS层使用RC4的写实例加密过的普通HTTP消息，也可以解密服务端RC4写实例发过来的消息。此外，TLS层还会通过计算消息内容的HMAC_MD5哈希值来校验每一条消息是否被篡改。
至此，“握手”过程已经完成，现在TLS记录的content type变成23（0x17）。加密的数据流以“17 03 01”开始，这几个字节表明了记录类型和TLS版本，后面是包含了HMAC哈希的加密数据。
对如下明文的加密：
GET /gp/cart/view.html/ref=pd_luc_mri HTTP/1.1 Host: www.amazon.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.10) Gecko/2009060911 Minefield/3.0.10 (.NET CLR 3.5.30729) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive ...
将得到下面这些字节：
剩下的唯一有趣的事是每个消息的序列号是依次递增的，现在是1（下一个消息将会是2，以此类推）。
