计算机网络 HTTPS梳理

Posted 2023-01-06 baiiu

前言

在HTTP协议中有可能存在信息窃听或身份伪装等安全问题，使用HTTPS通信机制可以有效的防止这些问题。

HTTP的缺点

• 通信使用明文，内容可能会被窃听

  • TCP/IP是可能被窃听的网络：按TCP/IP协议族的工作机制，通信内容在所有线路上都有可能遭到窥视。
  • 加密处理防止被窃听，加密的对象如下：
    • 通信的加密
      通过和SSL(Secure Socket Layer，安全套接层)或TLS(Transport Layer Security，安全层传输协议)的组合使用，加密HTTP的通信内容。
    • 内容的加密
      把HTTP报文里所含的内容加密。

• 不验证通信方的身份，可能会被伪装

  • 不确认通信方，会存在以下隐患：

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

  • 查明对手的证书
    SSL不仅提供加密处理，还使用了一种被称为证书的手段，可用于确定方。
    证书由值得信任的第三方机构颁发，用以证明服务器和客户端是实际存在的。
    使用证书，以证明通信方就是意料中的服务器，对使用者个人来讲，也减少了个人信息泄露的危险性。另外，客户端持有证书即可完成个人身份的确认，也可用于对Web网站的认证环节。

• 无法验证报文的完整性，可能遭篡改
  接收到的内容可能有误，在请求或响应送出之后直到对方接收之前的这段时间内，即使请求或响应的内容遭到篡改，也没有办法获悉。
  在请求或响应的传输途中，遭攻击者拦截并篡改内容的攻击称为中间人攻击(Man-in-the-Middle attack)。
  仅靠HTTP确保完整性是非常困难的，便有赖于HTTPS来实现。

HTTP+加密+认证+完整性保护=HTTPS

把添加了加密、认证机制、完整性保护的HTTP称为HTTPS(HTTP Secure)。

• HTTPS是身披SSL外壳的HTTP
  HTTPS并不是应用层的一种新协议，只是通信接口部分用SSL(Secure Socket Layer)和TLS(Transport Layer Security)协议代替而已。
  HTTP会先和SSL通信，再由SSL和TCP通信，即披了一层SSL的外壳。
  SSL是独立于HTTP的协议，所有不光是HTTP协议，其他运行在应用层的SMTP和Telnet等协议均可配合SSL协议使用。可以说SSL是当今世界上应用最广泛的网络安全技术。

• 相互交换密钥的公开密钥加密技术
  SSL采用公开密钥加密的加密处理方式。

  • 共享密钥加密：
    加密和解密同用一个密钥的方式，也叫对称密钥加密。
    以共享密钥方式来加密时，必须将密钥也发给对方。这就有两个问题：如何安全的发送、如何安全的存储。这就是共享密钥加密的不好之处。

  • 公开密钥加密
    公开密钥加密使用一对非对称的密钥。一把私有密钥，一把公开密钥，公开密钥和私钥是配对的。
    使用公开密钥加密方式时，发送密文的一方使用对方的公开密钥进行加密，对方收到被加密的信息后，再使用自己的私有密钥进行解密。这种方式不需要发送用来解密的私钥，也不必担心密钥被攻击者窃听盗走。
    再者，根据密文和公开密钥恢复信息原文是非常困难的。

  • HTTPS采用混合加密机制
    HTTPS采用共享密钥加密和公开密钥加密两者并用的混合加密机制。
    因为公开密钥加密的处理速度要慢于共享密钥加密。所以HTTPS利用两者的优势，在交换密钥环节使用公开密钥加密方式，在建立通信交换报文阶段则使用共享密钥加密方式。
    

证明公开密钥正确性的证书

公开密钥加密方式的问题：
无法证明公开密钥本身就是货真价实的公开密钥。即如何证明客户端收到的公开密钥就是原本预想的那台服务器发行的公开密钥；或在公开密钥传输途中，真正的公开密钥已被攻击者替换掉了。

为了解决上述问题，可使用由数字证书认证机构和其相关机关颁发的公开密钥证书。数字认证机构处于客户端与服务器双方都可信赖的第三方机构的立场上。

• 证书使用流程：
  首先，服务器的运营人员向数字证书认证机构提出公开密钥申请，该机构在判明申请者身份后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公钥证书后绑定在一起。
  服务器会将这份公钥证书发送给客户端，以进行公开密钥加密方式通信。
  客户端可使用该机构的公开密钥，对该证书上的数字签名进行验证，一旦验证通过，客户端便明确两件事：1.认证服务器的公开密钥是真实有效的数字证书认证机构； 2.服务器的公开密钥是值得信赖的。
  此处认证机关的公开密钥必须安全的转交给客户端。使用通信方式时，如何安全转交是比较困难的，因此，多数浏览器在发布版本时，会预先内部植入常用的认证机关的公开密钥。
  

• 可证明组织真实性的EV SSL证书
  证书的作用：1. 证明作为通信一方的服务器是否规范；2.确认对方服务器背后运营的企业是否真实存在。拥有该特性的证书就是EV SSL证书(Extended Validation SSL Certificate)。

EV SSL证书是基于国际标准的认证指导方针颁发的证书，其严格规定了对运营组织是否真实的确认方针，因此通过认证的Web网站能够获得更高的认可度。

• 用以确认客户端的客户端证书
  HTTPS中还可以使用客户端证书，以客户端证书进行客户端认证，证明服务器正在通信的对方始终是预料之内的客户端。想获取证书时，用户得自行安装客户端证书。
  现状是，安全性极高的认证机构可颁发客户端证书但仅用于特殊用途的业务，比如网上银行等。

• 由自认证机构颁发的证书为自签名证书
  使用OpenSSL这套开源程序，可以构建一套属于自己的认证机构，从而给自己颁发服务器证书，但在互联网上不可用，浏览器访问该服务器时，会显示无法确认链接安全性或该网站的安全证书存在问题等警告信息。

HTTPS的安全通信机制

HTTP会先和SSL通信，再由SSL和TCP通信，即披了一层SSL的外壳。

SSL/TLS协议的基本过程是这样的：
（1） 客户端向服务器端索要并验证公钥。
（2） 双方协商生成"对话密钥"。
（3） 双方采用"对话密钥"进行加密通信。

1. 客户端通过发送Client Hello报文开始SSL通信。报文中包含客户端支持的SSL的指定版本、加密组件(Cipher Suite)列表(所使用的加密算法及密钥长度等)。

2. 服务器可进行SSL通信时，会以Server Hello报文作为应答。可客户端一样，在报文中包含SSL版本及加密组件。服务器的加密组件内容是从收到的客户端加密组件内筛选出来的。

3. 之后服务器发送Certificate报文，报文中包含公开秘钥证书。

4. 最后服务器发送Server Hello Done报文通知客户端，最初阶段的SSL握手协商部分结束。

5. SSL第一次握手结束之后，客户端以Client Key Exchange报文作为回应，报文中包含通信加密中使用的一种被称为Pre-master secret的随机密码串。该条报文已用步骤3中的公钥进行加密。

6. 接着服务器继续发送Change Cipher Spec报文。该报文会提示服务器，在此报文之后的通信会采用Pre-master secret密钥加密。

7. 客户端发送Finished报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。

8. 服务器同样发送Change Cipher Spec报文。

9. 服务器同样发送Finished报文。

10. 服务器和客户端的Finished报文交换完毕后，SSL连接就算建立完成。当然，通信会受到SSL的保护。从此处开始进行应用层协议的通信，即HTTP通信，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用"会话密钥"加密内容。

11. 最后由客户端断开连接。断开连接时，发送close_notify报文。这步之后再发送TCP FIN报文来关闭与TCP的通信。

HTTPS四次握手

SSL/TLS协议运行机制的概述
图解SSL/TLS协议

注意握手阶段的所有通信都是明文的。

RSA算法

1. 客户端发出请求（ClientHello）
   首先，客户端（通常是浏览器）先向服务器发出加密通信的请求，这被叫做ClientHello请求。
   在这一步，客户端主要向服务器提供以下信息。
   （1） 支持的协议版本，比如TLS 1.0版。
   （2） 一个客户端生成的随机数，稍后用于生成"对话密钥"。
   （3） 支持的加密方法，比如RSA公钥加密。
   （4） 支持的压缩方法。

2. 服务器回应（SeverHello）
   服务器收到客户端请求后，向客户端发出回应，这叫做SeverHello。服务器的回应包含以下内容。
   （1） 确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
   （2） 一个服务器生成的随机数，稍后用于生成"对话密钥"。
   （3） 确认使用的加密方法，比如RSA公钥加密。
   （4） 服务器证书。

3. 客户端回应
   客户端收到服务器回应以后，首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。
   如果证书没有问题，客户端就会从证书中取出服务器的公钥。然后，向服务器发送下面三项信息。
   （1） 一个随机数。该随机数用服务器公钥加密，防止被窃听。又称为pre-master-key。
   （2） 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
   （3） 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。

4. 服务器的最后回应
   服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的"会话密钥"。然后，向客户端最后发送下面信息。
   （1）编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
   （2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。

ECDH算法

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

HTTPS比HTTP要慢2到100倍

HTTPS使用SSL和TLS，它的处理速度会变慢：

1. 除去和TCP连接、发送HTTP请求响应外，还必须进行SSL通信，整体上通信量会增加；
2. 必须进行加密处理，服务器和客户端都要进行加密解密处理，会更多的消耗服务器和客户端的硬件资源，导致负载增加。

TLS优化

《Web性能权威指南》

针对Https变慢的问题，业界也有很多优化手段，如下所示。
这里所说的会话标识符和会话记录单机制，也经常被人称为“会话缓存”或“无状态恢复”机制。无状态恢复机制的优点主要是消除了服务器端的缓存负担，通过要求客户端在与服务器建立新连接时提供会话记录单简化了部署（除非记录单过期）。

Session Identifier优化

“会话标识符”（Session Identifier，RFC 5246）机制是在SSL 2.0中引入的，支持服务器创建32字节的会话标识符，并在上一节我们讨论的完整的TLS协商期间作为其“ServerHello”消息的一部分发送。

服务器会为每个客户端保存一个会话ID和协商后的会话参数。相应地，客户端也可以保存会话ID信息，并将该ID包含在后续会话的“ClientHello”消息中，从而告诉服务器自己还记着上次握手协商后的加密套件和密钥呢，这些都可以重用。假设客户端和服务器都可以在自己的缓存中找到共享的会话ID参数，那么就可以进行简短握手（图4-3）。
借助会话标识符可以节省一次往返，还可以省掉用于协商共享加密密钥的公钥加密计算。由于重用了之前协商过的会话数据，就可以迅速建立一个加密连接，而且同样安全。

Session Ticket优化

Session Identifier的问题，由于服务器必须为每个客户端都创建和维护一段会话缓存，“会话标识符”机制在实践中也会遇到问题，特别是对那些每天都要“接待”几万甚至几百万独立连接的服务器来说，问题就更多了。由于每个打开的TLS连接都要占用内存，因此需要一套会话ID缓存和清除策略，对于拥有很多服务器而且为获得最佳性能必须使用共享TLS会话缓存的热门站点而言，部署这些策略绝非易事。
为了解决上述服务器端部署TLS会话缓存的问题，“会话记录单”（Session Ticket，RFC 5077）机制出台了，该机制不用服务器保存每个客户端的会话状态。相反，如果客户端表明其支持会话记录单，则服务器可以在完整TLS握手的最后一次交换中添加一条“新会话记录单”（New Session Ticket）记录，包含只有服务器知道的安全密钥加密过的所有会话数据。
然后，客户端将这个会话记录单保存起来，在后续会话的ClientHello消息中，可以将其包含在SessionTicket扩展中。这样，所有会话数据只保存在客户端，而由于数据被加密过，且密钥只有服务器知道，因此仍然是安全的。