TCP旁路劫持，糟糕的RFC5961_challenge ack

RFC5961 & CVE-2016-5696，哈哈，典型的拆了东墙补西墙，瘸子治成哑巴。

我一直坚信，信息安全的最高机密就是三缄其口，沉默是金。通俗点说就是不和陌生人说话，不和逼逼的人交谈。

但是TCP偏不，所以TCP不安全。

TCP是一个30多年前的古老的协议，如果不是为了兼容，早就该歇了，但是它却一直活着，使我不得开心颜。

30多年前的网络环境，那是伊始，默认就是一个可信的环境！现在完全不一样。

TCP连接劫持理论上是一件非常容易的事情，因为TCP的所有协议信息全部明文暴露，即便是旁路探测，一个32位的序列号还是容易猜出来的。

考虑到TCP是端到端协议，并不理解中间网络，因此TCP协议的收发端都容忍了乱序，在接收端表现为OFO队列，在发送端发送队列可以被SACK。因此TCP的接收端必须是无条件接收 一个范围而不是特定的一个序列号字节 的数据。

这便给了连接劫持者以可乘之机。因为只要劫持者猜中了一个范围，那么接收端就必须予以回应。

该范围由接收端主机的接收窗口决定，考虑到当前主机的内存越来越大，这个可以被猜中的范围也就越来越大，换句话说，TCP随着网络和主机能力的提高，越来越容易被劫持，越来越不安全。

TCP的接收端无法区分一个数据包来自真正的对端还是来自一个中间人的恶意攻击，这便很尴尬。如果该数据包是中间人的劫持数据包，且数据包包含数据，那么连接的数据将会被污染，如果该数据包有Reset标记，那么连接将会被Rest…

其实，只需要探测采集即可。劫持者持续建立新连接，然后采集时间和序列号信息，画图做函数，基本就能猜出被劫持侧的序列号生成规则了。

如何弥补？

好吧，RFC5961来了：
https://www.rfc-archive.org/getrfc?rfc=5961
可是问题解决了吗？远远没有！

RFC5961竟然违背了 三缄其口沉默是金 的原则啊，它竟然主动发送了一个所谓challenge ACK，试图弥补之前盲目就范的过失，然而却并非如此。

且不说画蛇添足的ACK Throttling被利用，单单这个challenge ACK就有问题。你试图阻止旁路劫持，然而如果不是旁路呢？challenge ACK不还是主动提供了自己的信息给了劫持者吗？然而接收端确实无法沉默是金，因为它真的没法区分来者。

好吧，姑且承认RFC5961确实让TCP旁路劫持更困难了，它的添足之笔甚是精妙，为了不至于这种challenge ACK太多，建议系统配置一个门限值，然后就被利用了。多么讽刺打脸的一件事啊。

CVE-2016-5696的细节参考这篇文章，写的很清楚了：
https://www.anquanke.com/post/id/84479

最近接触一些Quic方面的东西，Quic就把ACK这些全部都加密保护了，使得外部根本无法利用明文协议字段来进行劫持，这是好事吗？这是好事！然而人们偏偏不接受新事物。

人们会说，Quic加密了这些字段，那么中间设备将无法根据这些字段进行分析调优…我的天啊，你一个端到端协议，自己的CC算法做好就好了啊，让中间设备介入毛线啊！你会说，TCP不就是这样吗？我靠，那你是被TCP洗脑了吧，TCP那是做不到，Quic如何能做的更好，还用中间设备吗？！就好像前天我谈GUI，有人说专业人士都喜欢留空桌面，把所有东西都放在开始菜单里…搞笑，这是被微软洗脑了。

浙江温州皮鞋湿，下雨进水不会胖。