Forwarded from Masoud
Interesting😁If the translation is correct
a few months ago when I was discussing the blocking of Reality by Iran's GFW in a group someone told me to use Reality through a SOCKS5, and it wouldn't get blocked
a few months ago when I was discussing the blocking of Reality by Iran's GFW in a group someone told me to use Reality through a SOCKS5, and it wouldn't get blocked
😁23
Telegram
M in Project X
U said a few times that iranians told that tls was unstable,this is weird cuase i never had any issues with tls personally,the only thing is some isp have weird sni rules(only some of them) and becuase of that, full random ss or plain http work better(sometimes)…
当我们建议面板删掉明文 HTTP 选项时，这就是一些伊朗人的理由之一
但是你那里 fully random SS 和 plain HTTP 都不封也很难绷啊，毕竟你们那 SS 就是裸奔，密码都被 plain HTTP 面板交给 GFW 了，直接解密
但是你那里 fully random SS 和 plain HTTP 都不封也很难绷啊，毕竟你们那 SS 就是裸奔，密码都被 plain HTTP 面板交给 GFW 了，直接解密
😁29⚡4👀1
Telegram
Frederic Liu in Project X
sb不至于吧，sb更新协议不是蛮快的吗，不过n9i最近忙着搞1.12和1.11的当下版本
不会加就是不会加，原产于 Xray 的协议总想着在其它软件上也能用，你们是有什么 NTR 的癖好吗，他们的实现、更新也是没有任何保证的
你要想安稳用 Xray 的协议就直接用 Xray，别整天想着整花里胡哨的
你要想安稳用 Xray 的协议就直接用 Xray，别整天想着整花里胡哨的
😁29👀4
Telegram
Keith Chai in Project X
是啊，ss2022和vmess都是全加密协议，vless出加密我有点不太理解
VLESS 的加密是抗量子公私钥，且不会增加 RTT，机制类似于 REALITY 的 session id，并且 GFW 拿到客户端公钥没用，服务端私钥不泄露就不会被解密，正好明文 HTTP 面板不更新了不然这私钥是保不住了
🔥32👍7😁6⚡1
Telegram
gh0st in Project X
There has been a lot of news and information about vmess encryption leaks, who else thinks that ss and vmess are secure, I sympathize with you. Vless protocol is not perfect, but with all the features that encrypt it can be so to speak, as the person wrote.
VMess 和 SS 的加密都是对称加密，无前向安全，GFW 拿到客户端密码就能把以前的所有流量都解密了，我几年前就强调过，让我来设计加密的话肯定是 REALITY 这种带公私钥的，REALITY 有 TLS 的前向安全，不过私钥一定不能泄露啊，所以面板明文 HTTP 传私钥是真的蠢
👍37😁2
Telegram
𝕆𝕓𝕛𝕖𝕔𝕥 𝕊𝕙𝕒𝕕𝕠𝕨 in Project X
REALITY 的确有 (与 TLS 一致的) 前向安全性
但是 VLESS 的加密层如果采用抗量子加密, 性能 (使用非对称加密) 会有很大损耗
但是 VLESS 的加密层如果采用抗量子加密, 性能 (使用非对称加密) 会有很大损耗
现在的抗量子指的是密钥交换阶段，后面仍是对称加密，不会增加损耗
👍9👀1
Telegram
𝕆𝕓𝕛𝕖𝕔𝕥 𝕊𝕙𝕒𝕕𝕠𝕨 in Project X
量子公钥太大了 以至于难以嵌入到 VLESS 目前所依赖的 TLS Handshake 里
你再去看看，Chrome 的 TLS 已经默认包含 X25519Kyber768 了
并且 VLESS 自身的加密和外层是啥没有关系
并且 VLESS 自身的加密和外层是啥没有关系
👍10
Telegram
O_o $_$ in Project X
但是golang的X25519MLKEM768似乎没搞完🧐
我看了下 Go 1.24 有这个，上述 VLESS 加密有望这几天推出
我现在只担心 Chrome 也改成这个后，已经停更的 uTLS 是个问题
我现在只担心 Chrome 也改成这个后，已经停更的 uTLS 是个问题
👍16🎉2
Telegram
𝕆𝕓𝕛𝕖𝕔𝕥 𝕊𝕙𝕒𝕕𝕠𝕨 in Project X
好 明白了 最开始误解了
我以为是给 VLESS 单独添一个加密层
我以为是给 VLESS 单独添一个加密层
是单独添一个加密层，目前决定用抗量子的 X25519MLKEM768
1-RTT 的话有前向安全，0-RTT 的话私钥不泄露也是安全的，别明文传
1-RTT 的话有前向安全，0-RTT 的话私钥不泄露也是安全的，别明文传
👍14🎉1👀1
Telegram
𝕆𝕓𝕛𝕖𝕔𝕥 𝕊𝕙𝕒𝕕𝕠𝕨 in Project X
私钥不泄漏确实是安全的
但是如果采用了 TLS13 的会话恢复 如何应对重放?
但是如果采用了 TLS13 的会话恢复 如何应对重放?
我觉得倒是可以设计成会话恢复，至于防重放很简单，我本来在 SS 那边说的是给明文结构加个时间戳，但这个被 SS2022 用了我就不想用了，我觉得我可以发明一个滑动窗口防重放、无需对时
还有 VLESS 加密只考虑加密安全，不考虑对付 GFW，这不是它的用途
还有 VLESS 加密只考虑加密安全，不考虑对付 GFW，这不是它的用途
👍17😁2👀2
Telegram
𝕆𝕓𝕛𝕖𝕔𝕥 𝕊𝕙𝕒𝕕𝕠𝕨 in Project X
滑动窗口 无需对时🤔怎么说?
比如说只记录 100 个连接头以防重放，一开始是第 1-100 条连接，后面慢慢滑到第 201-300 条连接，小于 201 的就直接扔了，无需对时
👍12
Telegram
𝕆𝕓𝕛𝕖𝕔𝕥 𝕊𝕙𝕒𝕕𝕠𝕨 in Project X
我的意思不是避免重放带来的影响
而是如何向重放方应答 以免暴露
而是如何向重放方应答 以免暴露
都 2025 年了还想着用非 TLS 加密过墙呢？VLESS 加密不是给 GFW 看的
😁17
Telegram
𝕆𝕓𝕛𝕖𝕔𝕥 𝕊𝕙𝕒𝕕𝕠𝕨 in Project X
stateful 不是恰当的实现方法
假如服务端会重启?
假如服务端会重启?
你在群里的一系列发言有点雷人，因为你想错了，我们说的窗口都是依附于第一次的完整握手，肯定不是整个服务器共用的
👍8
Telegram
𝕆𝕓𝕛𝕖𝕔𝕥 𝕊𝕙𝕒𝕕𝕠𝕨 in Project X
但是这我也不好理解
TLS 已经做防重放了
TLS 已经做防重放了
TLS 的 0-RTT 不防重放，上层 HTTP GET 时才会用，POST 不会用
👍7
Telegram
风扇滑翔翼 in Project X
我的意思是滑都不用滑 只需要记忆一个票据下的已用的id就行了 开销很低
缺点就是有复用次数限制，其实滑起来也很简单，比如只允许最新序号减 100 以内的包，每次收到序号更大的包就 range map 把该请的清掉
或者固定时间比如每一分钟清一次，这样开销就更低了，可以忽略不计
或者固定时间比如每一分钟清一次，这样开销就更低了，可以忽略不计
👍9