Forwarded from GitHub
💬 New comment on BBS#13 ECH先遣服:搭建修改HTTPS记录的DoH服务,强制为Cloudflare CDN与Meta CDN开启ECH功能
by @RememberOurPromise
Cloudflare官方备案网站,可获取ECHconfig
科赋锐(北京)信息科技有限公司
京ICP备2020045912号-14
~依法合规上网,XD~
Reply to this message to post a comment on GitHub.
by @RememberOurPromise
Cloudflare官方备案网站,可获取ECHconfig
cloudflarestaging.com科赋锐(北京)信息科技有限公司
京ICP备2020045912号-14
~依法合规上网,XD~
Reply to this message to post a comment on GitHub.
😁60👍6👀3❤1
Project X
用reality你怎么抓
说到隐蔽性,最近想到了 XDRIVE 还有一个重要的特性是 中转机器上并不存在 Xray,比如说你可以拿国内 VPS 开个 FTPS,境内外两端主动连上它以传输数据,FTPS 支持流式边传边读、延迟有保障,且端口和主动探测都是 FTP,你在国内 VPS 上开个 FTP 传文件本来就很合理,“境外主动连上境内”这一行为还在 gfw 盲区,只是仍上下行对等
SSH 虽然也有这一特性但它本来就支持端口映射,所以你在干啥就不好解释了,且它的端口映射有比较明显的流量特征
👍33❤8⚡4👀2
Project X Channel
Photo
大家要有个概念,用户提需求虽不是 GFW 用户,但这些用户不捐钱就属于负价值用户,这种用户和 GFW 用户本质上没有区别。
😁54👀5❤1👍1
Project X
走了走了,吃完饭去。iOS这个话题,我就不该张口,反正享受福报的不是我。说了什么角度都要被攻击,哪有就事论事的理性交流,全是感情,全是先阵营对立
👍29😁12⚡2
Forwarded from Project X Channel
🎉13👍3
Forwarded from Yaka
Project X Channel
但是没有前向安全的话你手机一交,历史流量全解密,非 TLS 就福报了 https://github.com/XTLS/BBS/issues/2
那肯定,但就算要查手机肯定也是优先查手机上应用列表读取到翻墙软件的😁
😁23👀1
Forwarded from miruo xo
pqc这些安全升级...比优化现实上门维度更可控更直接。
这不就和自建机房需要考虑水电网和硬件老化,但是买云服务不需要考虑基础设施一样...不是一个维护的🙈
这不就和自建机房需要考虑水电网和硬件老化,但是买云服务不需要考虑基础设施一样...不是一个维护的🙈
👍9
Forwarded from Yaka
Project X Channel
pqc这些安全升级...比优化现实上门维度更可控更直接。 这不就和自建机房需要考虑水电网和硬件老化,但是买云服务不需要考虑基础设施一样...不是一个维护的🙈
但运营商app内置个读应用列表的功能真的一点成本都没有(
😁12👍5
Forwarded from Project X Channel
Project X Channel
但运营商app内置个读应用列表的功能真的一点成本都没有(
😁24❤2
Forwarded from AI在线解析总结视频 - 阿音兄弟👬🏻 (DC5)
This media is not supported in your browser
VIEW IN TELEGRAM
✅ Group video description display turned off
👀18👍9❤2
Forwarded from Project X Channel
Project X Channel
✅ Group video description display turned off
😁20
Forwarded from M
Yes,for now i can only access internet with dns tunnels
👍35🔥7
Forwarded from Nikita Korotaev
About a month ago, when Iran experienced serious disruptions in Internet access, the XTLS team closely monitored the situation and collected data on methods that were actually effective in bypassing the restrictions.
The analysis showed that in aggressive network environments, the solutions we normally rely on are sometimes insufficient for maintaining stable connectivity. In a number of cases, additional obfuscation mechanisms were required, for example mimicking DNS traffic, ICMP, or other protocols permitted within the country.
At that time, implementing new obfuscation methods directly in the core was an extremely labor-intensive process. For instance, disguising traffic as DNS or ICMP would have effectively required implementing a full-fledged transport protocol from scratch.
As a result, the idea was proposed to completely decouple data delivery from packet obfuscation, and a new concept called finalmask was introduced into the core.
The final masking layer represents the lowest, unreliable layer. For UDP, it only performs per-packet obfuscation and does not provide reliable delivery. Reliability is handled by the upper layer.
The responsibility model can now be structured as follows:
Protocol: encryption and authentication.
Transport: fragmentation, retransmission, and congestion control.
Finalmask: a stack of stateless masks that sequentially wrap the packet before transmission.
For clarity, we need to distinguish between several key concepts:
header-: simply attaches a fake header to a packet.
x: actually encapsulates and transmits data through the structure of the target protocol.
xDNS: allows traffic to be tunneled inside legitimate DNS queries.
Since it is an X* protocol, xDNS generates fully standards-compliant packets.
Its implementation is straightforward.
Client side:
The data stream is split into small chunks and encoded. These chunks are then divided into 63-byte labels and assembled into an FQDN of the form:
[N].[N+1].[domain]
The result is encoded in DNS wire format.
Server side:
The server extracts the data and packs the response into a TXT answer record.
The analysis showed that in aggressive network environments, the solutions we normally rely on are sometimes insufficient for maintaining stable connectivity. In a number of cases, additional obfuscation mechanisms were required, for example mimicking DNS traffic, ICMP, or other protocols permitted within the country.
At that time, implementing new obfuscation methods directly in the core was an extremely labor-intensive process. For instance, disguising traffic as DNS or ICMP would have effectively required implementing a full-fledged transport protocol from scratch.
As a result, the idea was proposed to completely decouple data delivery from packet obfuscation, and a new concept called finalmask was introduced into the core.
The final masking layer represents the lowest, unreliable layer. For UDP, it only performs per-packet obfuscation and does not provide reliable delivery. Reliability is handled by the upper layer.
The responsibility model can now be structured as follows:
Protocol: encryption and authentication.
Transport: fragmentation, retransmission, and congestion control.
Finalmask: a stack of stateless masks that sequentially wrap the packet before transmission.
For clarity, we need to distinguish between several key concepts:
header-: simply attaches a fake header to a packet.
x: actually encapsulates and transmits data through the structure of the target protocol.
xDNS: allows traffic to be tunneled inside legitimate DNS queries.
Since it is an X* protocol, xDNS generates fully standards-compliant packets.
Its implementation is straightforward.
Client side:
The data stream is split into small chunks and encoded. These chunks are then divided into 63-byte labels and assembled into an FQDN of the form:
[N].[N+1].[domain]
The result is encoded in DNS wire format.
Server side:
The server extracts the data and packs the response into a TXT answer record.
👍37❤8⚡3🔥3
Forwarded from Sorcerer
最近公司里不少用cursor的,但是cursor在国内只能用那几个垃圾模型,我就想在vps上弄个转发程序,转发一下api2.cursor.sh。然后我突然想到,reality不就对外表现成端口转发吗?直接reality偷api2.cursor.sh,再改一下本机hosts,果然就能用opus4.6了。给了几个同事一块用,正好可以骗骗公司的流量审计,以后正大光明的用reality翻墙
😁75🔥13👀3
Forwarded from GitHub
💬 New comment on Xray-core#5581 Geodat: Reduce peak memory usage
by @RPRX
感谢 @fortuna 提供有价值的参考资料,伊朗的民间互联网出境被完全切断时,只能依赖 DNSTT、XDNS 这类基于真实 DNS TXT 查询的隧道(利用了运营商自用的互联网出境线路),若商用互联网出境未被切断,则还可以使用 XHTTP 加境内 CDN
XDRIVE 要等伊朗的民间互联网开放了一些网站才能用,一个月前开放的是 Google、OpenAI 等,或者如果能从境外访问到伊朗境内的商用互联网,理论上也可以利用境内的网盘、付费存储等服务,[或者自己搭个 FTPS,境内 VPS 上并不存在 Xray](https://github.com/XTLS/Xray-core/pull/5645#issuecomment-3980000253)
我觉得 XDRIVE 在技术上不存在大问题(即使是利用 ChatGPT 中转),而是免费服务商可能的封禁,当然如果是付费的比如阿里云 OSS 等兼容 S3 的存储服务则不会以“超过频率”这一理由拒绝提供服务,而是境内的服务商可能会配合 GFW 试图封它
比较有趣的一点是 XDRIVE 被设计为使用 Xray 的通用 TLS 设置以支持 domain fronting,https://github.com/XTLS/Xray-core/pull/5645#issuecomment-3851839033 提到的给 www.googleapis.com 发 www.google.com 的 SNI 其实可能会导致返回默认证书,这种情况可以用 verifyPeerCertByName
Reply to this message to post a comment on GitHub.
by @RPRX
感谢 @fortuna 提供有价值的参考资料,伊朗的民间互联网出境被完全切断时,只能依赖 DNSTT、XDNS 这类基于真实 DNS TXT 查询的隧道(利用了运营商自用的互联网出境线路),若商用互联网出境未被切断,则还可以使用 XHTTP 加境内 CDN
XDRIVE 要等伊朗的民间互联网开放了一些网站才能用,一个月前开放的是 Google、OpenAI 等,或者如果能从境外访问到伊朗境内的商用互联网,理论上也可以利用境内的网盘、付费存储等服务,[或者自己搭个 FTPS,境内 VPS 上并不存在 Xray](https://github.com/XTLS/Xray-core/pull/5645#issuecomment-3980000253)
我觉得 XDRIVE 在技术上不存在大问题(即使是利用 ChatGPT 中转),而是免费服务商可能的封禁,当然如果是付费的比如阿里云 OSS 等兼容 S3 的存储服务则不会以“超过频率”这一理由拒绝提供服务,而是境内的服务商可能会配合 GFW 试图封它
比较有趣的一点是 XDRIVE 被设计为使用 Xray 的通用 TLS 设置以支持 domain fronting,https://github.com/XTLS/Xray-core/pull/5645#issuecomment-3851839033 提到的给 www.googleapis.com 发 www.google.com 的 SNI 其实可能会导致返回默认证书,这种情况可以用 verifyPeerCertByName
Reply to this message to post a comment on GitHub.
👍7❤4👀4😁1