一、SSL/TLS简介

SSL（Secure Socket Layer）最初是由Netscape公司开发的一个协议，其目的在于为互联网提供一个安全的通信机制。Netscape最早对外公布的版本是SSL2.0，但是由于SSL2.0有一些安全方面的缺陷，所以后来又重新设计了SSL3.0。SSL后来被IETF（Ineternet Engineering Task Force）所采纳并重新命名为TLS（Transport Layer Security），也就是说，TLS其实是SSL的后续版本。TLS1.0是SSL3.0的一个升级版本，后续的小版本还有TLS1.1和TLS1.2。现在普遍使用的是SSL3.0或者TLS1.0。

SSL/TLS协议是位于应用层和传输层（如TCP）之间的，它和具体的应用层协议无关，也就是说，任何应用层协议都可以使用SSL/TLS来获得安全通信的能力，如HTTP/FTP/SMTP等。

二、SSL/TLS基本原理

我们知道，互联网本身是一个公共的、不安全的网络。数据在互联网上传输时，无法避免会被恶意的第三方监视、偷听、截获甚至篡改，更有甚者，正在和我们通信的对方有可能根本就是假冒的，比如钓鱼网站等。既然SSL/TLS要为互联网提供一个安全通信的机制，那么它必须解决这里所有提到的安全问题，具体说，SSL/TLS通过下面三个方面来为互联网通信提供安全保证。

1. 机密性保证

SSL/TLS对要传输的数据进行加密，这样在互联网的传输数据就是加密后的密文，即使被恶意的第三方监视和偷听，由于没有解密秘钥，所以无法理解密文的意思。这也称为SSL/TSL的防偷听机制。

加密分为对称加密和非对称加密。对称加密（AES/RC4/3DES）的优点是效率高，然而对称加密使用的加密解密秘钥是一样的，这意味着加密方（即发送方）必须把秘钥发送给接收方，显然，在传输秘钥的过程中，如果不加以保护，秘钥就会被泄露。非对称加密（RSA/ECC）则克服了对称加密需要传输秘钥的弱点，但是非对称加密的效率很低，如果传输的数据量很大，那么使用非对称加密将是十分耗时的。也就是说，无论是对称加密还是非对称加密，都不能很好地满足数据加密传输的要求，为此，SSL/TLS对这两种方法取长补短，综合应用。SSL/TLS利用非对称加密来交换秘钥信息（秘钥信息并不是秘钥，而是生成秘钥时所需要用到的信息），由于秘钥信息的数据量很少，使用非对称加密还是可以接受的。而对于要传输的数据，SSL/TLS则使用对称加密，其秘钥由前面使用非对称加密传输得到的秘钥信息生成。由于秘钥信息是使用非对称加密的，所以其在传输过程中是安全的（恶意的第三方没有私钥无法进行解密）。

2. 消息完整性保证

由于恶意的第三方能够截获传输中的数据并把数据篡改后再发给接收方，所以SSL/TLS还必须提供一种方法来检测数据是否被篡改过。这也称为SSL/TLS的防篡改机制。具体地说，SSL/TLS使用MAC（消息验证码）来实现防篡改，即在发送消息之前，把该消息和一个通信双方共享的秘钥作为一个hash算法（MD5/SHA1）的输入，再把由此求得的摘要值联通消息一起发送给对方。

3. 身份真实性保证

SSL/TLS通过验证身份来确保不会和假冒的对方通信。这也称为SSL/TLS的防假冒机制。SSL/TLS使用由私钥签名的数字证书来实现防假冒。一般来说，服务器需要把它的数字证书传给客户端来验证，而客户端不一定需要提供证书。

三、SSL/TLS的握手过程

在开始传输应用程序数据之前，通信的双方必须先进行SSL/TLS握手。在握手的过程，双方交换并协商重要的信息，包括将要使用的SSL/TLS协议版本、加密算法、MAC算法、验证算法，以及用于各种算法的秘钥等。当然，任一方都可以在握手的过程中来验证对方的真伪，一旦验证失败，握手过程将被终止，同时这个SSL/TLS连接也会被终止。具体说，SSL/TLS的握手过程可以分为三个阶段：参数协商、身份验证，以及秘钥交换。

1. 参数协商

在这个阶段，客户端和服务器确定一个双方都能支持的最高版本的SSL/TLS协议，同时确定它们所使用的算法组合（Cipher Suite）。算法组合是分别用于不同目的的三个算法的组合，包含用于交换秘钥（Key Exchange）和身份验证的算法，用于加密应用程序数据的对称加密算法，以及用于消息验证的MAC算法。在SSL/TLS中，一个算法组合可以用一个字符串来表示，如“TLS_RSA_WHIT_RC4_128_MD5”，这个算法组合表示使用RSA来交换秘钥和验证身份，使用RC4来加密应用程序数据，以及使用MD5来验证消息内容（即防篡改）。另外，在这个阶段中，客户端和服务器会分别产生一个随机数，然后把其传给对方，它们将会在后面的秘钥交换阶段中用到。

2. 身份验证

如果在参数协商阶段时所确定的算法组合要求进行身份验证（如RSA），则服务器需要提供信息（服务器证书）来让客户端对齐进行身份验证。反过来，服务器也可以要求客户端提供证书，以便服务器也能够验证客户端的身份，不过这并不是必须的。是否需要验证客户端主要是根据应用程序的要求。

3. 密钥交换

在身份验证通过以后，就可以进入密钥交换阶段。注意，在这个阶段，客户端和服务器并不是直接交换秘钥，而是交换生成秘钥所需要用的信息，这个信息被称为Pre-Master Secret，其实就是一个有客户端产生的随机数。如果在参数协商阶段时所确定的算法组合指明使用RSA来交换秘钥，那么客户端将使用服务器的公钥（包含在服务器的数字证书中）来加密这个Pre-Master Secret，然后再传给服务器，由于只有服务器才有私钥来进行解密，所以Pre-Master Secret的传输是安全的。有了Pre-Master Secret之后，客户端和服务器还需要再计算一个Master Secret，这是因为最终的秘钥都是基于Master Secret而生成的。Master Secret本身则是通过对三个随机数进行计算而得到的，除了Pre-Master Secret之外，另外两个随机数则是在参数协商阶段交换的客户端随机数和服务器随机数。

最终生成的秘钥一共有4个，分别是：

客户端MAC写入秘钥。客户端使用这个秘钥来计算将要发送的消息的摘要，服务器使用该秘钥来验证客户端发过了的消息，也即实现防篡改。
服务器MAC写入秘钥。服务器使用这个秘钥来计算将要发送的消息的摘要，客户端使用该秘钥来验证服务器发过来的消息。
客户端写入秘钥。客户端使用这个秘钥来加密将要发送的应用程序数据，服务器使用它来对收到的密文进行解密。
服务器写入秘钥。服务器使用这个秘钥来加密将要发送的应用程序数据，客户端使用它来对收到的密文进行解密。

下面结合对www.sogou.com的抓包，具体看着三个阶段中的各个步骤：

总览：

客户端发送一个ClientHello消息给服务器，该消息包含客户端所能支持的SSL/TLS最高版本，以及一个支持的算法组合列表，当然，还有客户端生成的随机数。
服务器给客户端发送一个ServerHello消息，该消息包含服务器所选择的SSL/TLS版本号以及算法组合，同时还有服务器产生的随机数
如果在步骤2中所选择的算法组合包含RSA，则服务器向客户端发送它的数字证书，客户端将会验证服务器的身份。
服务器向客户端发送ServerHelloDone消息，表示服务器完成协商阶段的工作。
客户端产生一个随机的Pre-Master Secret，然后想服务器发送一个ClientKeyExchange消息，该消息包含使用服务器公钥加密的Pre-Master Secret
客户端和服务器各自使用Pre-Master Secret，步骤1中产生的客户端随机数，以及步骤2中产生的服务器随机数来计算一个Master Secret。有了Master Secret之后，客户端和服务器就可以使用Master Secret来计算后面所有需要用到的秘钥。
客户端发送一个ChangeCipherSpec通知给服务器，表明客户端将要开始使用刚才生成的秘钥来加密和验证数据。最后，客户端发送一个ClientFinish消息。
服务器收到了客户端的ChangeCipherSpec通知之后，也会对客户端发送ChangeCipherSpec通知，最后，服务器发送一个ClientFinish消息。