https协议简介

󰃭 2018-01-02

https简介

一、作用

我们都知道http协议是明文传输的，在网络安全日益重要的今天，明文传输会带来风险。 主要体现在以下三方面：

  • 窃听风险：第三方可以获知通信内容
  • 篡改风险：第三方可以修改通信内容
  • 冒充风险：第三方可以冒充他人身份参与通信

SSL/TLS协议便是为了解决这三大风险而设计的，而HTTPS的安全基础是SSL/TLS协议。简单来讲是 在HTTP下加入SSL/TLS层来保证通讯的安全的。

接下来会简要介绍SSL/TLS协议的历史和运行机制，希望这篇文章能让你对SSL/TLS到底做了哪些事 有个基本的概念。

二、历史

互联网加密通信协议的历史，几乎与互联网一样长。

  • 1994年，NetScape公司设计了SSL协议（Secure Sockets Layer）的1.0版，但是未发布。
  • 1995年，NetScape公司发布SSL 2.0版，很快发现有严重漏洞。
  • 1996年，SSL 3.0版问世，得到大规模应用。
  • 1999年，互联网标准化组织ISOC接替NetScape公司，发布了SSL的升级版TLS 1.0版。
  • 2006年和2008年，TLS进行了两次升级，分别为TLS 1.1版和TLS 1.2版。最新的变动是2011年 TLS 1.2的修订版。

目前，应用最广泛的是TLS 1.0，接下来是SSL 3.0。但是，主流浏览器都已经实现了TLS 1.2的支 持。TLS 1.0通常被标示为SSL 3.1，TLS 1.1为SSL 3.2，TLS 1.2为SSL 3.3。通常没有特别说 明时，SSL 和 TLS 指的是同一个协议，本文也不做严格区分。

三、SSL/TLS如何加密？

这一节我们将了解SSL/TLS是如何加密的，因此会忽略其它方面，现在我们只关心和加密有关的过 程。为了了解加密过程，我们需要先了解公开密钥加密和对称密钥加密

3.1 什么是公开密钥加密

这里引用一下维基百科的解释：

公开密钥加密（英语：Public-key cryptography），也称为非对称加密（英语：asymmetric cryptography），是密码学的一种算法，它需要两个密钥，一个是公开密钥，另一个是私有密钥； 一个用作加密的时候，另一个则用作解密。使用其中一个密钥把明文加密后所得的密文，只能用相对 应的另一个密钥才能解密得到原本的明文；甚至连最初用来加密的密钥也不能用作解密。

对上面的解释，我们可以做一个简单的类比来方便理解。把公钥和私钥分别比作锁和钥匙, 公钥只用 来加密数据，而私钥只用来解密数据。在明白了公开密钥加密的工作模式后，我们可以联想一下， 如何用其进行加密。下面是我简单设想的加密过程:

我们简单了解一下过程

  1. 客户端生成一对临时的公钥和私钥，并把公钥传给服务器
  2. 服务器收到客户端传过来的公钥，在响应客户端的同时（表示自己已经收到公钥了），发送服 务器自己的公钥
  3. 客户端发送应答，表示已经收到服务器的公钥了
  4. 接下来，双方便可以开始通信了。客户端会在发送数据前，用服务器的公钥加密，服务器收到数 据后用服务器的私钥解密，服务器如果需要发送数据也是一样的过程

表面来看，这个加密过程是没有问题的。但是公开密钥加密有个缺点便是需要非常庞大的计算量才能 加密解密数据，即使是多核心cpu也是负担不了这么庞大的计算量的。所以上面的流程是没法投 入实际使用的。那该怎么办呢？接下来就让我们看看https是如何解决这个问题的吧

3.2 什么是对称密钥加密

简单来说，对称密钥加密是一类算法。这类算法在加密和解密时使用相同的密钥,并且加密和解密的 速度比公开密钥加密快很多。从上面设想的流程中，我们可以发现，公开密钥加密只能够保证一个方 向数据的安全。那么只需要客户端生成一个对称密钥，然后通过公钥加密对称密钥发送给服务器，双 方接下来便可以通过对称密钥来加密数据了。这样既保证了安全性，又保证了性能。总结为一段话便是：

通过公开密钥加密的单向安全性，来加密随机生成的对称密钥。再通过对称密钥加密通信数据

SSL/TLS具体加密流程其实都是为了达成上面这个目的而设计的，所以请仔细思考一下上面这段话所表达的意义。

3.3 SSL/TLS的4次握手

1. 客户端发送ClientHello

客户端向服务器发起请求，开始一个新的会话连接

2. 服务器发送ServerHello + PublicKey

服务器回应客户端的请求，并附带上自己的公钥

3. 客户端发送加密的对称密钥

客户端在收到服务器公钥后，随机生成一个对称密钥，并用服务器的公钥加密后发送给服务器。

4. 服务器最后的响应

服务器发送最后的响应，在客户端收到响应后，便意味着双方都知道对方已经知道对称密钥是什
么了。接下来通信使用的协议还是http，只不过应用数据被加密了而已。

上述过程简单的介绍了SSL的加密过程，但是要注意，具体的实现其实和上面的流程相差是比较大的。 在实际使用中，会有很多匪夷所思的攻击手段，而SSL为了预防这些攻击，其实现是相当复杂的。 不过，我们在一开始了解SSL的时候，可以先忽略这些细节，只了解最基础的运作原理就行了。

四、数字签名

我们现在已经粗略的了解了https是如何加密的，但是光靠这样还不能保证通讯的安全。

4.1 中间人攻击

引用一段维基百科的解释

在密码学和计算机安全领域中，中间人攻击（英语：Man-in-the-middle attack，缩写：MITM） 是指攻击者与通讯的两端分别建立独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在 通过一个私密的连接与对方直接对话，但事实上整个会话都被攻击者完全控制。

为了应付这种攻击方法，客户端需要有一种方法确认服务端的身份。

4.2 数字签名

我们知道，在SSL的第二次握手时，服务器会发送公钥给客户端。但是，实际上发送的并不是公钥， 而是数字证书。那么，什么是数字证书呢？

上图包含了数字证书生成的大概流程，过程有所简略，但还是有参考意义的

(1)生成csr(Cerificate Signing Request)文件

csr文件即证书请求文件，由服务器方生成，一般包含公钥和服务器商的身份信息。服务器方生成csr 文件后，将其发送给CA。

(2)CA签名

CA(Certificate Authority)，即电子商务认证授权机构, 它是被客户端信任的第3方。CA在收到 证书后，会核查csr中的信息。如果审核通过，CA会用自己的私钥对csr文件中的内容进行签名。什 么是签名呢？狭义的来说，就是CA会先对csr文件的内容进行MD5，然后用私钥对这个MD5值进行加 密，然后把加密的值和csr文件的内容绑定在一起生成数字证书。

这里我们会发现，CA会使用私钥进行加密，因为公钥是公开的，所以任何人都可以进行解密并查看 其中的内容。但是只有拥有私钥的人，才能发布能够被这个公钥解密的内容, 这样便起到一个认证的 作用。例如，客户端在收到上面认证过的数字证书后，可以先取出其中内容进行MD5，然后用CA方的 公钥解密签名，并比对两个MD5值，如果两个值相等，则能够确认这个证书确实是经过CA方认证的。 无论中间人篡改证书内容还是签名, 都会导致证书检验失败。

Tips: CA的公钥一般包含在其证书中，称为根证书。一般内置在浏览器中

(3)证书颁发

CA方把认证过的数字证书颁发给服务器商

(4)服务器发送证书给客户端

在之后客户端和服务器进行通信时，会先进行握手，服务器会把认证过的证书发送给客户端

(5)证书验证

客户端收到证书后，利用浏览器的内置CA根证书验证收到证书的合法性。如果证书验证失败，浏览器 会警告用户，并让用户选择是否继续。效果类似下图:

五、结语

看到这里我们已经了解了https是如何加密和认证的。这两个措施可以有效的防范窃听风险和冒充风 险。至于数据篡改风险(即使不知道内容，也是可以篡改数据的)，这里并没有讲解，因为我也不是 很了解，就不献丑了。以后有机会也许会补上吧 : )