Apache服务之HTTPS基础


纸上得来终觉浅,绝知此事要躬行。

Apache服务之HTTPS基础


1. HTTPS 简介

HTTPS,也称作HTTP over TLS
TLS的前身是SSL,因为早期的SSL存在设计缺陷导致未能广泛使用。
TLS 1.0通常被标示为SSL 3.1TLS 1.1SSL 3.2TLS 1.2SSL 3.3

设计目的

  • (1) 所有信息都是加密传播,第三方无法窃听
  • (2) 具有校验机制,一旦被篡改,通信双方会立刻发现
  • (3) 配备身份证书,防止身份被冒充

耗时

  • HTTP耗时 = TCP握手
  • HTTPs耗时 = TCP握手 + SSL握手

2. HTTPS 事务

Apache服务之HTTPS基础


3. SSL 会话握手

SSL/TLS协议的基本思路是采用公钥加密算法,默认使用RSA
公钥加密/私钥解密: 客户端先向服务器端索要公钥,然后用公钥加密信息,服务器收到密文后,用自己的私钥解密。

3.1 产生的问题

Apache服务之HTTPS基础

  • (1)如何保证公钥不被篡改?
    • 解决方法:将公钥放在数字证书中。只要证书是可信的,公钥就是可信的。
  • (2)公钥加密计算量太大,如何减少耗用的时间?
    • 解决方法:每一次对话(session),客户端和服务器端都生成一个”对话密钥”(session key),用它来加密信息。
    • 由于”对话密钥”是对称加密,所以运算速度非常快,而服务器公钥只用于加密”对话密钥”本身,这样就减少了加密运算的消耗时间。

3.2 SSL 握手

使用RSA算法的SSL握手过程

Apache服务之HTTPS基础

  • (1) [明文] 客户端发送随机数client_random和支持的加密方式列表
    • 客户端支持的协议版本,比如TLS 1.0版本
    • 客户端生成一个用于生成”对话密钥”的随机数
    • 客户端支持的加密方法,比如RSA公钥加密
    • 客户端支持的压缩方法
  • (2) [明文] 服务器返回随机数server_random,选择的加密方式和服务器证书
    • 确认使用的加密通信协议版本,比如TLS 1.0版本
    • 生成一个用于生成”对话密钥”的随机数
    • 确认使用的加密方法,比如 RSA 公钥加密
    • 发送服务器证书
  • (3) [RSA] 客户端验证服务器证书,使用证书中的公钥加密premaster secret发送给服务端
    • 验证服务器证书
    • 发送一个用服务器公钥加密随机数,防止被窃听
    • 编码改变通知,表示随后的信息都将用双方商定的加密方法和密钥发送
    • 客户端握手结束通知,表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值,用来供服务器校验。
  • (4) 服务端使用私钥解密premaster secret
    • 服务端使用自己的私钥解密客户端通过公钥加密的随机数
  • (5) 两端分别通过client_randomserver_random  和premaster secret生成master secret,用于对称加密后续通信内容
    • 编码改变通知,表示随后的信息都将用双方商定的加密方法和密钥发送
    • 服务器握手结束通知,表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值,用来供客户端校验。

3.3 DH 算法的握手阶段

整个握手阶段都不加密(也没法加密),都是明文的。因此,如果有人窃听通信,他可以知道双方选择的加密方法,以及三个随机数中的两个。整个通话的安全,只取决于第三个随机数(Premaster secret)能不能被破解。

虽然理论上,只要服务器的公钥足够长(比如2048位),那么Premaster secret可以保证不被破解。但是为了足够安全,我们可以考虑把握手阶段的算法从默认的RSA算法,改为Diffie-Hellman算法。

采用DH算法后,Premaster secret不需要传递,双方只要交换各自的参数,就可以算出这个随机数。

Apache服务之HTTPS基础

  • 上图中,第三步和第四步由传递Premaster secret变成了传递DH算法所需的参数,然后双方各自算出Premaster secret。这样就提高了安全性。

3.4 session 的恢复

握手阶段用来建立SSL连接。如果出于某种原因,对话中断,就需要重新握手。这时有两种方法可以恢复原来的session:一种叫做session ID,另一种叫做session ticket

session ID

  • session ID的思想很简单,就是每一次对话都有一个编号(session ID)。如果对话中断,下次重连的时候,只要客户端给出这个编号,且服务器有这个编号的记录,双方就可以重新使用已有的对话密钥,而不必重新生成一把。

Apache服务之HTTPS基础

  • 上图中,客户端给出session ID,服务器确认该编号存在,双方就不再进行握手阶段剩余的步骤,而直接用已有的对话密钥进行加密通信。

session ticket

  • session ID是目前所有浏览器都支持的方法,但是它的缺点在于session ID往往只保留在一台服务器上。所以,如果客户端的请求发到另一台服务器,就无法恢复对话。session ticket就是为了解决这个问题而诞生的,目前只有FirefoxChrome浏览器支持。

Apache服务之HTTPS基础

  • 上图中,客户端不再发送session ID,而是发送一个服务器在上一次对话中发送过来的session ticket。这个session ticket是加密的,只有服务器才能解密,其中包括本次对话的主要信息,比如对话密钥和加密方法。当服务器收到session ticket以后,解密后就不必重新生成对话密钥了。

4. HTTPS 相关问题

  • 误解:HTTPS 无法缓存
    • 只要在HTTP头中使用特定命令,HTTPS是可以缓存的
    • Firefox默认只在内存中缓存HTTPS。但是只要头命令中有Cache-Control: Public缓存就会被写到硬盘上
  • 误解:SSL 证书很贵
    • 在效力上,便宜的证书当然会比大机构颁发的证书差一点,但是几乎所有的主流浏览器都接受这些证书
  • 误解:HTTPS 站点必须有独享的 IP 地址
    • 使用子域名通配符SSL证书,就能在一个IP地址上部署多个HTTPS子域名
    • 统一通信证书(UCC)支持一张证书同时匹配多个站点,可以是完全不同的域名
    • 服务器名称指示(SNI)允许一个IP地址上多个域名安装多张证书
  • 误解:HTTPS 太慢
    • 使用HTTPS不会使你的网站变得更快,但是有一些技巧可以大大减少额外开销
    • 同一张网页使用 HTTPS 协议之后打开时间变长,一旦有效的 HTTPS 连接建立起来,两种协议几乎没有区别
  • 误解:只有注册登录页才需要 HTTPS
    • 需要保护的信息都需要HTTPS

文章作者: Escape
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 Escape !
  目录