服务端做的事情是一样的，不过它使用“server_write_key”这个密钥。我们看到它的响应消息，包括泄露秘密的应用数据头。
这个消息解密后得到：
HTTP/1.1 200 OK Date: Wed, 10 Jun 2009 01:09:30 GMT Server: Server ... Cneonction: close Transfer-Encoding: chunked
这是一个普通的HTTP返回消息，它包含一个非描述性“Server: Server”HTTP头和一个来自Amazon负载均衡器的“Cneonction: close”头，显然拼写有误。
TLS就在应用层之下。HTTP服务器上的软件可以就像发送非加密数据一样工作，而唯一的区别是它们（指软件）将数据写到一个库，由这个库统一做加密。OpenSSL是TLS的一个非常流行的开源库。
在双方发送和接受加密数据的过程中，链接一直保持活动状态，直到任何一端发出一条“closure alert”消息并接着关闭连接。如果在断开后的很短时间内重连，则可以重用前面协商好的密钥（前提是服务器还缓存着他们），这样就不需要公钥操作，否则，就需要重新执行一次完全的握手过程。
应用数据消息可以是任何信息，这点很重要。“HTTPS”特别的唯一原因是因为Web太流行了，还有其他基于TCP/IP的协议运行在TLS之上。例如，TLS也用于FTPS和SMTP的安全扩展。使用TLS肯定比你自己发明解决方案要好，另外，使用经得起仔细的安全分析的协议，你能从中获益。
……顺利完工！
TLS RFC中还包含很多我们这里遗漏的内容，它是一份可读性非常好的规范。我们覆盖的内容是对Firefox和Amazon之间的220毫秒的舞蹈进行观察所看到的一条路径。这个过程很大程度 上受Amazon在ServerHello消息中所选择的TLS_RSA_WITH_RC4_128_MD5密码套件的影响，这是一个合理的选择，因为它对速度的倾向比对安全的倾向更多一点。
如我们所看到的，如果有人能将Amazon的模数“n”分解成“p”,“q”，那么他就可以有效解密所有的“安全”流通，直到Amazon换掉它的证书。所以Amazon通过每年替换一次证书的方式来平衡这方面的担心。
其中有一个密码套件是“TLS_DHE_RSA_WITH_AES_256_CBC_SHA”，它使用Diffie-Hellman密钥交换算法，这个算法具有良好的 “正向安全”的特点。也就意味这如果某人破解了密码交换的数学原理，对于解密下一个会话也没有什么益处。这个算法的缺点是需要计算更大的数字，所以对于一个很忙的服务器来说计算成本更大。“高级加密标准”（AES）出现在我们提供的很多密码套件中。它与RC4 的不同在于它一次加密16字节的“数据块”而不是一个字节，由于它的密钥可以大到256比特，所以很多人认为它比RC4要更安全。
仅需220毫秒中，网络中两个端点连接到一起，提供了足够资料来信任对方，建立加密算法，并开始进行加密的信息传输。
我写了一个程序对文章中所提及的握手协议走了一遍。
查看英文原文：The First Few Milliseconds of an HTTPS Connection。
http://www.infoq.com/articles/HTTPS-Connection-Jeff-Mose
详细DOC文档下载: http://forum.chinesehonker.org/thread-6096-1-1.html
