SSL/TLS协议运行机制的概述
图解SSL/TLS协议
HTTPS背后的加密算法
TLS协议分析 与 现代加密通信协议设计
概述
互联网是一个开放的环境，通信双方都是未知的身份。为了防止在通信时，有第三方可以获取通信的内容，修改通信的内容，或冒充他人进行通信。此时就需要有一个安全协议，可以使得通信内容被加密传输，并且还具有内容校验和身份验证机制。
SSL (Secure Sockets Layer 安全套接层)及其继任者 TLS (Transport Layer Security，传输层安全)就是这样一种安全协议，为网络通信提供基于进程对进程的鉴别，保密和数据完整性的服务。SSL 位于 TCP/IP 协议与各种应用层协议之间，应用层数据不再直接传递给传输层，而是传递给 SSL 层，SSL 层对从应用层收到的数据进行加密，并增加自己的 SSL 头。SSL 协议分为两层，由多个子协议组成，分别是：
- 记录协议：建立在可靠的传输协议（如TCP）之上。
- 握手协议、警报协议、修改密码规范协议：建立在记录协议之上。
基本原理
由于用非对称加密算法加密内容的消耗太大，所以 SSL/TLS 协议的基本原理是通信双方通过非对称加密交换一个对称加密密钥，在交换成功后，所有通信的内容通过对称加密以减少开销。例如，客户端首先向服务端请求其公钥，在拿到服务端返回的公钥后，客户端用这个公钥来加密对称密钥并发送给服务端，因为只有服务端有私钥可以正确解密加密后的对称密钥，所以通过非对称加密来保证了通信双方对称加密密钥的安全交换。而另一个要解决的问题是保证客户端收到的服务端的公钥是可信的，解决方法是采用数字证书。在使用对称密钥加密内容通信前的部分称为握手阶段，发生在握手协议层，而之后的加密通信就是记录协议层的工作了。
握手协议
握手协议建立在记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密和MAC算法、交换加密密钥等。
握手阶段涉及四次通信：
- ClientHello，首先，客户端（通常是浏览器）先向服务器发出加密通信的请求，在这一步，客户端主要向服务器提供以下信息。
- 支持的协议版本，比如TLS 1.0版。
- 一个客户端生成的随机数，稍后用于生成"对话密钥"。
- 支持的加密方法，比如RSA公钥加密。
- 支持的压缩方法。
- SeverHello，服务器收到客户端请求后，向客户端发出回应，服务器的回应包含以下内容。
- 确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器没有一致的支持版本，服务器将关闭加密通信，而此时客户端比如浏览器也会给出错误提示信息。
- 一个服务器生成的随机数，稍后用于生成"对话密钥"。
- 确认使用的加密方法，比如RSA公钥加密。
- 服务器证书。
- 如果服务器需要确认客户端的身份，还需要要求客户端提供"客户端证书"。
- 客户端回应，客户端收到服务器回应以后，首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。如果证书没有问题，客户端就会从证书中取出服务器的公钥。然后，向服务器发送下面三项信息。
- 一个随机数。该随机数用服务器公钥加密，防止被窃听。有了这个随机数以后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把对称"会话密钥"。
- 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
- 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。
- 如果服务器要求客户端证书，客户端会在这一步发送证书及相关信息。
- 服务器回应，服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的"会话密钥"。然后，向客户端最后发送下面信息。
- 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
- 服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。
交换对称密钥时并不是只能使用RSA算法，也可以使用例如 Diffie-Hellman算法（简称DH算法）等。
记录协议
记录协议建立在可靠的传输协议之上，为高层协议提供数据封装、压缩、加密，数据完整性等基本功能的支持。加密通过握手协议定义的对称密钥实现，完整性通过握手协议定义的带密钥的 MAC 算法保证。
操作过程：
- 分段，每个上层应用数据被分成2^14字节或更小的数据块。记录中包含类型、版本号、长度和数据字段。
- 压缩是可选的，并且是无损压缩，压缩后内容长度的增加不能超过1024字节。
- 在压缩数据上计算消息认证MAC。
- 对压缩数据及MAC进行加密。
- 增加SSL记录。
警报协议
客户端和服务器发现错误时，向对方发送一个警报消息。如果是致命错误，则立即关闭 SSL 连接，双方还会先删除相关的会话号，密钥。每个警报消息共2个字节，第1个字节表示错误类型，如果是警报，则值为1，如果是致命错误，则值为2，第2个字节制定实际错误类型。
致命的警报消息有：意外的消息、错误的 MAC、解压缩失败、记录溢出、握手失败、非法参数、未知的 CA、访问拒绝、解码错误、解密错误、协议版本等。
警告类型的消息有：无证书、不支持的证书、吊销的证书、证书过期、未知证书等。
修改密码规范协议
为了保障SSL传输过程的安全性，客户端和服务器双方应该每隔一段时间改变加密规范。SSL 修改密码规范协议是3个高层的特定协议之一，也是其中最简单的一个。在客服端和服务器完成握手协议之后,它需要向对方发送相关消息(该消息只包含一个值为1的单字节)，通知对方随后的数据将用刚刚协商的密码规范算法和关联的密钥处理，并负责协调本方模块按照协商的算法和密钥工作。
会话恢复
握手阶段用来建立SSL连接。如果出于某种原因，对话中断，就需要重新握手。这时有两种方法可以恢复原来的session：一种叫做session ID，另一种叫做session ticket。session ID的思想很简单，就是每一次对话都有一个编号（session ID）。如果对话中断，下次重连的时候，只要客户端给出这个编号，且服务器有这个编号的记录，双方就可以重新使用已有的"对话密钥"，而不必重新生成一把。session ID是目前所有浏览器都支持的方法，但是它的缺点在于session ID往往只保留在一台服务器上。所以，如果客户端的请求发到另一台服务器，就无法恢复对话。session ticket就是为了解决这个问题而诞生的。客户端不再发送session ID，而是发送一个服务器在上一次对话中发送过来的session ticket。这个session ticket是加密的，只有服务器才能解密，其中包括本次会话的主要信息，比如会话密钥和加密方法。当服务器收到session ticket以后，解密后就不必重新生成对话密钥了。
HTTPS
HTTPS 是 SSL/TLS 协议的一个最典型的应用，在应用层的 HTTP 协议和传输层之间加入了安全协议，使得原本明文传输的 HTTP 协议具有了保密，校验，认证的安全功能。在握手成功建立连接后，双方的通信基本上就是 HTTP 通信了，只是通过 SSL/TLS 的记录协议层，将内容用协商好的对称密钥进行了加密。HTTPS 协议的使用是以 https:// 作为协议前缀，默认端口是443。
