关于 23 3 3 判断部分的 代码特征的利用漏洞 about go HOT 12 CLOSED

首先，暂不论该方法有没有用，若想让 TLS 服务端不断循环，有更通用的方法、对任何 TLS 服务端均生效，根本不需要这么麻烦。
事实上，循环的代码到处都是，包括操作系统的网络栈本身，按你的标准岂不都算是漏洞了？有必要只揪着这里的循环不放吗？

其次，之前我没有理你，是因为你写的东西中基础错误都非常多，基础错误又推出层层错误，我实在没有时间浪费在你身上。

我只能给你说几个关键点：

是不是233数据解密一定会失败？

		case aead:
			if len(payload) < explicitNonceLen {
				return nil, 0, alertBadRecordMAC
			}
			nonce := payload[:explicitNonceLen]
			if len(nonce) == 0 {
				nonce = hc.seq[:]
			}
			payload = payload[explicitNonceLen:]

			var additionalData []byte
			if hc.version == VersionTLS13 {
				additionalData = record[:recordHeaderLen]
			} else {
				additionalData = append(hc.scratchBuf[:0], hc.seq[:]...)
				additionalData = append(additionalData, record[:3]...)
				n := len(payload) - c.Overhead()
				additionalData = append(additionalData, byte(n>>8), byte(n))
			}

			var err error
			plaintext, err = c.Open(payload[:0], nonce, payload, additionalData)
			if err != nil {
				return nil, 0, alertBadRecordMAC
			}

出现一个 23 3 3 0 0 就会导致解密失败、TLS alert、断连，你这方法自己都没验证过能持续多久就着急搞个大新闻？

233 攻击 用于主动探测的办法

相关代码只存在于服务端验证了客户端 UUID 后，故无法被主动探测，此贴终结。

关于MPL ... 要求修改后的代码版权归软件的发起者 ... 你要这个版权是想要干啥呢？

MPL 要求修改后的代码保持 MPL+，即仍为自由软件，任何人都能用，不是要求你把版权给我，看不懂英文建议少看垃圾资料。

from go.

因为现在rprx已经半年没有新的研发动作（失去联系）了，如果发现了xtls 有没有修复的bug，建议大佬可以帮助大家找到可行靠谱的解决方法，修复这个bug，让这个悬而未决的bug早日得到修复，这样对于使用者和开发者来说都是皆大欢喜的一件事情；同是开发协议，我想大家初心各异但方向都是相同的，希望各位开发者能在这愈加寒冷的冬日里守望相助、相互鼓励；最后，希望大家在这冬日里能平安顺遂，万事如意

from go.

现在嘴炮的人物特别多，哈哈提BUG也要小心被喷

from go.

相当有见解的文章。

说实话不好解决，但也不能回避这个问题。

也许在其他领域，xtls能发挥所长吧。

from go.

关于该漏洞的解决也是不难的，因为又不是必须要循环才能探测到23 3 3. 我们直接探测数据头部就行吧。

在我的新项目 https://github.com/e1732a364fed/v2ray_simple 中实现了 新版的 非魔改tls 的 splice，就是使用的新的tls探测方式，无需循环。

然而，verysimple的splice依然会遇到 一些 alert方面的问题，所以 这种 对拷直连的问题依然是不安全的，还是参考 issue12 和 16; 看起来似乎issue12只要不使用origin就行，但是issue16就不知了。总之 我还是要再学习一下tls 的alert问题，才能对alert的issue进行继续讨论；

不过本issue的话总之解决是不难的。删掉循环即可。

from go.

rprx已经被网暴到退网了 做个代理软件，里面的人各怀鬼胎 见识了有人的地方就是江湖 真是一点都不和谐呢。

from go.

感谢报告可能的问题 新流控应当修复了 XTLS/Xray-core#1235

from go.

感谢报告可能的问题 新流控应当修复了 XTLS/Xray-core#1235

感谢。我简单看了一下，应该是类似我说的机制，在tls包外进行过滤是吧。不错。不过 我瞄了一眼，是不是过滤机制太简单了，很容易被利用吧。

from go.

感谢报告可能的问题 新流控应当修复了 XTLS/Xray-core#1235

感谢。我简单看了一下，应该是类似我说的机制，在tls包外进行过滤是吧。不错。不过 我瞄了一眼，是不是过滤机制太简单了，很容易被利用吧。

目前的方法是越简单代码越少越好 如果大佬发现有新漏洞或者更好的过滤方法一起研究啊

from go.

感谢报告可能的问题 新流控应当修复了 XTLS/Xray-core#1235

感谢。我简单看了一下，应该是类似我说的机制，在tls包外进行过滤是吧。不错。不过 我瞄了一眼，是不是过滤机制太简单了，很容易被利用吧。

目前的方法是越简单代码越少越好 如果大佬发现有新漏洞或者更好的过滤方法一起研究啊

过滤太简单，那么攻击方式和 之前的 233 问题如出一辙。不过因为没有循环了，所以不是为了导致宕机，只是攻击后即可确认你使用了这个vision流控

from go.

最近有一些内部爆料不知 @e1732a364fed 有没有关注，我印象比较深的一个是审查者跟新加坡合作，在服务器端检测和收集流量。他们可能用这些方式收集 telegram 用户时序信息，以及收集一些机器学习的样本。假如有vps的进出流量都可以记录，那毫无疑问可以找到代理。我认为我们应该假设审查者无法掌控代理服务端和目标地址的情况下，讨论攻击和识别的问题。

from go.

最近有一些内部爆料不知 @e1732a364fed 有没有关注，我印象比较深的一个是审查者跟新加坡合作，在服务器端检测和收集流量。他们可能用这些方式收集 telegram 用户时序信息，以及收集一些机器学习的样本。假如有vps的进出流量都可以记录，那毫无疑问可以找到代理。我认为我们应该假设审查者无法掌控代理服务端和目标地址的情况下，讨论攻击和识别的问题。

我讲过，不需要知道代理的任何信息就可以进行攻击。不过类似于蜘蛛结网，需要你主动访问布置好的网站。

from go.