HTTPS 原理浅析及其在 Android 中的使用

作者：曹丰斌

  本文首先分析HTTP协议在安全性上的不足，进而阐述HTTPS实现安全通信的关键技术点和原理。然后通过抓包分析HTTPS协议的握手以及通信过程。最后总结一下自己在开发过程中遇到的HTTPS相关的问题，并给出当前项目中对HTTPS问题的系统解决方案，以供总结和分享。如有不当之处，欢迎批评和指正。

1.HTTP协议的不足

  HTTP1.x在传输数据时，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份，存在的问题如下：

• 通信使用明文(不加密)，内容可能会被窃听；
• 不验证通信方的身份，有可能遭遇伪装；
• 无法证明报文的完整性，所以有可能已遭篡改；

  其实这些问题不仅在HTTP上出现，其他未加密的协议中也会存在这类问题。

(1) 通信使用明文可能会被窃听

  按TCP/IP协议族的工作机制，互联网上的任何角落都存在通信内容被窃听的风险。而HTTP协议本身不具备加密的功能，所传输的都是明文。即使已经经过过加密处理的通信，也会被窥视到通信内容，这点和未加密的通信是相同的。只是说如果通信经过加密，就有可能让人无法破解报文信息的含义，但加密处理后的报文信息本身还是会被看到的。

(2) 不验证通信方的身份可能遭遇伪装

  在HTTP协议通信时，由于不存在确认通信方的处理步骤，因此任何人都可以发起请求。另外，服务器只要接收到请求，不管对方是谁都会返回一个响应。因此不确认通信方，存在以下隐患：

• 无法确定请求发送至目标的Web服务器是否是按真实意图返回响应的那台服务器。有可能是已伪装的 Web 服务器；
• 无法确定响应返回到的客户端是否是按真实意图接收响应的那个客户端。有可能是已伪装的客户端；
• 无法确定正在通信的对方是否具备访问权限。因为某些Web服务器上保存着重要的信息，只想发给特定用户通信的权限；
• 无法判定请求是来自何方、出自谁手；
• 即使是无意义的请求也会照单全收，无法阻止海量请求下的DoS攻击；

(3) 无法证明报文完整性，可能已遭篡改

  所谓完整性是指信息的准确度。若无法证明其完整性，通常也就意味着无法判断信息是否准确。HTTP协议无法证明通信的报文完整性，在请求或响应送出之后直到对方接收之前的这段时间内，即使请求或响应的内容遭到篡改，也没有办法获悉。

  比如，从某个Web网站下载内容，是无法确定客户端下载的文件和服务器上存放的文件是否前后一致的。文件内容在传输途中可能已经被篡改为其他的内容。即使内容真的已改变，作为接收方的客户端也是觉察不到的。像这样，请求或响应在传输途中，遭攻击者拦截并篡改内容的攻击称为中间人攻击(Man-in-the-Middle attack，MITM)。

(4) 安全的HTTP版本应该具备的几个特征

  由于上述的几个问题，需要一种能够提供如下功能的HTTP安全技术：

• (1) 服务器认证(客户端知道它们是在与真正的而不是伪造的服务器通话)；
• (2) 客户端认证(服务器知道它们是在与真正的而不是伪造的客户端通话)；
• (3) 完整性(客户端和服务器的数据不会被修改)；
• (4) 加密(客户端和服务器的对话是私密的，无需担心被窃听)；
• (5) 效率(一个运行的足够快的算法，以便低端的客户端和服务器使用)；
• (6) 普适性(基本上所有的客户端和服务器都支持这些协议)；

2.HTTPS的关键技术

  在这样的需求背景下，HTTPS技术诞生了。HTTPS协议的主要功能基本都依赖于TLS/SSL协议，提供了身份验证、信息加密和完整性校验的功能，可以解决HTTP存在的安全问题。本节就重点探讨一下HTTPS协议的几个关键技术点。

(1) 加密技术

加密算法一般分为两种：

• 对称加密：加密与解密的密钥相同。以DES算法为代表；
• 非对称加密：加密与解密的密钥不相同。以RSA算法为代表；

  对称加密强度非常高，一般破解不了，但存在一个很大的问题就是无法安全地生成和保管密钥，假如客户端和服务器之间每次会话都使用固定的、相同的密钥加密和解密，肯定存在很大的安全隐患。

  在非对称密钥交换算法出现以前，对称加密一个很大的问题就是不知道如何安全生成和保管密钥。非对称密钥交换过程主要就是为了解决这个问题，使密钥的生成和使用更加安全。但同时也是HTTPS性能和速度严重降低的“罪魁祸首”。

  HTTPS采用对称加密和非对称加密两者并用的混合加密机制，在交换密钥环节使用非对称加密方式，之后的建立通信交换报文阶段则使用对称加密方式。

(2) 身份验证–证明公开密钥正确性的证书

  非对称加密最大的一个问题，就是无法证明公钥本身就是货真价实的公钥。比如，正准备和某台服务器建立公开密钥加密方式下的通信时，如何证明收到的公开密钥就是原本预想的那台服务器发行的公开密钥。或许在公开密钥传输途中，真正的公开密钥已经被攻击者替换掉了。

  如果不验证公钥的可靠性，至少会存在如下的两个问题：中间人攻击和信息抵赖。

  为了解决上述问题，可以使用由数字证书认证机构(CA，Certificate Authority)和其相关机关颁发的公开密钥证书。

CA使用具体的流程如下：

• (1) 服务器的运营人员向数字证书认证机构(CA)提出公开密钥的申请;
• (2) CA通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等；
• (3) 如果信息审核通过，CA会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公钥证书后绑定在一起。
  证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构CA的信息、有效时间、证书序列号等信息的明文，同时包含一个签名；
  签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用CA的私钥对信息摘要进行加密，密文即签名；
• (4) 客户端在HTTPS握手阶段向服务器发出请求，要求服务器返回证书文件；
• (5) 客户端读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应CA的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即公钥合法；
• (6) 客户端然后验证证书相关的域名信息、有效时间等信息；
• (7) 客户端会内置信任CA的证书信息(包含公钥)，如果CA不被信任，则找不到对应CA的证书，证书也会被判定非法。

在这个过程注意几点：

• (1) 申请证书不需要提供私钥，确保私钥永远只能被服务器掌握；
• (2) 证书的合法性仍然依赖于非对称加密算法，证书主要是增加了服务器信息以及签名；
• (3) 内置CA对应的证书称为根证书；颁发者和使用者相同，自己为自己签名，叫自签名证书；
• (4) 证书=公钥+申请者与颁发者信息+签名；

3.HTTPS协议原理

(1) HTTPS的历史

HTTPS协议历史简介：

• (1) SSL协议的第一个版本由Netscape公司开发，但这个版本从未发布过；
• (2) SSL协议第二版于1994年11月发布。第一次部署是在Netscape Navigator1.1浏览器上，发行于1995年3月；
• (3) SSL 3于1995年年底发布，虽然名称与早先的协议版本相同，但SSL3是完全重新设计的协议，该设计一直沿用到今天。
• (4) TLS 1.0于1999年1月问世，与SSL 3相比，版本修改并不大；
• (5) 2006年4月，下一个版本TLS 1.1才问世，仅仅修复了一些关键的安全问题；
• (6) 2008年8月，TLS1.2发布。该版本添加了对已验证加密的支持，并且基本上删除