XTLS
上游 xtls 的 23 3 3 漏洞问题
见 https://github.com/XTLS/Go/issues/17
不一定对，但是值得关注
如果这个漏洞成立的话，那么我们即刻起就不应该在未来版本中添加xtls/go 的支持
现在helloword/passwall/ssr+后端好像用的都是xray 不过没关系啦，设备够强tls就行了
不过话说，你有没有试着攻击自己的vps😏
现在helloword/passwall/ssr+后端好像用的都是xray 不过没关系啦，设备够强tls就行了
不过话说，你有没有试着攻击自己的vps😏
肯定不敢攻击自己vps啊！如果 测试者 的流量被墙捕获，墙如果看了我的博文，那不就知道哪个vps是 测试者 的，且 测试者 使用了xtls了吗？？
这个时候，只有勇士才敢攻击自己vps。唯一的可能是在内网里测试，但是我为什么要测试呢？我很相信我自己，只有认为我的分析有问题的人才回去测试。
当然，我没说过说我在墙内，所以 如果我是 测试者，测试者 是有可能不怕墙知道 测试者 的vps存在的。
还有，我什么时候说我的 vps使用了xtls？
还有，我什么时候说我有vps了？
用vps翻这个事情其实本身是没问题的，要不然油管上那么多up主都得凉 只要不做坏事就好了，别怕别怕。窃以为自己一个人在家看P站也没事
啊对了，没有的话，打开github很慢的哟，甚至打不开的哟~
To me, it doesn't seem to be a valid security hole in xtls. If you have the original access to the proxy server, there are many ways to break the service. If you can trick other users to click a link, there are also many bad things you can do. Causing some loop in server only will waste some cpu cycles.
To me, it doesn't seem to be a valid security hole in xtls. If you have the original access to the proxy server, there are many ways to break the service. If you can trick other users to click a link, there are also many bad things you can do. Causing some loop in server only will waste some cpu cycles.
那主动探测呢？墙可以主动向可疑ip进行主动233 探测
To me, it doesn't seem to be a valid security hole in xtls. If you have the original access to the proxy server, there are many ways to break the service. If you can trick other users to click a link, there are also many bad things you can do. Causing some loop in server only will waste some cpu cycles.
还有，你的 “loop in server" 少个 the, in the server, 然后 if you have the original， 应该把the 去掉。
主要是因为， “original access”并不是特指
另外，知道uuid并不是就是有对服务器的访问权限啊！难道你能ssh？
1MB可以循环一百万次，你叫 some cycles，哦，原来一百万次只是some，懂了
大意失荆州
如果我是大厂的 code reviewer, 你是我的下属，我发现问题后，你给我这么回答，请问我会怎么做呢 ? 在安全性要求这么高的翻墙场合中，你如此大意，你的工资评定可以好好期待了。
总之，我下列的建议应该没有异议：
- 在xray的页面，醒目位置，标注，xtls协议已经不建议机场使用
- 在醒目位置标明，可能会被墙探测到，并不建议在安全要求较高的场合使用，并给出 XTLS/GO 项目的 issue12, issue16, issue17 的链接
https://github.com/XTLS/Go/issues/12 https://github.com/XTLS/Go/issues/16 https://github.com/XTLS/Go/issues/17
有能力自己修，搁着阴阳怪气啥呢。怕不安全大可不用
没有能力难道不能阅读代码，提出issue了吗？难道漏洞只能由开发者发现，其他人必须无脑用，不检查代码吗？难道每个人都有能力修吗？到底谁在阴阳怪气？
我当然不用xtls了，这是专门给大家提个醒。
有能力自己修，搁着阴阳怪气啥呢。怕不安全大可不用
没有能力难道不能阅读代码，提出issue了吗？难道漏洞只能由开发者发现，其他人必须无脑用，不检查代码吗？难道每个人都有能力修吗？到底谁在阴阳怪气？
我当然不用xtls了，这是专门给大家提个醒。
宁前面说的当然都可以，但是宁这口气就让人感觉宁很nb似的。
有能力自己修，搁着阴阳怪气啥呢。怕不安全大可不用
典型的： 你说电影演的烂人家说有本事你来演， 你说这才不好吃人家说有本事你来做啊， 你说这车不好开人家说有本事你来造啊， 你说这个女孩性格不好人家说你来生？ 你说这个软件有漏洞人家说你来写个没漏洞的啊或者你来修啊
有能力自己修，搁着阴阳怪气啥呢。怕不安全大可不用
典型的： 你说电影演的烂人家说有本事你来演， 你说这才不好吃人家说有本事你来做啊， 你说这车不好开人家说有本事你来造啊， 你说这个女孩性格不好人家说你来生？ 你说这个软件有漏洞人家说你来写个没漏洞的啊或者你来修啊
键盘侠，就服你。从此我不再在xray社区发言。显然，xray社区不欢迎提出任何问题，必须要附带解决办法才行。我早在文中写过了，你都不看我的文章，我文中的意思就是不管怎么修复，xtls都终将出现新bug。
从此，我不再在xray发言。没准以后我会自己搞一个新社区。目前我会为v2ray效力。
看完上面的回复，难怪XTLS/Go几个严重issue都没有人管，原来是对自己盲目的自信，Xray在闭门造车啊，真是令我大开眼界
在这楼里居然还能看到不许别人提出问题的人，垃圾请在tg垃圾场里发言，不要来github
有能力自己修，搁着阴阳怪气啥呢。怕不安全大可不用
说你是傻逼一点都不为过
有能力自己修，搁着阴阳怪气啥呢。怕不安全大可不用
典型的： 你说电影演的烂人家说有本事你来演， 你说这才不好吃人家说有本事你来做啊， 你说这车不好开人家说有本事你来造啊， 你说这个女孩性格不好人家说你来生？ 你说这个软件有漏洞人家说你来写个没漏洞的啊或者你来修啊
键盘侠，就服你。从此我不再在xray社区发言。显然，xray社区不欢迎提出任何问题，必须要附带解决办法才行。我早在文中写过了，你都不看我的文章，我文中的意思就是不管怎么修复，xtls都终将出现新bug。
从此，我不再在xray发言。没准以后我会自己搞一个新社区。目前我会为v2ray效力。
你为什么要伤害友军
看完上面的回复，难怪XTLS/Go几个严重issue都没有人管，原来是对自己盲目的自信，Xray在闭门造车啊，真是令我大开眼界
在这楼里居然还能看到不许别人提出问题的人，垃圾请在tg垃圾场里发言，不要来github
有能力自己修，搁着阴阳怪气啥呢。怕不安全大可不用
说你是傻逼一点都不为过
这个算好的了，我之前发xtls的issue还有人直接上来就骂
后来2楼那个秀英文的contributor还关了issue
PS：说骂人话不要打汉字，我们要翻译成韩文🤭
有能力自己修，搁着阴阳怪气啥呢。怕不安全大可不用
典型的： 你说电影演的烂人家说有本事你来演， 你说这才不好吃人家说有本事你来做啊， 你说这车不好开人家说有本事你来造啊， 你说这个女孩性格不好人家说你来生？ 你说这个软件有漏洞人家说你来写个没漏洞的啊或者你来修啊
键盘侠，就服你。从此我不再在xray社区发言。显然，xray社区不欢迎提出任何问题，必须要附带解决办法才行。我早在文中写过了，你都不看我的文章，我文中的意思就是不管怎么修复，xtls都终将出现新bug。
从此，我不再在xray发言。没准以后我会自己搞一个新社区。目前我会为v2ray效力。
连友军都攻击，不愧是你。赶紧去打针吧
有能力自己修，搁着阴阳怪气啥呢。怕不安全大可不用
典型的： 你说电影演的烂人家说有本事你来演， 你说这才不好吃人家说有本事你来做啊， 你说这车不好开人家说有本事你来造啊， 你说这个女孩性格不好人家说你来生？ 你说这个软件有漏洞人家说你来写个没漏洞的啊或者你来修啊
键盘侠，就服你。从此我不再在xray社区发言。显然，xray社区不欢迎提出任何问题，必须要附带解决办法才行。我早在文中写过了，你都不看我的文章，我文中的意思就是不管怎么修复，xtls都终将出现新bug。
从此，我不再在xray发言。没准以后我会自己搞一个新社区。目前我会为v2ray效力。
别开枪 我我。。我是友军
都烦不烦 ，哪有那么多功夫嘴炮，有bug 就提交，有能力的就修复，没能力的闭嘴看着，逼逼那么多有什么用 ？
确实，有的人bug也不提交，也不会去修复，而且不闭嘴，还要上来逼逼
看上去好像是个理中客，其实连自己都骂，活成了自己讨厌的样子，是吧？？？ @Uhtred009
有能力自己修，搁着阴阳怪气啥呢。怕不安全大可不用
典型的： 你说电影演的烂人家说有本事你来演， 你说这才不好吃人家说有本事你来做啊， 你说这车不好开人家说有本事你来造啊， 你说这个女孩性格不好人家说你来生？ 你说这个软件有漏洞人家说你来写个没漏洞的啊或者你来修啊
键盘侠，就服你。从此我不再在xray社区发言。显然，xray社区不欢迎提出任何问题，必须要附带解决办法才行。我早在文中写过了，你都不看我的文章，我文中的意思就是不管怎么修复，xtls都终将出现新bug。 从此，我不再在xray发言。没准以后我会自己搞一个新社区。目前我会为v2ray效力。
别开枪 我我。。我是友军
啊，你是吗？反正我看一大长串就直接认为键盘侠了，而且这里键盘侠很多是吧。
总之我很忙，偶尔看到一大段很多带问号的，而且和issue毫无意义的语句，直接就很生气。看你的问好最多，正好激起我的情绪。本来早就准备不在xray发言了，就正好回复给你。
以后发言能不能围绕着如何修复bug，而不是围绕着互喷。无论是友军也好，敌军也好，能不能放下武器。
提高个人素质，提高社区整体修养，抓紧时间修复问题，尽自己所能。好了我就说这么多。不要再刷屏了。
按照你的文章，不必如此，将streamSettings设置为tls即可，可以继续使用direct和splice流控，服务端也要做相应修改，确保XTLS的特殊功能没有启动。
我觉得应该不会有人差那点加密开销吧。
实际上现在project X群里更多推荐grpc搭配好线路或者直接上hysteria，XTLS的握手延迟在群里饱受诟病，要不就直接ss，如果不嫌经常换IP麻烦的话。
如果一定要标注，我觉得应该直接推荐使用grpc，增强安全性本来就是引入grpc的原因之一，其次是改streamSettings
按照你的文章，不必如此，将streamSettings设置为tls即可，可以继续使用direct和splice流控，服务端也要做相应修改，确保XTLS的特殊功能没有启动。
@CCCAUCHY 你好，我有点疑问，不使用 xTLS 时也支持设置 "flow": "xtls-rprx-direct" 吗？能否给个配置示例，谢谢。
按照你的文章，不必如此，将streamSettings设置为tls即可，可以继续使用direct和splice流控，服务端也要做相应修改，确保XTLS的特殊功能没有启动。
@CCCAUCHY 你好，我有点疑问，不使用 xTLS 时也支持设置
"flow": "xtls-rprx-direct"吗？能否给个配置示例，谢谢。
比如在qv2中，不能直接把原本为XTLS的配置简单在GUI修改，还需要打开json，将所有streamSettings下的XTLS相关项目改为tls，我还没有进行性能测试，服务端保险起见也要修改
按照你的文章，不必如此，将streamSettings设置为tls即可，可以继续使用direct和splice流控，服务端也要做相应修改，确保XTLS的特殊功能没有启动。
@CCCAUCHY 你好，我有点疑问，不使用 xTLS 时也支持设置
"flow": "xtls-rprx-direct"吗？能否给个配置示例，谢谢。
看了 官方文档 后我的理解是，flow: string 只能配合 xTLS 使用。如果不使用 xTLS 的话，流控其实是不生效的……
不知道我理解得对不对。
flow: string 流控模式，用于选择 XTLS 的算法。
注意 当 flow 被指定时，还需要将该出站协议的 streamSettings.security 一项指定为 xtls，tlsSettings 改为 xtlsSettings。详情请参考 streamSettings。
关于 Splice 模式 Splice 是 Linux Kernel 提供的函数，系统内核直接转发 TCP，不再经过 Xray 的内存，大大减少了数据拷贝、CPU 上下文切换的次数。
此处循环不算漏洞，更无法被主动探测，说明详见 https://github.com/XTLS/Go/issues/17#issuecomment-1446073606
都是些什么东西
