【笔记】【HTTP】《图解HTTP》第7章 确保web安全的https

前言

• 有输入就要有产出，该笔记是本人看完《图解HTTP》后对每章涉及到的知识进行汇总
• 博客将会已书的每章为一篇发布，下一篇博客发布时间不确定
• 笔记中有些个人理解后整理的笔记，可能有所偏差，也恳请读者帮忙指出，谢谢。

免责声明

• 本博客是本人在学习《图解 HTTP》后整理的笔记，旨在方便复习和回顾，并非用作商业用途。
• 为了方便，博客有些图与书中的图一致，因此没有自行截图，而是采取引用他人博客图片地址，感谢这些博主提供的图床。
• 此笔记用于记录本人对于该知识的汇总。以方便日后的工作与学习。
• 内容与原书不完整，请读者结合原书观看
• 如有侵权请告知，马上删除。

第7章 确保web安全的https

7.1 HTTP的缺点

1. 通信使用明文可能被窃听

• 产生原因：HTTP本身不具备加密功能，所以无法做到对通信整体进行加密

  • 通信整体：
    • 这里的通信整体是指使用 HTTP 协议通信的请求和响应的内容

• 窃听位置：TCP/IP是可能被窃听的网络

  • 即便已记过加密处理的通信 ，也会被窥视到通信内容，这点和未加密是相同的。
  • 窃听相同段上的通信方法：
    • 只需要收集在互联网上的流动的数据包（帧）就行。
    • 用抓包或嗅探器工具，解析收集来的数据包。

• 防止被窃听：加密处理

  • 通信的加密（即加密HTTP的通信内容）

    • 方法：HTTP协议通过和SSL或TLS的组合使用

      • SSL（Secure Socket Layer）：安全套接层
      • TLS（Transport Layer Security）：安全层传输协议

      • 与SSL组合使用的HTTP被称为HTTPS

        • HTTPS：
          • 超文本传输安全协议
          • 用SSL建立安全通信线路之后，可以在这条线路上进行HTTP通信。

  • 内容的加密（即加密HTTP报文里所含的内容）

    • 客户端需要对HTTP报文进行加密处理后再发送请求。
    • 有效加密实现前提：
      • 要求客户端和服务器同时具备加密和解密机制。

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

• 产生原因：HTTP协议中的请求和响应不会对通行方进行确认。

• 伪装位置：任何人都可以发起请求

  • 服务器只要接收到请求，不管对方是谁都会返回一个响应。

• 产生的隐患：

  • 无法确定请求发送至目标的 Web 服务器是否是按真实意 图返回响应的那台服务器。

    • 有可能是已伪装的 Web 服务器。

  • 无法确定响应返回到的客户端是否是按真实意图接收响 应的那个客户端。

    • 有可能是已伪装的客户端。

  • 无法确定正在通信的对方是否具备访问权限。

    • 因为某些 Web 服务器上保存着重要的信息，只想发给特定用户通信的权限。

  • 无法判定请求是来自何方、出自谁手。 即使是无意义的请求也会照单全收。

    • 无法阻止海量请求下的 DoS 攻击

      • DoS攻击：(Denial of Service，拒绝服务攻击)。

• 防止伪装：查明对手的证书。

  • 使用SSL

    • 提供加密处理

    • 还使用了一种被称为证书的手段，来确认方。

      • 证书：
        • 由值得信任的第三方机构颁发。
        • 用以证明服务器和客户端是实际存在的。
        • 伪造证书从技术角度来说是异常困难的一件事。

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

• 产生原因：HTTP无法证明通信报文完整性

  • 完整性：信息的准确度。

• 产生的隐患：接收到的内容可能有误

• 篡改位置：在请求或响应送出之后直到对方接收之前这段时间内

  • 即使请求或响应的内容遭到篡改，也没有办法获悉。（即没有任何办法确认，发出的请求/响应和接收到的请求/响应是前后相同的。）

    • 中间人攻击（Man-in-the-Middle attack,MITM）：
      • 请求或响应在传输途中，遭攻击者拦截并篡改的攻击。

• 防止篡改：

  • MD5和SHA-1散列值校验

    • MD5：
      • 由单向函数生成的散列值。

  • PGP数字签名

    • PGP（Pretty Good Privacy）完美隐私：
      • 用来证明创建文件的数字签名。

  【注意】

  • 两种方法都需要操纵客户端的用户本人亲自查验下载的文件是否就是原来服务器上的文件。

    • 浏览器无法自动帮用户检查。

  • 依旧无法百分百保证确认结果正确。

    【原因】

    • PGP和MD5本身被改写的话，用户是没有办法意识到的。

    【因此】

    • 有必要使用HTTPS。
      • SSL提供认证和加密处理及摘要功能。

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

1. HTTPS

• HTTP加上加密处理以及完整性保护后

  • 加密处理：防止线路遭到窃听
  • 完整性保护：防止报文被篡改

• 使用格式

  https://
  

• 不是应用层的一种新协议。（即HTTPS其实是披着SSL协议外壳的HTTP）

  • 只是HTTP通信接口部分用SSL和TLS协议代替而已。

    通常	使用SSL
    HTTP直接和TCP通信	1. 先和SSL通信 2. 再由SSL和TCP通信

    

  • SSL：
    • HTTP在采用SSL后，HTTP就拥有了HTTPS的加密、证书和完整性保护这些功能。
    • 独立于HTTP的协议。
    • 是当今世界上应用最为广泛的网络安全技术。
      • 不光是HTTP协议，其他运行在应用层的SMTP和Telnet等协议均可配合SSL协议使用。

2. 相互交换密钥的公开密钥加密技术

1. 公开密钥加密

• 加密算法是公开的。
• 密钥是保密的
  • 加密和解密都会用到密钥
  • 没有密钥就无法对密码解密。（即任何人只要持有密钥就能解密了）
• 缺点：密钥被攻击者获得，加密失去意义。

2. 共享密钥加密（对称密钥加密）

• 加密和解密同用一个密钥
• 必须将密钥也发给对方。
• 缺点：如果[通信被监听](# 1. 通信使用明文可能被窃听)密钥就可会落入到落入攻击者之手，加密失去意义。

3. 使用两把密钥的公开密钥加密

• 公开密钥加密

  • 解决了共享密钥加密的困难

• 使用一对非对称密钥

  • 私有密钥：
    • 不允许让其他人知道
  • 公开密钥：
    • 可以随意发布，任何人都可以获得。

• 加密方式：使用公开密钥加密方式

• 过程：

  1. 发送密文的一方使用对方的公开密钥进行加密处理
  2. 对方接收到被加密信息后，再使用自己的私有密钥进行解密。

  

4. HTTPS采用混合加密机制

• HTTPS采用共享密钥和公开密钥两者并用的混合加密机制。

• 过程：

  • 在交换密钥环节使用公开密钥加密方式
  • 之后的建立通信交换报文阶段则使用共享密钥加密方式。

  

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

1. 可证明组织真实性的EV SSL证书

• 作用：
  1. 证明作为通信一方的服务器是否规范
  2. 确认对方的服务器背后运行的企业是否正是存在。

2. 用以确认客户端的客户端证书

• 作用：进行客户端的认证
  • 证明服务器正在通信的对方始终是预料之内的客户端。
• 存在的问题：
  1. 获取证书时，用户得自行安装客户端证书。（即需要自费安装）
  2. 只能用来证明客户端实际存在，而不能用来证明用户本人的真实有效性。
     • 只要获得了安装有客户端证书的计算机的使用权限，就同时拥有了客户端证书的使用权限。

3. 由自认证机构颁发的自签名证书

• 自认证机构：独立构建的认证机构
  • 作用：相当于自己对外宣称“我是XXX”的程度。
  • 需要让值得信赖的第三方机构接入认证，才能让自认证机构颁布的公开密钥发挥作用，并借此证明服务器的真实性。

• 拥有证书特征：
  • 浏览器访问该服务器时，会显示‘"无法确认连接安全性"或 “该网站的安全证书存在问题”等警告消息。

4. HTTPS的安全通信机制

1. 通信步骤

1. 简略步骤

1. 客户端：发送Client Hello报文开始SSL通信

   • Client Hello报文：
     • 包含内容：
       • 客户端支持的SSL的指定版本
       • 加密组件列表（所使用的加密算法及密钥长度等）。

   
   

2. 服务器：可进行SSL通信时，会以Sever Hello 报文作为应答。

   • Sever Hello 报文：
     • 包含内容：和Client Hello报文所包含内容意义。
       • 只不过服务器的加密组件内容是从接受到的客户端加密组件内筛选出来的。

   
   

3. 服务器：发送Certificate 报文。

   • Certificate 报文：
     • 包含内容：公开密钥证书。

   
   

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

   
   

5. 客户端：在SSL第一次握手结束之后，以Client Key Exchange 报文作为回应。

   • Client Key Exchange 报文：
     • 包含内容：
       • 通信加密中使用的一种被称为Pre-master secret 的随机密码串。
     • 该报文以用步骤三中的公开密钥进行加密。

   
   

6. 客户端：继续发送Change Cipher Spec 报文。

   • Change Cipher Spec 报文：
     • 会提示服务器，在此报文之后的通信会采用Pre-master secret 密钥加密。

   
   

7. 客户端：发送Finished报文。

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

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

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

10. 服务器和客户端：Finished报文交互完毕后，SSL连接就算建立完成。

    • 通信会收到SSL的保护。
    • 从此处开始进行应用层协议的通信，即发送HTTP请求。

11. 应用层协议通信，即发送HTTP响应。

12. 客户端：最后断开连接。

    • 发送close_notify报文：断开连接
    • 发送TCP FIN报文：关闭与TCP的通信。

2. MAC报文

• 应用层发送数据时附件的报文
• 作用：能够查知报文是否遭到篡改，从而保护了报文的完整性。

3. 整个HTTPS通信过程

2. SSL和TLS

• HTTPS使用SSL和TLS这两个协议。

• TSL是以SSL为原型开发的协议，有时候会统一称该协议为SSL

• 当HTTPS使用SSL时，处理速度会变慢。

  

  • SSL速度慢：
    • 慢指的是：
      1. 通信慢
      2. 速度慢：由于大量消耗CPU及内存等资源，导致的。
    • 解决方法：使用SSL加速器（专用服务器）硬件

3. 不一直使用HTTPS的原因

1. 加密通信会消耗更多的CPU及内存资源。
2. 只有在包含个人信息等敏感数据时，才利用其进行加密通信。
3. 对于访问量大的网站，负载过大，资源浪费，不使用HTTPS可节约资源。
4. 购买证书认证太贵了。