浅析HTTPS协议

发表于 | 分类于 | | 阅读次数:

一、基本概念

1、HTTPS

HTTPS，也称作HTTP over TLS。TLS的前身是SSL。端口为443。

下图描述了在TCP/IP协议栈中TLS(各子协议）和HTTP的关系

其中Handshake protocol，Change Ciper Spec protocol和Alert protocol组成了SSL Handshaking Protocols。

HTTPS和HTTP协议相比提供了

  1. 数据完整性：内容传输经过完整性校验
  2. 数据隐私性：内容经过对称加密，每个连接生成一个唯一的加密密钥
  3. 身份认证：第三方无法伪造服务端（客户端）身份

其中，数据完整性和隐私性由TLS Record Protocol保证，身份认证由TLS Handshaking Protocols实现。

2、对称加密

对称密钥（Symmetric-key algorithm）又称为共享密钥加密，对称密钥在加密和解密的过程中使用的密钥是相同的。对称加密有很多种算法，由于它效率很高，所以被广泛使用在很多加密协议的核心当中。

2.1、常见算法

  • DES
  • 3DES
  • AES
  • RC5
  • RC6

2.2、优点与缺点

优点:

  • 加/解密速度快
  • 密钥管理简单
  • 适宜一对一的信息加密传输

缺点：

  • 加密算法简单，密钥长度有限（56比特/128比特）加密强度不高
  • 密钥分发困难，不适宜一对多的加密信息传输。

3、非对称加密

非对称密钥（public-key cryptography），又称为公开密钥加密，服务端会生成一对密钥，一个私钥保存在服务端，仅自己知道，另一个是公钥，公钥可以自由发布供任何人使用。

3.1、常见算法

  • RSA：算法实现简单，诞生于 1977 年，历史悠久，经过了长时间的破解测试，安全性高。缺点就是需要比较大的素数（目前常用的是 2048 位）来保证安全强度，很消耗 CPU 运算资源。RSA 是目前唯一一个既能用于密钥交换又能用于证书签名的算法。
  • D-H：diffie-hellman 密钥交换算法（迪菲－赫尔曼密钥交换），诞生时间比较早（1977 年），但是 1999 年才公开。缺点是比较消耗 CPU 性能。
  • Elgamal、背包算法、Rabin、ECC等

其中最著名的应该是RSA和迪菲－赫尔曼算法了。

3.2、优点与缺点

优点:

  • 更加安全

缺点：

  • 加密和解密花费时间长、速度慢，只适合对少量数据进行加密。

3.3、加密过程举例

  1. 服务端生成配对的公钥和私钥
  2. 私钥保存在服务端，公钥发送给客户端
  3. 客户端使用公钥加密明文传输给服务端
  4. 服务端使用私钥解密密文得到明文
  • 登陆用户：小明
  • 授权网站：某知名社交网站（以下简称XX）

小明都是某知名社交网站XX的用户，XX出于安全考虑在登陆的地方用了非对称加密。小明在登陆界面敲入账号、密码，点击“登陆”。于是，浏览器利用公钥对小明的账号密码进行了加密，并向XX发送登陆请求。XX的登陆授权程序通过私钥，将账号、密码解密，并验证通过。之后，将小明的个人信息（含隐私），通过私钥加密后，传输回浏览器。浏览器通过公钥解密数据，并展示给小明。

  • 步骤一： 小明输入账号密码 –> 浏览器用公钥加密 –> 请求发送给XX
  • 步骤二： XX用私钥解密，验证通过 –> 获取小明社交数据，用私钥加密 –> 浏览器用公钥解密数据，并展示。

用非对称加密，就能解决数据传输安全的问题了吗？前面特意强调了一下，私钥加密的数据，公钥是可以解开的，而公钥又是加密的。也就是说，非对称加密只能保证单向数据传输的安全性。

3.4、公开密钥加密的两个问题

  1. 公钥如何获取：

    浏览器是怎么获得XX的公钥的？当然，小明可以自己去网上查，XX也可以将公钥贴在自己的主页。然而，对于一个动不动就成败上千万的社交网站来说，会给用户造成极大的不便利，毕竟大部分用户都不知道“公钥”是什么东西。

  2. 数据传输仅单向安全：前面提到，公钥加密的数据，只有私钥能解开，于是小明的账号、密码是安全了，半路不怕被拦截。

    然后有个很大的问题：私钥加密的数据，公钥也能解开。加上公钥是公开的，小明的隐私数据相当于在网上换了种方式裸奔。（中间代理服务器拿到了公钥后，毫不犹豫的就可以解密小明的数据）

针对这两个问题，需要介绍下面的两个概念

4、数字签名

除了上面提到的加密解密报文之外，还可以用加密系统对报文进行签名，以说明是谁编写的报文，同时证明报文未被篡改过。这种技术被称为数字签名。

4.1、定义

将报文按双方约定的HASH算法计算得到一个固定位数的报文摘要。在数学上保证：只要改动报文中任何一位，重新计算出的报文摘要值就会与原先的值不相符。这样就保证了报文的不可更改性。

将该报文摘要值用发送者的私人密钥加密，然后连同原报文一起发送给接收者，而产生的报文即称数字签名

4.2、好处

数字签名有两点好处：

  • 签名可以证明是作者编写了这条报文。

    只有作者才会有最机密的私有密钥，因此，只有作者才能计算出这些校验和。校验和就像来自作者的个人“签名”一样。

  • 签名可以防止报文被篡改。

    如果有恶意攻击者在报文传输过程中对其进行了修改，校验和就不再匹配了，由于校验和只有作者保密的私有密钥才能产生，所以攻击者无法为篡改了的报文伪造出正确的校验和。

    工作过程如下：

105572559931273736

5、数字证书

数字证书就是互联网通讯中标志通讯各方身份信息的一系列数据，提供了一种在Internet上验证您身份的方式，其作用类似于司机的驾驶执照或日常生活中的身份证。它是由一个由权威机构—–CA机构，又称为证书授权（Certificate Authority）中心发行的，人们可以在网上用它来识别对方的身份。数字证书是一个经证书授权中心数字签名的包含公开密钥拥有者信息以及公开密钥的文件。最简单的证书包含一个公开密钥、名称以及证书授权中心的数字签名。

证书的内容

  1. 颁发证书的机构的名字 – CA
  2. 证书内容本身的数字签名（用CA私钥加密）
  3. 证书签名用到的hash算法
  4. 证书持有者的公钥

个人理解，前三项是用于证书身份的验证，而最后一个则是证书中包含的内容，因为证书的意义就是服务器返回的一个公钥，而前三项则用于验证这个公钥确实是由服务器返回的并且没有被篡改。

保证这个证书是服务器返回的并且没有被篡改的关键在于浏览器之中内置的CA的根证书，其中包含了CA的公钥，这样通过前三项就能保证证书的正确性。

6、数字签名与数字证书

再理解以下数字签名与数字证书的意义。

首先数字签名的意义就是两点，证明作者身份并且保证数据没有被篡改，它通过hash摘要与非对称加密来实现，但是它的实现由个前提就是接受者必须有正确的公钥，理论上说，如果接受者有所有发送者的公钥并且保证这些公钥的正确性，就不需要数字证书了，但是接受者不可能保存所有的发送者的公钥，它只能保存有限的公钥，并且在通信的时候利用这些有限的公钥来获取发送者的公钥。

所以数字证书就出现了，个人理解它本质上也是一个数字签名，利用上面说的发送者能保存的有限个公钥，来保存CA根证书的公钥，这样就能保证CA根证书机构发送的数据一定是正确且身份明确的，然后再通过这些CA的证书来发送临时的公钥，相当于递归的确认。

通过对数字签名与证书的介绍，就可以解决上面提出的两个问题了

  • 公钥如何获取：

    通过根证书和数字签名技术，来获取公钥。

  • 数据传输的单向安全：

    使用对称加密。而非对称加密主要用于上面公钥的获取。

这样再看一下整个加密通信的流程：

  1. 小明访问服务器，服务器将自己的证书给到小明（其实是给到浏览器，小明不会有感知）
  2. 浏览器首先验证证书的合法性。通过浏览器内置的CA根证书的公钥来验证证书的数字签名，确定改证书是由CA办法并且没有被篡改的。
  3. 浏览器从证书中拿到服务器的公钥A
  4. 浏览器生成一个只有自己自己的对称密钥B，用公钥A加密，并传给服务器（其实是有协商的过程，这里为了便于理解先简化）
  5. 服务器通过私钥解密，拿到对称密钥B
  6. 浏览器与服务器之后的数据通信，都用密钥B进行加密

注意：对于每个访问服务器的用户，生成的对称密钥B理论上来说都是不一样的。比如小明、小王、小光，可能生成的就是B1、B2、B3.

可以看出，整个过程中结合了公钥加密与私钥加密各自的特点，通过二者的配合来保证数据的完整性、隐私性以及身份验证三个特性。

二、工作过程

下面来看一下HTTPS的工作过程

1、基本过程

SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。

但是，这里有两个问题。

  1. 如何保证公钥不被篡改？

    解决方法：将公钥放在数字证书中。只要证书是可信的，公钥就是可信的。

  2. 公钥加密计算量太大，如何减少耗用的时间？

    解决方法：每一次对话（session），客户端和服务器端都生成一个”对话密钥”（session key），用它来加密信息。由于”对话密钥”是对称加密，所以运算速度非常快，而服务器公钥只用于加密”对话密钥”本身，这样就减少了加密运算的消耗时间。

基本过程是这样的：

  1. 客户端向服务器端索要并验证公钥。
  2. 双方协商生成”对话密钥”。
  3. 双方采用”对话密钥”进行加密通信。

上面过程的前两步，又称为”握手阶段”（handshake）。

2、握手阶段

握手阶段涉及四次通信，这个阶段的通信都是明文的。

2.1、客户端 ClientHello

首先，客户端（通常是浏览器）先向服务器发出加密通信的请求，这被叫做ClientHello请求。

在这一步，客户端主要向服务器提供以下信息:

  1. 支持的协议版本，比如TLS 1.0版。
  2. 一个客户端生成的随机数，稍后用于生成”对话密钥”。(标记为随机数1)
  3. 支持的加密方法，比如RSA公钥加密。
  4. 支持的压缩方法。

2.2、服务器回应 ServerHello

服务器收到客户端请求后，向客户端发出回应，这叫做SeverHello。

服务器的回应包含以下内容：

  1. 确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
  2. 一个服务器生成的随机数，稍后用于生成”对话密钥”。(标记为随机数2)
  3. 确认使用的加密方法，比如RSA公钥加密。
  4. 服务器证书。

除了上面这些信息，如果服务器需要确认客户端的身份，就会再包含一项请求，要求客户端提供”客户端证书”。比如，金融机构往往只允许认证客户连入自己的网络，就会向正式客户提供USB密钥，里面就包含了一张客户端证书。

2.3、客户端回应

客户端收到服务器回应以后，首先验证服务器证书。

  • 如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。
  • 如果证书没有问题，客户端就会从证书中取出服务器的公钥。

然后，向服务器发送下面三项信息：

  1. 一个随机数。该随机数用服务器公钥加密，防止被窃听。(标记为pre-master key，前主密钥)
  2. 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
  3. 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。

此外，如果前一步，服务器要求客户端证书，客户端会在这一步发送证书及相关信息。

上面第一项的随机数，是整个握手阶段出现的第三个随机数，又称”pre-master key”。有了它以后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把”会话密钥”。

为什么一定要用三个随机数，来生成”会话密钥”？

“不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。

对于RSA密钥交换算法来说，pre-master-key本身就是一个随机数，再加上hello消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。

pre master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre master secret就有可能被猜出来，那么使用用pre master secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。”

2.4、服务器最后的回应

服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的”会话密钥”。

然后，向客户端最后发送下面信息。

  1. 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
  2. 服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。

至此，整个握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用”会话密钥”加密内容。

三、参考地址

http://www.codeceo.com/article/https-worker.html

http://blog.jobbole.com/107930/

http://www.cnblogs.com/chyingp/p/https-introduction.html

http://blog.csdn.net/oscar999/article/details/9364101

http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html