剖析 HTTPS 的设计思路

- 日理万妓 2022-03-15 01:16 254阅读 0赞

HTTPS（全称：Hyper Text Transfer Protocol over Secure Socket Layer ，安全的超文本传输协议），是以安全为目标的HTTP通道。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。这个系统的最初研发由 Netscape 进行。

如今，HTTPS 已经渐渐成为主流，很多大型网站都已经全站 HTTPS 化。那么有了 HTTP 后为什么还需要有 HTTPS 呢？——为了解决 HTTP 的不足。

**HTTP 的不足之处**

*  通信内容使用明文——内容可能被窃听
 *  不验证通信方的身份——可能遭遇伪装
 *  无法验证报文的完整性——报文有可能已遭篡改

现在来看看一般的明文通信都存在什么问题。

## 使用明文传输内容存在的问题 ##

在理想的信息流动情况下，信息能够安全达到目的地且未受到任何攻击。

我们平时生活中所说的“攻击”，更多地有”主动“的意义。但是这里的攻击，囊括了主动和被动两层意义。根据 ITU-T 的 X.800 推荐标准（OSI 安全框架），攻击分为以下几类：

*  **被动攻击**
    
     *  **窃听**：一个非授权方介入系统的攻击，获取了传输的信息，破坏保密性。
     *  **流量攻击**：监听流量来判断通信的性质。
 *  **主动攻击**
    
     *  **伪装/冒充**：个实体假装成另外一个实体。
     *  **伪造/篡改**：将伪造的客体插入系统中，破坏真实性。
     *  **重放**：获取有效数据段以重播的方式获取对方信任。
     *  DoS / DDoS：导致合法用户不能够访问正常网络服务的行为都算是拒绝服务攻击。

一般的明文网络访问，无法防止上面所述的攻击方式。通过应用密码学的知识，一般可以阻止上面多数的攻击。（但是密码学对流量攻击、重放和 (D)DoS 还做不了太多。防止重放攻击还需要在更高的应用层做一些处理。）

下面，我们用密码学来解决它可以解决的风险：

1.  **窃听**风险：黑客可以获知通信内容。 —— 保证数据的隐私性
2.  **篡改**风险：黑客可以修改通信内容。 —— 保证数据的完整性
3.  **冒充**风险：黑客可以冒充他人身份参与通信。 —— 保证身份正确。

## 解决窃听风险：加密 ##

1、对称加密 。有流式、分组两种，加密和解密都是使用的同一个密钥。 例如：DES、AES 等

2、非对称加密 。加密使用的密钥和解密使用的密钥是不相同的，分别称为：公钥、私钥，公钥和算法都是公开的，私钥是保密的。非对称加密算法性能低，但是安全性超强，由于其加密特性，非对称加密算法能加密的数据长度也是有限的。 例如：RSA、DSA。

非对称加密是最安全的。但是在频繁大量的网络数据传输过程中，非对称加密算法的性能限制会成为整个系统的瓶颈。如果需要长时间且频繁地传输信息，全程使用非对称加密是万万不可以的。

Client->Server:  I want to talk with you.
    Server->Client:  It's my public key.
    Client->Server:  Message encoded by public key.
    Note: The hacker knows nothing.
    Note: Server knows this messgae.
    复制代码

只要算法和密钥选择得当，使用对称加密算法可以得到同样安全的加密效果。但是使用对称加密密钥也有它自己的问题：通信双方如何商定出密钥。通信双方共享同一个对称密钥，如果双方已经知道这一密钥，之后的信息使用这一密钥进行加密完全没有问题。 但是，不同的客户端、服务器数量庞大，所以双方都需要维护大量的密钥，维护成本很高，密钥极易泄露。因此，对称密钥必须动态生成。但问题就在于，密钥如何安全的分享出去。密钥钥如果泄漏，加密就失去了意义。

我们可以将对称加密和非对称加密联合起来来解决这个问题。

对于没有见过面的双方，第一次请求通信的时候，S 先发出自己的公钥，C 记下 S 的公钥。之后 S 和 C 协商得出一个对称密钥。因为是通信非对称加密后的，监听者仅凭他们之间的通信内容是难以破译出它们协商出的对称密钥的。之后，S、C 使用对称密钥进行正式的通信，监听者不知道他们的密钥，所以也无法破译他们之间的通信内容。

看起来很完美。

## 如何防止中间人：认证 ##

考虑下面的情况：中间人代理了 S、C 之间的所有流量。

C -> H: 请求公钥
    H -> S: 请求公钥
    S -> H: 返回真实公钥
    Note: 伪造密钥对
    H -> C: 返回伪造的公钥
    Note: 用伪造公钥加密明文
    C -> H: 密文
    Note: 解密得到明文
    Note: 用真实公钥加密明文
    H -> S: 密文
    Note: 用私钥解密得明文
    Note: 无感知
    Note: 无感知
    复制代码

中间人通过伪造公钥私钥对，伪装成 S，同时 C、S 双方对此毫无感知。其实即使不伪造密钥对，只要中间人监听到了公钥，就足以把 S 发给 C 的消息给解密出来。这里的问题是：如何确认 ”S“ 是真实的而不是中间人 ”H“，如何保证公钥的准确 。

为了保证公钥的真实性，引入了认证这一手段。

#### 数字签名 ####

数字签名基于公钥私钥体制，将一段文本通过哈希（hash）和私钥加密处理后生成数字签名。接收者用发送者的公共密钥对签名解密，并将之与收到的信息“指纹”进行比较，以确定其真实性。只要签名者的私钥不被泄漏，数字签名就是可信的。

#### 数字证书 ####

数字证书，是由一个官方的证书颁发机构（CA）签发的一组数据。这种证书很难伪造，用于使用者的身份证明。

数字证书包含以下内容：

*  对象名称（人、服务器、组织、公司等）
 *  **对象的公开密钥**
 *  其它扩展信息
 *  = = = = = = = = = = = = = = = = = = = = =
 *  **附上证书颁发机构的数字签名**

使用证书，正常的通信流程是这样子的：

1.  S 会把自己的数字证书下发给 C
2.  C 通过证书中“证书颁发机构的数字签名”来验证证书的来源和完整性。
    
    具体做法是使用 CA 的公钥解密并对比。
3.  一旦证书被认证通过，C 就从证书中取出 “对象的公开密钥”，之后就用这个公钥来加密数据。

CA 的私钥仅它自己知道，因此黑客无法伪造 CA 的签名，也不能得到合法的证书。只要证书认证通过，它的公钥就是可信的。

到这里，这整个过程才算是无懈可击的。

## HTTPS 具体是怎么做的 ##

HTTPS 的通信过程和上面描述的基本一致。

-> 客户端向服务端发送请求
    -> 服务端返回数字证书
    -> 客户端用自己的CA[主流的CA机构证书一般都内置在各个主流浏览器中]公钥去解密证书,如果证书有问题会提示风险
    -> 如果证书没问题客户端会生成一个对称加密的随机秘钥然后再和刚刚解密的服务器端的公钥对数据进行加密,然后发送给服务器端
    -> 服务器端收到以后会用自己的私钥对客户端发来的对称秘钥进行解密
    -> 之后双方就拿着这个对称加密秘钥来进行正常的通信`
    复制代码

整个过程中，HTTPS 证书使用的是 X.509 证书标准。

X.509 是密码学里公钥证书的格式标准。 X.509 证书己应用在包括TLS/SSL 在内的众多网络协议里。

X.509 是由国际电信联盟（ITU-T）制定的数字证书标准。为了提供公用网络用户目录信息服务， ITU 于 1988 年制定了 X.500 系列标准。其中 X.500 和 X.509 是安全认证系统的核心， X.500 定义了一种区别命名规则，以命名树来确保用户名称的唯一性； X.509 则为 X.500 用户名称提供了通信实体鉴别机制，并规定了实体鉴别过程中广泛适用的证书语法和数据接口， X.509 称之为证书。

HTTPS协议使用的是 SSL 证书，它**遵从**了 X.509 标准。

*  证书格式版本号
 *  证书序列号
 *  过期时间
 *  证书办法机构
 *  证书使用的签名算法
 *  过期时间
 *  对象名称（人、服务器、组织、公司等）
 *  **对象的公开密钥**
 *  其它扩展信息
 *  = = = = = = = = = = = = = = = = = = = = =
 *  **附上证书颁发机构的数字签名**

在浏览器中，查看证书内容非常容易。

### X.509 证书的信任链 ###

到现在，还有一个问题没有被解决。使用证书认证的前提是 C 知道 S 的公钥，可是S 的公钥不能在不安全的网络中直接发送给 C。

此时就引入了**证书颁发机构**（Certificate Authority，简称CA），世界上CA数量并不多。C 预先拥有所有受信任CA的证书。如果 S 想要一个证书，它先向 CA 申请，CA 使用它自己的私钥对 S 的证书进行签名。接下来，C 和 S 要相互通信的时候，S 将它的证书发给 C。 C 拥有所有 CA 的可信公钥，所以 C 可以验证证书的真实性。

如此一来，C 信任 CA，CA信任 S 使得 C 信任 S，信任链（Chain Of Trust）就是这样形成的。

事实上，客户端 C 内置的是 CA的根证书(Root Certificate)，HTTPS协议中服务器会发送证书链（Certificate Chain）给客户端。

如上图，“Wikipedia”的证书的证书链如下。这里，C 一定是信任 根证书 Root CA 的，于是 C 最终信任 "Wikimedia Foundation, Inc" 。这里有一个细节，根证书是由根证书自己来签名和颁发的。

<table> 
 <thead> 
  <tr> 
   <th>证书</th> 
   <th>证书颁发者</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>GlobalSign Root CA（根证书）</td> 
   <td>GlobalSign Root CA（自签名）</td> 
  </tr> 
  <tr> 
   <td>GlobalSign Organization Validation CA - SHA256 - G2</td> 
   <td>GlobalSign Root CA</td> 
  </tr> 
  <tr> 
   <td>"Wikimedia Foundation, Inc."</td> 
   <td>GlobalSign Organization Validation CA</td> 
  </tr> 
 </tbody> 
</table>

最终，C 只要内置世界上仅有的几个根证书就可以自行校验所有的 HTTPS 证书了。S 的证书必须经过某一个 CA 的签名。但是现在的操作系统和浏览器也允许用户自行添加自己的根证书。例如 `12306.cn` 曾经要求用户自行下载安装指定的根证书。

从下图可以看到，根证书 “GlobalSign Root CA” 早已经内置到系统内部了。

## 结语 ##

使用密码学理论，客户端和服务器之间实现了信息的保密传输。密码学中对称加密、非对称加密和哈希函数在整个通信建立的过程中都发挥了作用，并且都缺一不可。密码学的理论知识已经成为安全通信的理论基础。

现在 HTTPS 已经被广泛运用到各大网站中，它已经成为我们日常中用到的技术，而我们对此并没有太大的感知。密码学提供了很多已经被我们视为理所当然的工具，我们使用的大多数安全通信工具都仰仗于它。