【E21现场】tv.cctv.com无法正常访问

ID	Creation Date	Assignee	Status
OMPUB-899	2023-04-13T14:56:59.000+0800	杨威	已关闭

埃塞tv.cctv.com突然无法正常访问，中电要求排查确认是否和我们系统有关。

2023-02-17 有部分用户向中电反馈该网站无法正常访问使用，询问是否和TSG系统有关。

当时中电也咨询了业主，业主回复未对该网站进行deny。

当天测试访问的情况是，部分终端首页就无法访问成功，要不首页刷新加载成功了但是点击首页视频视频加载失败。

pcap包是上次2023-02-17 反馈问题给洋姐时捕的数据包

[ https://tv.cctv.com/|https://tv.cctv.com/]目前存在以下情况：

[2023-04-13|https://tv.cctv.com/] 刚访问的结果，是首页访问加载刷新比较慢，首页加载成功后，点击视频然后视频加载10秒钟左右，可加载成功正常播放。

chengsiyuan commented on 2023-04-24T16:14:41.897+0800:

2023-04-24 10:30:00 to 2023-04-24 10:56:59测试：测试环境：电脑连接手机热点，电脑访问[https://tv.cctv.com/；|https://tv.cctv.com/] 测试结果：1、电脑无痕模式下访问[https://tv.cctv.com/]，首次无法访问，点击刷新后2分钟左右，访问成功，但是首页加载速度很慢，点击视频无法加载； 2、测试时间段的Security Events可以查到对应日志，Session Records未查到日志。

附件cctv.com.zip为：测试时间段的pcap包、对应的session record和security event log日志情况截图、以及security event log日志详情

yangwei commented on 2023-04-25T09:17:36.121+0800:

使用wireshark条件tls.handshake.extensions_server_name == "tv.cctv.com"对pcap进行过滤，一共可以查询到6次包含“tv.cctv.com”的SSL Client Hello请求，其中前4次的ja3 hash，与Security Events中的一一对应

!image-2023-04-25-09-05-31-302.png|width=1046,height=539!

查看第一个在客户端捕获的SSL会话，第8个包发起的Client Hello出现了多次重传后，客户端主动发送rst断开，与NPB收到C2S单向流量，并命中策略执行deny->reset动作时，由于缺乏S2C侧信息，执行动作退化为Drop相符，最终客户端在多次重试后，主动结束会话。

!image-2023-04-25-09-07-32-104.png|width=1096,height=214!

最后两个SSL会话，使用服务端IP+SNI条件，在TSG界面查询，未查询到日志可能由以下原因导致： ** 对应处理的NPB（10.227.11.9）处理能力过载，bypass掉了对应的流量没有进行业务处理，可以通过查询NZ界面排除该原因 ** 测试过程中，对应会话的流量没有完整分发给NPB，或者NPB出现丢包，导致不包含SNI为tv.cctv.com的请求（被Deny的会话，不会被包含在会话日志中），可以通过修改查询条件为ClientIP+ServerIP进行排除

yangwei commented on 2023-05-04T17:40:01.829+0800:

4.25更新：

使用思源提供的NZ监控记录，未发现对应的NPB有bypass现象，排除上述可能性1
观察思源提供的测试时段，按服务端IP+客户端IP查询会话记录日志的结果，未见上图在客户端捕包中过滤出来包编号为133和139的两次SSL会话（ja3hash分别为0ff609d8da5f262fbf853192d219b638和4b147568c463e2c44acbacf41c59986f）
!image-2023-05-04-17-37-09-358.png|width=866,height=454!

初步结论为，存在测试客户端部分流量没有经过TSG系统的现象，从而导致deny效果不佳

yangwei commented on 2023-05-06T09:25:25.262+0800:

更新描述后，发现是用户是想确认为什么TSG系统没有下发相关阻断或干扰策略的前提下，[ https://tv.cctv.com/|https://tv.cctv.com/]访问效果不佳。

结合前述分析，更新描述如下：

2023-04-24 10:30:00 to 2023-04-24 10:56:59测试 ** 客户端数据分析 *** 客户端共发起6次包含“tv.cctv.com”的SSL Client Hello请求，其中前4次访问失败，后2次访问成功 *** 分析失败的前4次访问可以发现，发起Client Hello后，出现了多次重传，最后客户端主动发送rst断开。该现象与被中间网络设备丢弃数据包类似。 ** TSG系统日志数据分析 *** 在TSG系统查询客户端公网IP+前4次访问的服务端IP（95.101.22.161），可以找到对应ja3hash的会话日志，说明该会话经过TSG系统，且TSG系统并未做出相应的丢弃数据包行为 *** 分析TSG系统记录的前4个会话信息，发现为C2S侧单向流，且pkt_send数量为3，TSG系统仅能看到C2S侧的SYN，ACK，和首个Client Hello数据包，对于客户端后续的重传包未有记录，{}推测执行丢弃的系统部署位置相对TSG系统，更靠近客户端侧{} *** 对于后2次访问成功的会话，未见到对应的TSG日志查询结果返回，请[~chengsiyuan] 补充查询对应测试时段测试客户端IP+服务端IP（95.101.22.177）的会话日志，以便进一步进行分析 **** 根据补充的会话日志信息，可以在TSG系统查询到后2次使用TLS1.3访问的日志，可知测试客户端的流量经过TSG系统

结论：

tv.cctv.com的访问，存在被其他(除TSG之外的)网络审计系统{}丢弃{}的情况
根据TSG记录的会话日志，{}推测该系统的部署位置，较TSG更靠近客户端{}
客户端捕包结果显示，当tv.cctv.com的访问切换为TLS1.3后，访问成功，对应2023-04-13 测试时首先无法访问，一段时间后可以正常播放的现象，{}推测该系统对TLS1.3的过滤能力不佳{}