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

right