行至水穷处 坐看“云”起时

Cloud Native ADN -> CNadn.Net

F5 SSL forward proxy

如果一个企业希望当用户访问任意SSL加密的数据时也能监控其内容的话,同时又希望用户不要觉察到TA可能在被监控(至少对于绝大部分普通用户来说),可以考虑使用SSL forward proxy。该功能的基本原理类似于前段时间某强大的传说中的火墙干的那样,当请求通过时候,实时on-fly签发一张让用户感觉不到的server证书,这样客户端SSL实际是和中间设备(F5)在通信,F5在server侧模拟充当普通客户与实际网站通信,从而实现数据解密。

对于F5来说,其实际通信过程如下:

  1. client 发起 client hello 到VIP
  2. F5 vip接到该client hello后在client侧暂时hold住,不处理
  3. 同时在server侧发起一个新的SSL会话,通过该会话获得实际服务器的server证书
  4. 利用server证书里的一些关键信息(CN或者SAN),通过在F5上配置的一个CA实时签发一张关于该server的证书
  5. F5在client侧回复server hello,以及实时签发的证书给client,最后client侧SSL会话建立
  6. client 发送实际数据,F5可以看到该实际数据
  7. F5在server侧利用server侧的SSL会话重新封装数据

如果此时并不想对所有网站都进行这样处理,比如对到一些敏感网站(例如个人网银等)请求,则需要对这些网站进行bypass,所谓bypass就是不让F5获得敏感数据,F5将执行类似纯数据包转发,这个bypass情形的过程如下(假设需求是:缺省截取但对部分网站bypass):

 

  1. client 发起 client hello 到VIP
  2. F5 vip接到该client hello后在client侧暂时hold住,不处理
  3. 同时在server侧发起一个新的SSL会话,通过该会话获得实际服务器的server证书
  4. 利用server证书里的一些关键信息(CN或者SAN)或L3、4层信息,查找匹配bypass列表,然后执行下面蓝色或者红色的过程:
  5. 如果发现匹配,则重新建立一个新TCP连接,将第1步收到的client hello转发给server,后续client和server间的数据,F5只做简单转发。
  6. 如果没有发现匹配,则执行下面的 7-10过程
  7. 利用server证书里的一些关键信息,通过在F5上配置的一个CA实时签发一张关于该server的证书
  8. F5在client侧回复server hello,以及实时签发的证书给client,最后client侧SSL会话建立
  9. client 发送实际数据,F5可以看到该实际数据
  10. F5在server侧利用server侧的SSL会话重新封装数据

配置方法:

1.配置一个client ssl profile,启用ssl forward proxy:

《F5 SSL forward proxy》

蓝色是必配部分,而且如果要做的完美(客户端不容易发现的话,这里的CA是关键,得用浏览器能认得)

红色部分为当需要bypass时配置,其中可以配置根据多重条件bypass,具体看在线帮助,配置选项可以直接选择调用data group配置。

2. 配置一个server ssl profile,同样启用ssl forward proxy,另外如果启用bypass的,则必须在client和server 这两个SSL profile中同时启用。

 

测试效果:

1。没有被bypass,即可以观察明文数据情形:

注意看上述最后的证书是F5自己签发的:

 

2. Bypass情形,即客户端看到实际真实server证书

注意看证书是是未经过F5签发的而是原始的entrust签发的证书

其他问题:

  1. 这个功能需要license,非免费

  2. 该功能不支持server要求双向验证的情形,对于这种情况默认是无法进行处理的,因为在通信过程中的第3步会失败,进而导致F5 reset client侧连接。

Bugs:

sol16360: The SSL Forward Proxy feature does not fully support the SSL Forward Proxy Bypass option

sol15830: Changes made to a data group are not automatically propagated to a Client SSL profile

 

另外,上述假定访问vs的都是标准的HTTPS请求,实际应用很可能是一个全0的通配类VS,那么此时需要考虑一些irule,利用irule判断如果是一个SSL握手,则启用ssl profle功能,否则关闭SSL profile,类似这样

 

附加信息,在一个全0的通配端口的vs上,当一个tls1.0以上版本的ssl 请求的话,识别其SNI是否在2way——ssl的bypass group中,如果匹配则vs当成普通转发vs,如果不匹配则启用两侧ssl profile进行SSL forward处理。并针对一些匹配条件启动SSL forward bypass策略。 对于SSLV3,由于不适用于ssl forward功能,直接当成普通vs转发。注意下述irule对没有提供SNI且服务器要求2way-ssl的情形是无法处理的。

 

点赞

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据