SSL协议

最初SSL协议是由netscape开发，并集成到浏览器中，用于保护HTTP传输安全性，作为在传输层和应用层之间的一层，对更多的需要保护数据安全性的协议进行封装。IETF以SSL协议为基础，提出了一种新的协议：TLS，建立在SSL V3 .0 的基础上，是SSL 3 . 0的后续版本，已经开始在实际应用中使用。虽然TLS和SSL不能互操作，仅仅是因为他们使用的加密算法和MAC算法不同，协议本身差别非常细微。RFC-2246是IETF提出的第一个版本，被称作TLS v1 . 0，目前最新的版本是TLS v1 . 2，在RFC-5246中描述了其细节问题。 以下根据RFC5246，介绍SSL 协议由两层构成： TLS Record Protocol 和 TLS Handshake Protocol 。 TLS Record Protocol 处于较低的一层，基于一些可信任的协议，如 TCP ， 为高层协议提供数据封装、压缩、加密等基本功能的支持。 它保证了通信的两个基本安全属性： 1 ． 保密连接 。数据传输使用对称加密算法，如 AES ， RC4 等，该对称加密算法的密钥对于每个连接是唯一的，基于密钥协商协议生成，比如 TLS handshake protocol ， Record Protocol 也可以不使用加密。 2 ． 可信连接 。消息的传输包括了基于密钥的消息认证码（ keyed MAC ），使用安全 Hash 函数计算 MAC ，用于完整性检查。 Record Protocol 也可以不使用 MAC ，但是这种模式只用于安全参数协商时。 Record Protocol 用于封装多种高层的协议，其中一个种就是 TLS handshake protocol ，这种协议允许客户与服务器相互认证，在应用程序通信前，协商加密算法和加密密钥。 TLS handshake protocol 保证了连接的三个基本安全属性： 1 ． 两端的身份可以通过非对称或者公钥加密算法（ DSA ， RSA 等）进行认证 。认证过程是可选的，但至少要求一端被认证。 2 ． 共享密钥的协商是安全的 。密钥协商对于监听者和任何被认证的连接都是不可见的。 3 ． 协商是可信的 。攻击者无法修改协商信息。 TLS协议提供的服务主要有 ： 1）认证用户和服务器，确保数据发送到正确的客户机和服务器； 2）加密数据以防止数据中途被攻击者监听； 3）维护数据的完整性，确保数据在传输过程中不被攻击者篡改。 TLS协议在协议栈中如下图所示： TLS协议对数据的封装如下图所示：   为了便于更好的认识和理解 SSL 协议，这里着重介绍 SSL 协议的握手协议 ， mail.qq.com 支持 SSL 协议，以下结合实例，介绍 SSL 握手协议 。 数据包使用 Wireshark 抓取。 SSL 协议既用到了公钥加密技术又用到了对称加密技术，对称加密技术 使用于 Record 层，用于对传输的数据进行加密， 公钥加密技术 使用于 Handshake 协议， 提供了身份认证 的功能 。SSL 的握手协议非常有效的让客户和服务器之间完成相互之间的身份认证， 本实例中只有客户端验证服务端，服务端并没有对客户端进行验证，一般相互进行身份认证的情况在登录银行系统时会用到。下面根据抓取到的数据包，讲解浏览器访问 mail.qq.com 时使用 SSL 协议的过程 ：   ①客户端的浏览器向服务器 提出 TCP 连接请求，建立起 TCP 连接后，客户端向服务端发送 Client Hello 消息， 传送客户端 SSL 协议的版本号，加密算法的种类 ，以及其他服务器和客户端之间通讯所需要的各种信息。 Client Hello 消息的内容如下图所示： Cipher Specs 字段是一个枚举类型，说明了客户端所支持算法， 每个 Cipher Spec 指定了一个加密组合，从下图可以看出， SSL 与 TLS 的很显著的区别就是， TLS 支持了更多更先进更安全的加密组合， 如下图所示： ②服务 端收到建立 SSL 连接的请求后， 向客户端传送 SSL 协议的版本号，加密算法的种类，随机数以及其他相关信息，同时服务器还将向客户端传送自己的证书。 如下图所示： Random 是服务端产生的随机数，根据一个随机种子生成，这里的随机种子是 gmt_unix_time ，根据这个时间，使用伪随机数函数（ PRF ）生成一个 32 字节的 random_bytes 。 Session ID 是 一组任意字节数的序列，由 server 选出，用于识别连接是活动状态还是可恢复状态。 Cipher Suite 指定了服务端选定的加密组合，这里选出的加密组合是 TLS_RSA_WITH_AES_256_CBC_SHA ， RSA 作为认证算法， 256 位的 AES 分组加密算法作为 Record 层加密 payload 使用的算法， SHA 作为消息认证码算法，用于保证消息的完整性，防止消息被篡改。 Compress Method 表明了使用的压缩算法， Record 层接收高层协议的数据时，会将数据进行分片，前面已经提到过，对于每个分片可以选择使用一定压缩算法来提高加密和传输效率，这里没有使用压缩算法，所以是 null 。 接着，服务端返回了证书 ，证书使用 x.509 格式 ，供客户端验证其身份， 同时发送一个 Server Hello Done 消息。 如下图所示： ③ 客 户利用服务器传过来的信息验证服务器的合法性，服务器的合法性包括：证书是否过期，发行服务器证书的 CA 是否可靠，发行者证书的公钥能否正确解开服务器证书的“发行者的数字签名”，服务器证书上的域名是否和服务器的实际域名相匹配。如果合法性验证没有通过， 通讯将断开；如果合法性验证通过，将继续进行第四步。 ④用户端随机产生一个用于后面通讯的 密钥 ，然后用服务器的公钥（服务器的公钥从步骤②中的服务器的证书中获得）对其加密，然后将加密后的“ 预主密钥 ”传给服务器 （ Client key exchange ） 。 该过程内容如下图所示： 由于预主密钥的传输使用 RSA 进行了加密，所以无法在抓取的数据包中显示出来 （在上图中的 Encrypted Handshake Message ） ，从而保证了握手过程的保密性。 ⑤ 如果服务 端 要求客户的身份认证（在握手过程中为可选 ，本例中没有该步骤 ），用户可以建立一个随机数然后对其进行数据签名，将这个含有签名的随机数和客户自己的证书以及加密过的预主密码 （ Premaster secret ） 一起传给服务 端 。 ⑥ 如果服务 端 要求客户的身份认证，服务 端 必须检验客户证书和签名随机数的合法性，具体的合法性验证过程包括：客户的证书使用日期是否有效，为客户提供证书的CA 是否可靠，发行CA 的公钥能否正确解开客户证书的发行 CA 的数字签名，检查客户的证书是否在证书废止列表（CRL ）中。检验如果没有通过，通讯立刻中断；如果验证通过，服务 端 将用自己的私钥解开加密的预主密码，然后执行一系列步骤来产生主 密钥（ Master secret ） （客户端也将通过同样的方法产生相同的主通讯密码）。 如果服务端没有进行步骤 5 ，服务端端收到客户端发送的使用服务端公钥加密的预主密钥，用私钥解开加密的预主密钥， 执行一系列函数，生成会话的主密钥，客户端也进行相同的操作生成主密钥。 ⑦服务器和客户端 拥有了 相同的主 密钥 ， 双方使用之前协商的 对称 加密算法，并使用主密钥作为 密钥 ， 用于 SSL 协议的安全数据通讯的加解密通讯。同时在 SSL 通讯过程中还要 维护数据通信 的完整性，防止数据通讯中的任何变化 ，通过消息认证码来保证 。 ⑧客户端向服务器端发出信息 （ Change cipher spec ） ，指明后面的数据通讯将使用的步骤⑦中的主密码为对称密钥，同时通知服务器客户端的握手过程结束。 ⑨服务器向客户端发出信息 （ Change Cipher Spec ） ，指明后面的数据通讯将使用的步骤⑦中的主密码为对称密钥，同时通知客户端服务器端的握手过程结束。 ⑩SSL 的握手部分结束，SSL 安全通道的数据通讯开始，客户和服务器开始使用相同的对称密钥进行数据通讯，同时进行通讯完整性的检验。 该过程的数据包如下图所示： 从此过程开始， TLS Record 层使用 Application Data Protocol 通信，其 Content-type 字段变为 HTTP ，这个字段记录了上层协议的协议类型，以便数据提交到对方的 TLS Record 层后，对数据进行组装，并交付给上层协议处理。