TLS/SSL如何保证HTTPS协议的安全

TLS/SSL如何保证HTTPS协议的安全

概述

1999年6月，万维网协会(W3C)和互联网工程任务组（IETF）共同发布了RFC2616，这份标准规范化了接下来20年里十分重要的一个协议–HTTP。HTTP协议是一个客户端和服务端之间进行请求和应答的标准，能够让客户端使用标准的方式从服务器内获取各种资源，如HTML，数字图像等等。

虽然HTTP得到了广泛的使用，但是HTTP的安全行性难以得到保证。攻击者可以通过监听和中间人攻击等手段获取网站账户和敏感信息。为了解决这一问题，1994年网景公司首次提出了HTTPS协议，该协议可在使用适当的加密包以及服务器证书可被验证和信任时，对窃听和中间人攻击提供合理的防护。

HTTPS协议的原理是在HTTP与传输层（如TCP）之间建立一条可靠安全套接层(SSL)。该层的主要任务是提供私密性和身份认证。后来IETF在SSLv3的基础上做了一定的修改，形成了TLS，即安全传输协议。安全的传输协议建立在密文传输的基础上，下面从加密和及身份认证技术两个方面来叙述TLS/SSL为HTTP提供的防护措施。

加密和身份认证

对称加密和非对称加密

从密钥划分的角度上来说，加密分为对称加密和非对称加密两种。非对称加密的加密和解密采用的是同一串密钥，用户使用同一个私钥可以同时加密和解密明文和密文，常见的对称加密算法有AES和DES等等。与之不同的非对称加密的

密钥分为公钥和私钥两种，使用公钥加密的密文只有使用私钥才能解密，反之亦然。常见的非对称加密算法有RSA等等。

相对非对称加密来说，对称加密的效率要高得多，但是由于难以对密钥进行分发和管理，因此对称加密的安全性更低。而非对称加密恰恰相反，发布者只需发布公钥，别人即可使用公钥加密明文并将密文发送给发布者，发布者可以用私钥对密文进行解密。整个流程中私钥完全不会泄露，这也体现了非对称加密更高的安全性。但是非对称加密的加解密的时间长，速度慢，只适合加解密少量数据。

TLS/SSL协议结合了这两者的优点：使用对称加密来加解密实际数据，而使用非堆成加密来加密对称密钥。这样既能保证加解密的速度，又能解决密钥的分发问题。

身份认证和数字证书

上述非对称加密的公私钥体系虽然能保证信息的私密性，但是无法做到身份认证。考虑这样一种情况：存在一个第三者发送了假的公钥给客户端，然后用这个假公钥对应的私钥给客户端发送信息以欺骗客户端。此时的客户端完全不知道与自己通信的服务端是假冒的。这个场景下的关键问题是，服务器如何证明自己的身份，数字证书的存在解决了这一问题。

所谓的数字证书，就是首先要确立一个足够信任的第三方C，C使用自己的私钥对服务器S提供的公钥做加密，然后服务器再将加密后的公钥发送给客户端，客户端使用C提供的公钥对加密后的服务器公钥做解密，如果能正常解密就说明第三方C证明了服务器S的身份，这样就解决了服务器的身份认证问题。该过程的流程图如图所示：

image

在实际的数字证书体系中，这个受信的第三方被称之为证书授权中心（CA），服务器交给CA进行加密的除了自己的公钥外还包括一些其它的如组织名字，有效期等等其它用于身份证明的信息，加密后的相关数据被赋予了一个新的名字—数字证书。SSL/TLS中采用了数字证书的方法对服务器或客户端做身份验证。

接下来将详细叙述SSL/TLS如何利用加密技术和数字证书技术来提供安全的信道。

SSL/TLS****安全传输层的建立

客户端和服务端之间安全信道的建立分为四个阶段，如下图所示。下面将对这四个结算分别进行介绍。

image

阶段一

在CS(客户端-服务端)模式下，首先发起通宵的一般都是客户端，因此提出建立SSL连接的也是客户端。客户端（通常是浏览器）首先向服务器发送一个需要进行加密通信的请求，该信息被称之为ClientHello。在该步骤中，客户端主要向服务端提供如下的信息:

  1. 客户端支持的SSL/TLS协议版本；

  2. 支持加密套件。所谓的加密套件，就是一套流程中会使用到的加密算法，如RSA等等。客户端会向服务器发送自己所知道的所有加密套件，但是最终采用哪一种完全取决与服务器的选择；

  3. 一个由客户端生成的随机数，该数字会用于后面的密钥生成。

阶段二

阶段二的主要行为是服务器应答。服务器在收到客户端的问候消息后会对其提供的协议版本，支持的加密算法等信息做检查，如果服务器接受所有条件，则会向客户端发送SeverHello消息，以及如下的内容：

  1. 本次会话中要使用的协议版本。服务器会从客户端提供的协议版本选择一个接下来使用的具体版本信息，用于本次会话的协议规范；

  2. 从客户端提供的加密套件中选择一个接下来要使用的加密套件；

  3. 服务器证书。服务器会将事先从CA中申请的证书发送给客户端，关于证书的原理详见2.2节，这里不再赘述。

  4. 一个由服务器生成的随机数，该随机数同样会被用来生成密钥。

至此，客户端和服务端已经约定了如下信息：本次会话使用的协议版本、接下来要使用的加密算法、以及由双方生成的随机数。

阶段三

客户端在收到服务端发送的回应后，会首先使用CA提供的凭据验证其证书，如果证书不是由可信机构颁发，或者证书中出现其包含的服务器信息与实际的信息不一致等问题，客户端就会认为该服务器不可信进而给用户发出警告或直接中断通信。如果证书没有出现问题客户端则会向服务器发送如下信息：

  1. 由服务器的公钥加密的pre master key。该值的生成方式以及内容由具体的加密套件而定，如果采用的是RSA加密，那么该值则为客户端生成的一个随机数。双方会使用该pre master key以及之前产生的两个随机数共同生成消息传输过程中使用的对称密钥，该密钥用于后面所有实际内容的对称加密；

  2. 消息改变通知，该通知的含义是告知服务器接下来的所有消息都用约定好的加密套件和密钥进行加密传输。

  3. 客户端结束握手的消息，该消息会包含之前发的所有消息的哈希值，用于交给服务器进行校验。

阶段四

服务端在收到客户端发送的pre master key后也会使用与客户端相同的方法计算本次会话使用的对称密钥，接着向客户端发送如下消息以结束信道的建立工作：

  1. 消息改变通知，表示随后的信息都将使用双方使约定的加密算法加密后再发送；

  2. 服务端的结束握手消息，和客户端一样，该通知也包含之前所有消息的哈希值，用于交给客户端进行校验。

至此，双方就在HTTP协议之下建立起了一个可以安全通信的信道，将不安全的HTTP封装成为了相对安全的HTTPS。

局限性

安全性总是相对的。TLS/SSL所能提供的保护也受到浏览器的实现以及服务端软件所支持的加密算法等因素的影响。