钓鱼 TLS 攻击的可行性 #2317
Comments
|
大可不必，我有一个更优的钓法：“国内常用网站或客户端”向一个“境外钓鱼网址”发送 ID，再去看这个 ID 是哪个 IP 发的 所以钓鱼当然是可以钓的，但我的钓法能钓不止 XTLS（更通用），还不会触发 TLS 错误（更隐蔽），还无需过滤流量（更高效） “更隐蔽”还体现在，其实你网站上简单挂个国外的流量统计就相当于开始钓了， |
你这个方法不能直接找到出国连接去确定国内用户和用于出国的 sni、目标 ip 和端口的组合（是“不能直接”，不是“不能”）。如果国外经过中转就更难找到。这里说 xtls 是因为只有这个直接用于出国。以及如果我的理解没错的话，你这里的 id 只由投放的网页决定，如果网页同时也提供给国外访问，就无法区分正常流量和代理流量。 |
|
首先，审查者的最终目的是找到翻墙服务器，那么我的方法肯定是更优的，优点上面已经列出来了。国外的中转绝大多数是 CDN 或一些特殊需求分流，对于前者你的方法完全钓不到， 其次，ID 那部分你没看懂，“国内常用网站或客户端”当然知道这个 ID 是属于哪个国内 IP 甚至用户的， 最后，如果你就是想抓到单个连接，我也可以提供另一个更通用、隐蔽的方法：特殊的难以被 padding 掩盖的收发流量 pattern。 |
|
我的意思是，我的方法可以作为自动加载的资源文件投放，而用这种方法传 id 就有限制，否则就需要用 js 主动传输 id，而且还是不能直接得到出国服务器的 sni 和端口。通过钓鱼服务器能直接得到一台国外服务器的 ip，但是如果有不止一台国外服务器，手动配置中转，就不能直接得到出国服务器的 ip。因为这个 id 只能包含最初客户端的信息，即使检索这个客户端的出站也只能找到下一跳的连接，如果国内也有中转就也不容易从国内流量找到出国服务器。无论如何，这些都需要主动处理，不能直接在出国网关上部署被动检测，所以我说“直接”，当然只是要实现你说的”最终目的“的话也是可行的。 你说的“后者（特殊需求分流）不会涉及钓鱼域名”没看懂。 最后，感觉你说的流量模式仍然可以因为多路复用被覆盖，准确率不会很高，实现难度可能不小。这里能公开说明一下构造方法吗？ |
|
当然我说的这两种方法也是可以在一定程度上结合起来使用的， 对于我说的第一种方法，关于“不能直接”和“不能”，我说一下：钓到了用户就可以去查同一时间他的出境流量，从而抓到单个连接。 普通人正常出境流量是较少的，数据库也可以过滤掉一些 IP，如果怕他剩下的流量还是多，不是还有收发流量 pattern 嘛。 不过“抓到单个连接”这个需求是比较伪的，审查者的最终目的是找到翻墙服务器， |
出入境数据量是比较大的，所以如果能“直接上报 IP”，我没有必要选择去检测流量。 并且既然我要部署个钓鱼，我肯定是希望通用，而不是只能抓到占比很少的 XTLS。
比如说 Netflix、ChatGPT 需求并不会分流钓鱼域名。
多路复用能起到混淆作用，仅限于它对付的流量是普通的而不是“精心设计”的，另外绝大多数时候并没有大量的干扰流量。 对于构造方法，我推荐直接上正弦波，有傅里叶变换还要啥自行车。 |
这一段有一处错误，我说的第一个方法中，JS 并不是必须的，比如图片链接后加个查询参数就行了 关于“境外中转”前面说过了，关于“境内中转”你可以看一下 https://t.me/projectXtls/147 |
这里的时域数据是包长吗（tls 的侧信道还有啥，这我不熟），如果是的话，能还原出指定频率需要的包会不会比较多？
我的理解是这个 id 同时用于编码客户端 ip，“静态”查询参数不能区分客户端（你之前说没懂的就是这个，我想说这样不能把本来就来自国外的流量区分开），而根据最终客户端动态生成查询参数仍然需要 js。
我说的“境内中转”不是指类似 IPLC 的东西，只是为了隐藏客户端原始 ip。当然你可以说国内的事情总可以追溯，我只是说这能相对地避免”直接“的追溯。 off-topic 叠一下关于 IPLC 我想提一下，公务人员也有访问国外网络的需求（监控国外舆情），而他们也没有和上层直接接触的权限，也许很多时候出国的手段就是 IPLC。另外还有国际贸易的需求，毕竟现在还在“以经济建设为中心”，或许十年内也不会改变这个方针。 |
包长不行，因为包长受到种种限制，加上 padding 等影响，最终的包长不好控制，所以应当是数据量 代理的上传流量是非常少的，也就是说上行干扰非常少，正弦波发几个周期就足够了，想更精准就多取一段时间，但总时间都不长
当然也可以客户端生成一个随机 ID，同时发给国内外两个服务器，
不过国内隐藏原始 IP 的服务应该说是几乎没有，除非你自己搭，可能还多少有点违规，
关于 IPLC， 但是对普通个人来说 IPLC 就是会“没有”，因为没人还敢散售，你买不到。即使偶有流出，价格也不是普通个人能承受的。 还有人说彻底脱钩，我想说严管 IPLC 乱象怎么就彻底脱钩了，又不是没它就不能翻墙，他们底下人做事也不是都能用上 IPLC。 |
|
审查者在这么做之前，已经拿到了翻墙服务器的 IP，且适用于各种协议，若再去生成、检测流量是为了找 IP， XTLS/Go#17 (comment) 我觉得若要应对审查者掌控代理服务端或目标地址的情况，只能是类似 Tor 的模式。 |
|
比如说 GFW 在这里插一个正常的静态 img，我们一加载它不就拿到服务器 IP 了，GFW 再去查这 IP 有什么、有谁连接，不就凉了 所以我上 GitHub 都是用 Tor，另一方面 GitHub 肯定有 GFW 内线，其实它有能力直接把我 IP 交出去， 要对付我说的第一种钓法，只有全代理，要对付我说的第二种钓法，只有彻底抹平流量特征，但这些解法特征都很明显，挺无解的 |
你的意思是单次连接上下行的总数据量？没搞懂，请教一下细节。
我忘了客户端是直连目标网页了，确实拿得到
我的意思就是自己搭，所以我说“可以追溯”。
这里我们理解的分歧大概在于，我认为公务人员也属于“普通个人”，他们用来出国的方法不比我们多，只是他们的行为即使被检测也会被豁免。
我理解你想说的是，在全局的脆弱性下，局部的脆弱性可以忽略。但我的观点相反，往往是局部的脆弱性更容易被利用，而利用全局的脆弱性会受到更多的制约。 |
一段时间的数据量作为一个采样点，离散采样加 FFT
服务端只需小改，这都嫌麻烦的话“客户端生成一个随机 ID，同时发给国内外两个服务器”，查日志就行，这件事可以很做得隐蔽
对于一些领导和特殊部门能用上 IPLC，对于底层打工科员就八仙过海各显神通 分歧不在于这里，而是你应该认识到严管 IPLC 对经济建设并没有多少影响，企业仍会有合法 IPLC，且翻墙手段不止 IPLC 这一种，现在绝大多数人并没有在用 IPLC，而是各种翻墙协议，如果哪天 IP 白名单了，灵活翻墙没了，这才会对经济建设有严重影响
|
你说的是覆盖率低，我承认。我说的是部署上的灵活性，尽管这在技术上确实不值一提，但是在行政上或许会多一点麻烦。客户端生成 id 不管同时发送给两个服务器还是什么都需要 js，当然这不是什么高要求。这里只是提一下细节，你说的也很合理，我觉得不用再讨论了。
按我的理解，你是认为严管 iplc 会让用户被迫使用代理协议出国，更利于监控。而我这里是认为底层科员利用被“滥用”的 iplc 的可能性不小。而如果使用率真的很小，严管也没有足够的好处。就是说用的多的话会伤到自己人，用的少的话根本不用管，所以“滥用”可能会长期持续。
推测审查者的行为本来就不只是技术问题。这里我只是试图解释一下为什么我这里提出这个问题，而你不认为这是一个问题，没有讨论“哲学”的意思。你认为的实际情况和我认为的实际情况有区别，这很正常。 |
不是，不管用什么都会被监控，IPLC 可能监控更严，只是不封， 你有一处逻辑矛盾，既然“底层科员”是“普通个人”，那么他们也应当像“普通个人”一样，以用各种翻墙协议为主，而不是 IPLC 我认为散售 IPLC 要凉是因为机场用它，且由于这两年的 GFW，用得更疯狂，
我说了钓是可以钓的，只是我有更好的钓法，一个都跑不掉，注意是更好的， |
“能翻就行”未必比“买 IPLC 机场”简单，而且可能多人共用或者团队分配，不一定需要“自掏腰包”。
“根据历史”总是有一定的合理性，但实际情况还是要具体分析。这里就是在具体推测，当然也只是提供一种可能性，不是什么绝对的说法。
我当然承认你的方法更通用。我那句话的意思就是，你的方法“太通用”，实际用起来反而容易受到额外的限制，虽然听起来有点反逻辑。而只能解决一个问题的特殊方法反而更容易实施，更不容易出错。只是个人理解，不用太在意。 我这个方法缺乏隐蔽性确实是一个问题，不过你的第一个方法隐蔽性也没有多高，如果实施了反审查社区应该很快就能注意到。第二个方法确实比较隐蔽，这里我主观认为不会被使用吧 |
所以不管怎么看，散售 IPLC 都是凉，关键它自己也比以前疯狂啊，以前正宫是优质直连线路，机场都宣传自己的线路多好，IPLC 只是备胎，现在机场用过时协议就等着被墙，IPLC 上位成了“高端”机场的标配，不管真假都宣传自己是 IPLC，它不凉谁凉
你说反了，第一个方法更隐蔽，因为带个参数是很合理的事情，你发现它有也不能确定它是钓鱼，而第二个方法的流量特征很明显 |
我说得明白一点，我认为 iplc 机场相当有市场，很容易被底层科员使用。你觉得他们使用中端机场是”明显更好“的方案，所以我说的情况不存在。这里我不认可你说的”明显更好“而已。我说的也是推测，证明不了必要性，合理性是主观的，没必要再争了。
”不管怎么看“是你对未来管控政策的推测，或许你有内部消息帮助你判断，不过如果没有公开的信息源，我也没办法信服是不是。
如果只是监测而没有断流，我觉得都差不多隐蔽，你说第二个更明显也可以。只是第一个方法需要用国外网站，受控制的国内网站用国外网站做统计就不是很自然。如果有断流现象，我觉得第一个方法更容易发现（前端数据收集），而第二个方法一般人不是很容易想到（侧信道），当然想到了也容易发现。 |
而如果你无法给出什么普遍的原因（必要性），那么这叫凭空想象“底层科员集中在 IPLC”而不能说是推测，客观上是不合理的 “我认为 iplc 机场相当有市场，很容易被底层科员使用”这句话有逻辑吗？
首先你要认识到一个历史上的以及正在发生的事实：机场流行的协议必然会先凉，即使其它协议的特征更加明显 #1767 (comment) 因为机场用户是最多的，自建的只是零头，而 GFW 就是一直在找人最多的下手，VPN、SSH、SS、SSR、WSS、Trojan，无一例外 那么现在压力来到了版本之子中转和 IPLC 这边，下一个凉的是什么已经很明显了吧？
不知道你说的断流是什么，GFW 要钓鱼当然会给它白名单，不会掐它， 第二个也需要国外网站，另外第一个不必拘泥于我说的形式，还有很多非常合理、隐蔽的方式，写过 Web 的都能想出 N 种 我发现前面那个“审查者在这么做之前”你理解的问题了， 当然你的方法局限性较大，GFW 要钓的话至少会用我的或更优的方法，还是那个话题：如果被代理目标有鬼，那肯定能找到代理 |
|
补充两个情况：
|
|
我感觉你的逻辑有一点矛盾的地方，你一方面说 iplc 少，没有必要性，另一方面又说 iplc 在机场流行，机场已经不得不用。我只能理解为，你认为中端机场用的协议属于故意留的口子，iplc 属于不受控的方式里面流行的，所以会被优先封杀。 我从来没有说过“底层科员集中在 iplc”，我想表达的是 iplc 占可观的比例，所以容易误伤。这个”可观“不是说大多数，只是说不太少。 总结一下就是前面说的”就是说用的多的话会伤到自己人，用的少的话根本不用管“。你不能单独得出两个结论，又说 iplc 客观上不会被用，又说 iplc 是版本之子必然会凉，你这两个结论只保留一个的话都还算合理。 ”合理、隐蔽的方式有很多“，不意味着不容易被发现，前端逆向又不是没人会，而且审查者的效率往往不如社区。我还可以说每个人都能发明自己的加密算法，但很难没有漏洞。 前面那个不是你理解的这个问题，但总之这里我们看待问题的角度差异比较大，而且我也承认你的逻辑合理。 |
|
这么说吧，比较是相对的，我说 IPLC 流行是相对于它以前备胎的角色，今年已经是一种疯狂的状态，达到了种种限制下的饱和，这已经是非常严重的监管失灵了。 你可以理解为 IPLC 是一个 独立的市场、有额外的监管，若市场大规模异常，治理就会到来。 如果从翻墙的总量来看，IPLC 占比就是少。今年机场以中转为主，中转迟早要凉，那时 IPLC 也跑不掉，因为中转是前置条件。 所以逻辑上是没有冲突的，相比以前，IPLC 已经能滥用的都滥用了，这叫流行，且它适用额外的监管，但供应量远少于常规线路。 另外怎么说呢，枪打出头鸟，“高端”机场拿 IPLC 标榜自己是非常扎眼的行为，就算它供应量少也会引来举报、调查等。 “合理、隐蔽”指的是就算你看到了他的业务逻辑，也不能确定他就是 GFW 安排来钓你的，因为他这个业务逻辑就是正常的。 或者说，有很多正常的业务都没想钓你但会造成钓到了你的事实，这是“分流”必然会有问题，早就被诟病过。 因为网站本来就都会追踪你，举个例子，有个子域在境外，Cookie 自动传过去，这不就巧了。 |
|
To 群里： |
|
还是想逐句回复一下，
往上翻，
这显然不是我的意思，前面我说过：
原句是“也许很多时候出国的手段就是 IPLC”，
以前机场主流是那些直连协议时就有“自己人”“用的多”， |
|
总结一下你的观点：你说 iplc 要凉是因为滥用相对以前严重，更能体现出监管失灵，且有高端机场引流。但这和之前的“机场流行的必然先凉”的理由无关，所以你重新说明“机场流行的是中转，iplc 只是顺带”。 这个论述只要“iplc 就是少”属实就合理，可以认可。 “机场已经不得不用”是来自 https://t.me/projectXtls/147 的“机场是没办法，就算成本高风险大也得上中转甚至 IPLC”。虽然原话首先说的是中转，但上下文把两者高度并列（且把 iplc 放在前面），难免出现一点理解偏差。 关于误伤：我是认为审查者大部分时候相当保守，有可观测的误伤就不会轻易实施，所以我说的“很多”不意味着比例多么大。我感觉你不这么认为，一个理由是历史上代理协议多次被大范围封杀。但问题是不管哪一次也没有真正封完。你现在说流行的协议都被封了，并给出了多份用户报告，那我也很好奇现在的个人或者机场都是怎么连接国外网络的。 关于隐蔽性：我觉得能用来钓鱼的网站都比较官方，所以单是用到了国外网站就值得怀疑 |
是有关的，如果没有“高端”机场对 IPLC 的滥用、没有黑心机场的假 IPLC 宣传，IPLC 就不会吸引到这么多的关注，可能比中转先凉
相比于中转，显然 IPLC 问题性质更严重，这种“不过墙”的特殊线路本来就有非常严格的审批、审计和监管，今年这种情况就是打脸 当然我是不觉得奇怪的，到处都是不受监督的权力、贪污腐败的官员，不出这种问题才有鬼。那位 炮 一开始还说没贿赂，
如果说开源软件觉得被云厂商拿去卖云服务都很不爽，那么中转这种方式的伤害就更大。以前说过中转只会给 GFW 喂海量数据，却对社区发展没有任何帮助，毕竟连名字都不会提，客户端也是用旧的就行，导致普通用户都不知道/关注新协议、新客户端了。 属于是喂的数据最多，credit 却一点都没给。 昨晚微软 TLSv1.3 炸了，我看到有个人连夜修改 200 台机的 REALITY dest，一看就是卖中转的，因为 REALITY 机场暂时没这规模。
这你就错了，你觉得拼多多干了这么多事，中国为啥一声不吭？我们发现某浏览器插件干的事更明目张胆， |
你之前说“机场流行的必然先凉”的理由是“用户多封掉打击大”，这里是说和这个理由无关，因为用户不多，不是说和这一现象无关。
我是想说在我的主观印象中，今年能连接国外网络的人数并没有减少。你说用中转，中转最后也需要一个代理协议出国，那么就是没封完，你总不至于说最后用的都是 REALITY。
审查者和私有企业都合作相对地不会那么深远，因为企业会给自己留底。当然这种情况确实需要考虑，你是对的。 |
有没有一种可能，同一句话可以有多个含义，若单独拎出来、脱离上下文，很难说它就是什么意思。
当然不是，如果是的话这么短一句话我直接打出来不就行了。就是因为情况非常复杂，我懒得描述了，所以让你多去看看了解下。 |
|
|
|
水墨近期日常 https://hostloc.com/thread-1188475-1-1.html 卖转发的，卖“专线”的近况。这位不是混mjj圈不了解业界建议不要回他了。我刚发现 rprx 说的真是符合近段时间vps圈现状，⑥ |
|
首先感谢你耐心的回复。 我总是推导在一定程度上是因为你没有一开始就把话说清楚，你把澄清的部分一开始就说了也就不需要澄清了。 另外你经常会补充很多与主题没有直接关联的背景，就我而言我很感谢你的补充，我的很多追问也是关于这部分。 讨论敏感话题注册小号是常规操作吧。以前没有注册是因为以前还没有讨论相关话题所需的基本的技术理解。抱歉给你带来不好的印象。 |
|
这个“我感觉你不这么认为”，
这句话之前我并不确定你说的“没封完”指什么，这句话说它包括“仍有协议能用”，恰恰说明了对某一协议/方式来说，“自己人”“用的多”并不是护身符，因为它不具有不可替代性，被封了人们就会用其它协议/方式，从这个角度来说严管 IPLC 也并不怎么伤“自己人” 还是简单说一下各协议 2023 现状（对于中国大多数地区）
所以你可以看到以前的流行协议在今年是什么样的存活状况，事实上今年自建的大都是新协议，非 IPLC 中转用的协议原理也没差 |
说下我个人的看法：TUIC协议版本V5出了一段时间了，在群里约一段时间前（印象中7-10天前）讨论热度很高时，有大于3人（靠印象）反映用了段时间客户端不通，换端口好。我当时还想我也测试过，运气好我没遇到。
12小时后测试，UDP443端口恢复了。能正常用了。 |
|
@chika0801 你遇到的应该是运营商限速，偶尔会给你的端口限到 0，表现就是服务端收不到包。GFW 认为你是翻墙的话，封你端口就不会短时间给你恢复了， |
|
@RPRX 我那台用Hy2协议的VPS，我会留着，我过段时间再用它。我这用UDP，我倒时没遇到过QoS，那天晚上突然遇到后，我还是激活了一些，是应该睡一觉再观察是否自行恢复的。听了你的看法，我也觉得你说的是对的。 现在我找了另一台VPS，是小众商家，非CN优化线路，我认为它的IP是干净的。我就只开TUIC最新版本协议来用，开8443端口。我的目的是测试下能不能遇到群友反应的用TUIC端口被封。 |
已遇到了。协议使用TUIC，客户端突然不通，查看服务端日志如下。此时修改服务端配置换一个端口，客户端配置也相应修改端口，立即就通了。
用Hy2的那台VPS，前几天日常用时，也有再次遇到UDP443端口突然不通（客户端表现就是连不上），我遇到后不继续用，明天来看它又自己恢复的现象。 我这地区我印象中，之前对UDP类的都很畅通（我之前都没遇到1次这种现象），有可能是我这地区的力度上来了吧。 |
如果我的理解没有问题的话，xtls 在满足条件时不会加密 tls 目标连接。如果构造钓鱼 tls 服务器，在正常完成 tls 握手后就开始发送特定数据，尽管数据会被客户端拒绝，但是数据内容对中间人可见，中间人通过过滤内容就可以识别与钓鱼服务器的连接。如果钓鱼服务器国内不能访问，那么只有通过 xtls 访问时特征数据才会经由国内网络传输，可以据此识别 xtls 服务器。
这种攻击需要客户端主动访问钓鱼服务器，但是如果将服务器链接作为自动加载的资源文件投放在国内常用网站，就有可能导致很多客户端在无意中访问。因为钓鱼服务器本来就不在国内，服务器端针对回国的分流无效。移动端的分应用代理有效，但是网页端分流也无效（不存在“分网页代理”，代理工具无法得知发起连接的网页）。
The text was updated successfully, but these errors were encountered: