看看无线网络登录页面有多不安全（附能过滤SSL流量的防火墙原理）

这篇文章的缘起是 EFF 的这篇文章。然鹅本人在当时翻译它时点错了按钮，没有保存。不过这篇文章说的问题和背后原理其实很简单：

该文主角： Captive Portal，直译有点拗口，意思是终端登录（无线）网络时需要认证使用者的身份，这样一种网页，要求你输入相关（个人）信息，给你看一些服务条款。想必大家在公共场所蹭网时都遇到过。

所以问题就是这样的设置很不安全，即要求使用者的个人信息，又会暗地里监视使用者的上网数据。概括地讲，这种设置其实就是著名的 中间人攻击。看，我随便一搜，就有不少不错的文章：1, 2.

那么作为网络管理员呢，如果非要使用网页认证这种方式的话，可以有以下几个措施（待翻译:）

以下是本人摘抄过来的介绍 SSL防火墙的原理，网页认证也是这个原理，可以触类旁通（其实技术不难）。

SSL防火墙

1.1 非解密方式的流量过滤

必须结合 SNI 和 CN/SAN进行:

1.2 Outbound过滤过程

用户首先经过 NGFW 与外部服务器建立TCP连接, 然后发出 SSL握手.

  1. SSL 代理缓存客户端的握手报文, 如果不需要策略重查, 则执行步骤6; 否则, 使用客户端 Hello中 SNI+IP+Port 进行本地的 SNI_CN 不匹配缓存查询, 则根据缓存的分类信息进行策略重查, 转步骤4; 否则,设置需要 SNI_CN一致性检测, 执行步骤2;
  2. 使用客户端 Hello中 SNI 进行异步分类查询, 如果提取异常, 转步骤6;
  3. 收到返回的分类信息后, 发起策略重查;
  4. 收到策略重查结果, 如果为阻断, 则关闭会话; 如果为不代理, 则执行步骤5; 否则 (代理) 执行步骤6;
  5. 以 TCP代理的形式, 解析服务器侧证书, 校验 SNI和CN的一致性, 不匹配则使用 CN/SAN 进行分类查询, 执行步骤10; 同时, 上宋握手报文到 NGE, 进行 URL过滤, 并根据 NGE 返回值进行相应处理, 本流程结束;
  6. SSL 代理使用客户端Hello报文的SNI /版本信息, 发起服务器侧握手;
  7. SSL代理收到服务器证书后, 如果不需要 SNI_CN一致性检测, 则执行步骤9; 否则,检验 SNI 与证书 CN/SAN 的匹配性, 不匹配则使用 CN/SAN 进行分类查询;
  8. 获得分类查询后, 记录本地 IP/SNI/分类缓存, 进行策略重查, 如果不需要代理, 关闭会话 (下一条流转发), 如果为阻断, 则直接关闭会话, 否则(需要代理), 急需后续步骤;
  9. SSL 代理完成与服务器握手后, 使用服务器选择的加密算法即导入的证书与客户端完成握手; 握手完毕(不走步骤10);
  10. 获得分类查询后, 记录本地 IP/SNI/分类缓存, 进行策略重查, 如果为阻断, 则直接关闭会话; 否则,则继续当前的 TCP代理流程, 尝试退代理. 对于需要代理的情况,下一条流生效.

1.3 inbound 流量过滤

用户首先经过 NGFW 与内部设备建立 TCP 连接, 然后发出 SSL 握手;

  1. SSL 代理收到客户端的握手报文后, 坚持客户端Hello中的版本/算法等信息, 检查是否不支持, 不支持则根据配置执行相应动作, 流程结束; 否则执行步骤2;
  2. SSL 代理与服务器进行握手, 获得服务器证书, 如果服务证书与导入的服务器证书之一匹配, 匹配则执行步骤3; 否则形成 IP+SNI 表, 后续放行次会话, 当前会话关闭, 流程结束;
  3. SSL 代理使用服务器选择的加密算法/导入的证书/配置的版本/算法等与客户端完成握手;
  4. 握手完毕后, 客户端将应用层数据以明文方式发送到 NGFW 设备;
  5. SSL 代理对数据进行解密后进行安全检测, 确认安全后, 重新加密发往服务器侧; 否则, 管理员设置进行告警, 阻断等操作;
  6. 服务器对收到的SSL 代理发出的加密数据进行响应, 将数据用加密报文发送给 SSL 代理;
  7. SSL代理对数据进行解密后进行安全检测, 确认安全后, 重新加密发往客户端; 否则, 管理员设置进行告警, 阻断等操作.
Posted on September 14, 2017