bbs
bbs copied to clipboard
net4people
Looking for: A good paper on how TLS-in-TLS detection works?
related to #280, it got me thinking about TLS-in-TLS: I wonder if ECH and/or GREASE in the inner layer would (temporarily) confuse those heuristics.
but then, i realized, i have no idea how TLS-in-TLS is detected today. is there an (english) summary of it?
I only see some vague allusions towards it at https://github.com/XTLS/Xray-core/discussions/1295 (google translate) which talks about packet sizes and timings being detectable via machine learning. But it's not very concrete about how this detection works (I think it's a good read regardless)
I wonder if ECH and/or GREASE in the inner layer would (temporarily) confuse those heuristics.
No.
几个月前有一篇研究 TLS in TLS 握手特征的论文（至今尚未发布），它的作者找到了我和 @yuhan6665 ，我提了一些修改建议
这篇论文也让我们意识到了实现 Vision Seed 的紧迫性，正好近期我们就在开发它，我还会给 Trojan-killer 加上原理说明等
A few months ago, the author of a paper on TLS in TLS handshake characterization (which has not yet been published) reached out to me and @yuhan6665, and I suggested some changes.
This paper also made us realize the urgency of implementing Vision Seed, which we've been working on for a while now, and I'll be adding a rationale to Trojan-killer, etc.
I wonder if ECH and/or GREASE in the inner layer would (temporarily) confuse those heuristics.
No.
几个月前有一篇研究 TLS in TLS 握手特征的论文（至今尚未发布），它的作者找到了我和 @yuhan6665 ，我提了一些修改建议
这篇论文也让我们意识到了实现 Vision Seed 的紧迫性，正好近期我们就在开发它，我还会给 Trojan-killer 加上原理说明等
If I understand correctly, The paper actually states that protocols like XTLS Vision that simply add padding to the connection header don't work in their own homemade TLS in crypto recognition model, and there is currently no evidence that GFW applies such checks either. In other words, not only is the protocol complex and undefined, it is also meaningless for anti-censorship purposes.
Your Trojan-killer simply checks the first packet length and claims to have no false positives on your own device. For the doubter, you even said that you don't know how to open a .pcap file.
Using Chinese to promote your project in the anti-censorship community and exaggerating the dangers of TLS in crypto traffic characteristics actually does not help understanding GFW.
If I understand correctly, The paper actually states that protocols like XTLS Vision that simply add padding to the connection header don't work in their own homemade TLS in crypto recognition model, and there is currently no evidence that GFW applies such checks either. In other words, not only is the protocol complex and undefined, it is also meaningless for anti-censorship purposes.
首先我认为，你在看了别人未发表的文章后，公开说这篇文章是什么内容是不合适的。你的描述仅是这篇文章内容的一部分且并不准确，但我若说太多就是揭示了更多的内容，包括他的测试方法、其它协议的数据以及数据之间的对比。我最多能透露，根据作者的说法，通用 TLS in TLS 握手检测模型对 Vision 的强 padding 效果非常差，只能“协议倒模”，而这就是 Seed 要解决的问题之一。
然后“either”这个词，我补充一下背景，这位朋友说 TLS in TLS 检测是炒作，还有一个人说是骗流量，所以我就写了 Trojan-killer，仅为了揭示确实存在的问题。你我都清楚 Vision 和 Trojan 的区别，也清楚 Trojan 的反馈经常是一天封一个端口，不知道这种大规模的用户实测能否作为你要的“evidence”？此外不要忘记，就是在这里出现的“内鬼”说的 GFW 已经部署了这种检测，或许他不一定可信，然而我证明了我们自己就能检测，还有大规模的用户实测作为佐证。
First of all I don't think it's appropriate for you to say publicly what this article is about after reading someone else's unpublished article. Your description is only part of the article and is not accurate, but to say too much would be to reveal much more, including his testing methodology, data from other protocols, and comparisons between the data. The most I can reveal is that, according to the author, the generic TLS in TLS handshake detection model is so ineffective against Vision's strong padding that it can only be "protocol inverted", which is one of the problems Seed is trying to solve.
And the word "either", let me add a little background, this person said that TLS in TLS detection is hype, and another person said that it's a traffic scam, so I wrote Trojan-killer just to reveal that there is a real problem. You and I both know the difference between Vision and Trojan, and we both know that Trojan's feedback is often one port a day, so I wonder if this large-scale user testing is the "evidence" you're looking for? Also, don't forget that the " insider " who appeared here said that GFW has already deployed this kind of detection, maybe he may not be credible, but I proved that we can detect it by ourselves, and there is a large-scale user testing as a proof.
Your Trojan-killer simply checks the first packet length and claims to have no false positives on your own device. For the doubter, you even said that you don't know how to open a .pcap file.
并不是仅首包，而是“客户端 CCS（包括）后、服务端发数据前，客户端所发的数据量总和”，以及“客户端再次发数据前，服务端所发的数据量总和”，所以其实我的检测限制的是时序条件。并不是“no false positives”，而是约千分之一（Tun 模式）。
至于你所说的“doubter”，他公然告诉我们“如果靠一个简单的size匹配能过滤全部tls流量，那么密码学的基础就不存在了”，这句话的水平我就请各位自行评判，我已经评价过了。那个文件当时我确实等了半天都没能打开，那段时间我的 WireShark 一直很卡，后来重装系统发现应该是之前我为了抓 Chrome 的包，开了导出密钥供 WireShark 解密，它是一直积累的，时间长了就很卡。
It's not just the first packet, it's "the sum of the amount of data sent by the client after the client's CCS (inclusive) and before the server sends the data" and "the sum of the amount of data sent by the server before the client sends the data again", so really what I'm restricting my detection to is the Timing condition. Not "no false positives", but about 1 in 1000 (Tun mode).
As for your "doubter", he blatantly told us that "if a simple size match can filter all tls traffic, then the foundation of cryptography doesn't exist", I'll leave it to you to judge the level of this statement, I've already done so. I've already done that. I did wait for half a day to open that file, and during that time my WireShark had been very stuck, and then I reinstalled my system and realized that I had opened the export key for WireShark to decrypt in order to capture Chrome packets, and it had been accumulating, and it was very stuck after a long period of time.
Using Chinese to promote your project in the anti-censorship community and exaggerating the dangers of TLS in crypto traffic characteristics actually does not help understanding GFW.
用中文怎么就有特殊效果了？而且我不是一贯用中文吗，这也能找角度黑？我用中文的最终原因很简单，因为我对英语的掌握远未达到随意改变语言特征的程度，毕竟不是母语，而用中文干这件事就方便很多。
How does using Chinese give you a special effect? And don't I always use Chinese, how can I find an angle to hack? The ultimate reason I use Chinese is simply because my mastery of English is far from being able to change the characteristics of the language at will, after all, it's not my mother tongue, and it's much easier to do this in Chinese.
我最多能透露，根据作者的说法，通用 TLS in TLS 握手检测模型对 Vision 的强 padding 效果非常差
似乎并不是这样
That doesn't seem to be the case
也清楚 Trojan 的反馈经常是一天封一个端口
您应该清楚当时确定的原因是 Go TLS 指纹识别，且有报告有无条件 443 封锁出现。
无论如何，您的方法没有使用机器学习，也似乎无法应对不同的 Trojan 实现，也不会被 GFW 使用；且没有证据证明 GFW 应用了此类机器学习识别。考虑此类模型在误报率与性能问题，要想大规模部署都还需要很长时间。
You should be aware that the identified cause at the time was Go TLS fingerprinting, and there were reports of unconditional 443 blocks occurring.
Regardless, your approach does not use machine learning, does not appear to cope with different Trojan implementations, and is not used by GFW; and there is no evidence that GFW applies such machine learning recognition. Considering the false alarm rate and performance issues of such models, it will take a long time to deploy them on a large scale.
此外不要忘记，就是在这里出现的“内鬼”说的 GFW 已经部署了这种检测
我记得这位内鬼还曾爆料 GFW 使用 AES 加密的数据存在的特征进行封锁，这也是您要的密码学不存在了吗？
I remember that this insider also broke the news that GFW uses the characteristics of AES encrypted data to block it. Is this also the cryptography you want that does not exist?
这位朋友说 TLS in TLS 检测是炒作，还有一个人说是骗流量，所以我就写了 Trojan-killer，仅为了揭示确实存在的问题
您确实正在宣传一个没有证据的威胁，且您的 “识别” 并不能证明 GFW 确实能够或已经应用此类检查。
You are indeed promoting a threat without evidence, and your "proof" does not prove that GFW can or has applied such checks.
几个月前有一篇研究 TLS in TLS 握手特征的论文（至今尚未发布），它的作者找到了我和 @yuhan6665 ，我提了一些修改建议
Exactly, a paper demonstrating TLS-in-TLS is what I am looking for (and specifically, a link), or a paper that explains what testing has been done to identify how the GFW does it. It's hard for me to understand not just the urgency for Vision Seed (on which I will "just trust" you) but also how it works under the hood, because I don't understand what exact features it aims to eliminate. and yes, ideally it would be in english.
I will also say that it is currently very hard for an outsider to study anything related to the XTLS project. It may be intentional, but hence my original question, I am looking for a technical writeup of:
- what experiments did you do
- what did you observe in those experiments
- what do you conclude about the GFW
- what is the feature you want to eliminate
- how do you eliminate the feature
announcement of XTLS vision addresses 4 and 5, and is really vague about 3.
if this is intentional due to strategic reasons it is fine, there's a reason i asked the original question in a research forum though, and not in the XTLS bugtracker
Exactly, a paper demonstrating TLS-in-TLS is what I am looking for (and specifically, a link), or a paper that explains what testing has been done to identify how the GFW does it.
I can tell you that this paper does not study the behavior of GFW, but constructs a machine learning model by itself. If it weren't for rprx's publicity, I'm afraid the community wouldn't know how dangerous it is.
With the exception of the XTLS vision padding, everything about XTLS is about performance optimization and is unreviewed, and older versions of it have identifiable issues.
@RPRX
我想提醒您，如果您无法正面回应对于您的质疑，请不要发动粉丝攻击他人。 我不是那种监视其他项目的群组的人。
I would like to remind everyone that if you are unable to respond directly to your doubts, please do not mobilize fans to attack others. I'm not the kind of person who oversees other project teams.
i think there is merit in proactively eliminating features of a protocol before others get to build detection around it. i did not intend to start a discussion around that or to discuss how the XTLS project is lead. I am here to understand how TLS-in-TLS detection works, and I suppose if the GFW does not do it, how it can be done. again, even after this long unrelated debate, I have not seen a decent writeup on it.
i think there is merit in proactively eliminating features of a protocol before others get to build detection around it. i did not intend to start a discussion around that or to discuss how the XTLS project is lead. I am here to understand how TLS-in-TLS detection works, and I suppose if the GFW does not do it, how it can be done. again, even after this long unrelated debate, I have not seen a decent writeup on it.
I'm afraid all of them here can't provide you with valuable content. Most developers in the Simplified Chinese community are mostly user-oriented and want more non-professional users to use their software, so they provide support for black industries or even closed-source software. People here do not work for anti-censorship or research GFW .
我想提醒您，如果您无法正面回应对于您的质疑，请不要发动粉丝攻击他人。 我不是那种监督其他项目小组的人。
声明：在此期间 @nekohasekai 在其主页发了篇针对我的 小作文，我仅在频道发了条 消息 作为初步回应，并没有发动谁攻击谁
至于“监督其他项目小组”，是 @nekohasekai 认为其他人都一直在注视着他的 telegram 群组
@nekohasekai 的新回复当然我也会回复，但是看起来 @nekohasekai 并不想只讨论这件事本身，而是挑起一场战争
I would like to remind everyone that if you are unable to respond directly to your doubts, please do not mobilize fans to attack others. I'm not the kind of person who oversees other project teams.
Disclaimer: In the meantime @nekohasekai posted a small essay against me on his homepage. ef91ae44ba422c91ed60835f01332c08045ea7ab), I only posted a message on my channel as an initial response, and I did not start an attack on anyone.
As for "monitoring other project teams", @nekohasekai thinks that everyone else has been watching his telegram group
New reply from @nekohasekai I'll reply of course, but it looks like @nekohasekai doesn't want to just discuss the matter itself, but start a war!
I'm afraid all of them here can't provide you with valuable content. Most developers in the Simplified Chinese community are mostly user-oriented and want more non-professional users to use their software, so they provide support for black industries or even closed-source software. People here do not work for anti-censorship or research GFW .
I believe you are actively derailing the topic I want to discuss. I sympathize with your frustration around how XTLS is marketed, but I am not interested in your assessment of whether RPRX or anybody else can provide the content I requested.
I also want to point out that @nlifew is the only person in the thread who attempted to give me useful information. RPRX also gave some anecdote about a research paper, but it's not really answering my question.
Go fight elsewhere, this is embarassing.
我最多能透露，根据作者的说法，通用 TLS in TLS 握手检测模型对 Vision 的强 padding 效果非常差
似乎并不是这样
请你仔细看一下那个表格，检测其它协议（包括一些 mux）所用的是 通用模型，而检测 obfs 和 Vision 所用的是两个 针对性模型，即对 Vision 进行“协议倒模”，这就是 Seed 要解决的问题之一。我向作者说应当把通用模型检测 Vision 的数据放上来，作者对 @yuhan6665 和我说了上面这番话，这就是当时它没被放上来的原因。
If you look at the table carefully, detecting other protocols (including some muxes) uses generic models, while detecting obfs and Vision uses two specific models, i.e., "protocol inverting" for Vision, which was one of the problems Seed was trying to solve. I said to the author that the data from the generic model for detecting Vision should be put up, and the author said the above to @yuhan6665 and me, which is why it wasn't put up at the time.
也清楚 Trojan 的反馈经常是一天封一个端口
您应该清楚当时确定的原因是 Go TLS 指纹识别，且有报告有无条件 443 封锁出现。
无论如何，您的方法没有使用机器学习，也似乎无法应对不同的 Trojan 实现，也不会被 GFW 使用；且没有证据证明 GFW 应用了此类机器学习识别。考虑此类模型在误报率与性能问题，要想大规模部署都还需要很长时间。
如果你认为只有指纹识别，今年 uTLS 已经铺开，Trojan 和 Vision 都能用的情况下，仍然经常有人报告前者一天封一个端口。
Trojan-killer 仅为一个揭示 TLS in TLS 握手问题的启发性 PoC，为什么非要基于机器学习的方法？它写出来也不是为了非常完善以便被 GFW 使用。此外，我并没有 GFW 的方法的误报率与性能的内部数据，但我相信检测它对 GFW 的资源来说不是问题。
If you think it's only fingerprinting, uTLS has been rolled out this year with both Trojan and Vision working, and there are still frequent reports of the former blocking a port a day.
Trojan-killer is just an illuminating PoC that reveals the TLS in TLS handshake problem, so why does it have to be based on a machine learning approach? It's also not written to be perfected for use by GFW. Also, I don't have internal data on the false positives and performance of GFW's method, but I'm sure detecting it would not be a problem for GFW's resources.
此外不要忘记，就是在这里出现的“内鬼”说的 GFW 已经部署了这种检测
我记得这位内鬼还曾爆料 GFW 使用 AES 加密的数据存在的特征进行封锁，这也是您要的密码学不存在了吗？
并不是同一个人。对于 AES in AES 的说法，我的评价是“至于 AES in AES，我也觉得有点扯，但他说和硬件有关，不是我的专业。”
请注意，你的发言多次存在这样的事实性错误。
Not the same person. My comment on the AES in AES statement was "As far as AES in AES goes, I think it's a bit of a stretch too, but he said it had to do with hardware, not my specialty."
Please note that your statement is factually incorrect in this way on several occasions.
这位朋友说 TLS in TLS 检测是炒作，还有一个人说是骗流量，所以我就写了 Trojan-killer，仅为了揭示确实存在的问题
您确实正在宣传一个没有证据的威胁，且您的 “识别” 并不能证明 GFW 确实能够或已经应用此类检查。
我建议你自己去测试一下。既然我们都能用低成本检测出经典的 TLS in TLS 握手，为什么你仍觉得 GFW 没有能力实施检测？
关于 GFW 是否应用了此类检查，上面已经说过了。这已经是人们切实遇到的事情、实测出的区别。
I suggest you test it yourself. Why do you still think that GFW is not capable of applying inspections when we can all detect the classic TLS in TLS handshake at low cost?
The question of whether GFW applies such checks has already been addressed above. It's already a difference between what people actually encounter and what they actually test.
上面是你要的“正面回应”，而对于你在本 issue 发表的仇恨性 off-topic 言论，我选择不作回应，这里不是合适的地方。
你的那篇小作文也存在很多错误，第一句分析就错了，~~你应该庆幸周五晚上我没那么多时间~~。
The above is the "direct response" you asked for, and I chose not to respond to the hateful off-topic comments you made in this issue, this is not the right place for it.
Your little essay is also riddled with errors, the first sentence of your analysis is wrong, ~~you should be glad I don't have that much time on a Friday night~~.
@nekohasekai 我看到了你在群里的回复，请把它发到这里，这样所有人都能看到。明天我会统一查看并回复。
I saw your reply in the group, please post it here so everyone can see it. I will check and reply in a unified way tomorrow.
@mmmray 请不要误会，我的意思是他应当在这里发就事论事的“正面回应”，这只是在讨论技术问题。
Please don't get me wrong, I mean he should be posting "direct responses" here on the matter, this is just a technical discussion.
I guess it is worth actually explaining TLS-in-TLS detection before the flamewar heats up as people tend to get involved in the war without a proper understanding of the underlying issue.
First, let's take a look at TLS. Modern TLS usage is almost provable secure with LHAE security. Which means, vulnerabilities keep cropping up, but for most people that's just fine. An attacker's power is greatly limited compared to plaintext protocols:
- An attacker can get no information of application data itself.
- An attacker can tamper none of handshake messages and application data without getting caught.
- And, in an appropriate setting:
- an attacker can not decrypt the stream after its ephemeral state is gone, without a quantum computer.
- an attacker can not determine the exact length of an application message.
These properties may seem strong enough for a generic secure transport, but not necessarily sufficient. It is common to want to hide some information in the handshake messages, hence ESNI and ECH. It is common to want to bind a TLS stream to another stream, where existing solutions have massive problems. Worse, for anti-censorship developers and malware developers, every aspect not covered by that notion of security is troublesome:
Oppressive regime needs you to find the difference between these developers and these developers. They're the same developers.
- TLS fingerprinting: information in handshake messages, like ciphersuites and extensions, contains implementation detail, which can be used to identify a certain proxy implementation.
- Active probing: an attacker can perform active probes to see how the server reacts. Many proxies have special handling for certain types of error, thus giving themselves away. Success by getting caught.
- Behavioral fingerprinting: For example, long-lived connections need to be kept alive. TCP keepalive, TLS heartbeat or application level message? A feature. Time between each keepalive message? A feature. To reconnect or not if the message is lost? A feature.
- Flow analysis: TLS padding is rarely used in practice. Even if used, padding sizes are usually uniformly distributed so an average cancels them out. Then the attacker proceeds with (direction, length, timing) triples of every message. Surely, the last two elements can never be exact, but can still contribute to classification.
TLS-in-TLS detection is just a specialized version of flow analysis because the length and timing of a browser-initiated TLS handshake are too typical. It takes no machine learning to classify: Client Hello is always 517 bytes, Certificate is always huge like about 4KiB, predictable timing like the first Application Data after Change Cipher Spec. People have been classifying applications for so long.
I have no intention of arguing here, please rprx reply to me in his own group or if he is willing to come up with some research results on GFW.
上面是你要的“正面回应”，而对于你在本 issue 发表的仇恨性 off-topic 言论，我选择不作回应，这里不是合适的地方。
你的那篇小作文也存在很多错误，第一句分析就错了，~你应该庆幸周五晚上我没那么多时间~。
又要笑死我了，这个人还在装高尚。人身攻击我的时候，怎么又不说 “仇恨性 off-topic 言论” 呢？
在我看来 @nekohasekai 的观点相当客观，反倒某人到处散播他的R主席语录。
Again LOL, this person is still acting noble. How come you don't say "hateful off-topic remarks" when you personally attack me?
It seems to me that @nekohasekai's views are quite objective, instead someone is spreading his R chairman quotes all over the place.
I have no intention of arguing here, please rprx reply to me in his own group or if he is willing to come up with some research results on GFW.
这里的 arguing 不就是你先挑起来的吗？https://github.com/net4people/bbs/issues/281#issuecomment-1702353781
在此之前我说的是 https://github.com/net4people/bbs/issues/281#issuecomment-1701448593 ，而它是和主题相关的。
Isn't arguing here what you started? https://github.com/net4people/bbs/issues/281#issuecomment-1702353781
Before that I was talking about https://github.com/net4people/bbs/issues/281#issuecomment-1701448593 and it was related to the topic.
I have no intention of arguing here, please rprx reply to me in his own group or if he is willing to come up with some research results on GFW.
这里的 arguing 不就是你先挑起来的吗？#281 (comment)
在此之前我说的是 #281 (comment) ，而它是和主题相关的。
I'm afraid that all the things we discussed are meaningless to this issue and the community. Also, you are ignoring my replies to you in your group, so this is my last message here.
上面是你要的“正面回应”，而对于你在本 issue 发表的仇恨性 off-topic 言论，我选择不作回应，这里不是合适的地方。 你的那篇小作文也存在很多错误，第一句分析就错了，~你应该庆幸周五晚上我没那么多时间~。
又要笑死我了，这个人还在装高尚。人身攻击我的时候，怎么又不说 “仇恨性 off-topic 言论” 呢？
在我看来 @nekohasekai 的观点相当客观，反倒某人到处散播他的R主席语录。
首先你对中文的理解有很大的问题，我首次对你的评价是针对你的“发言”，因为错误实在太多，这些也是你承认的。
此外你的项目说明有多少错误自己不知道吧？我没有时间一直陪你玩，你实在想要的话我可以写给你。
First of all you have a big problem understanding Chinese, my first comment to you was about your "speech" because there are too many mistakes, which you also admitted.
Besides, you don't know how many mistakes you made in your project description, do you? I don't have time to play with you all the time, I can write it for you if you really want.
I have no intention of arguing here, please rprx reply to me in his own group or if he is willing to come up with some research results on GFW.
这里的 arguing 不就是你先挑起来的吗？#281 (comment) 在此之前我说的是 #281 (comment) ，而它是和主题相关的。
I'm afraid that all the things we discussed are meaningless to this issue and the community. Also, you are ignoring my replies to you in your group, so this is my last message here.
所以你为什么要挑起来冲突呢？我说了，正面的技术讨论可以在这里进行。当然若你不愿意发到这里，我也会回复，~~指明天~~。
So why are you trying to start a conflict? As I said, positive technical discussions can take place here. Of course if you don't want to post it here, I will respond, ~~meaning tomorrow~~.
@mmmray What's your problem? Isn't it clear that @nekohasekai started the fight at first? And why's that my responses to those unfriendly comments would receive your "thumbs down"? What about them who made their unfriendly comments in the first place? I don't what to do this here either, but they've already sent unfriendly comments. Shouldn't I respond?
(continued)
To mitigate these problem, there came uTLS, application fronting, padding and a lot more techniques. What is being discussed here is padding.
I wonder if ECH and/or GREASE in the inner layer would (temporarily) confuse those heuristics.
Who knows (except that inner ghost). No one knows what those heuristics are. Fixing broken heuristics to accommodate ECH is just several hours.
Padding has shown to be somewhat effective in hiding inner stream characteristics. Good news: TLS can be arbitrarily shaped. Bad news: TLS can be made really slow with long padding. And effectively hiding the inner TLS stream requires rather long padding. XTLS chose to pad only the first few packets and leave the remainder to be raw, unaltered browser traffic, hence the somewhat opinionated breakage of V2Ray's composability.
People diverge about what is the best way to pad records. NaïveProxy uses short, always-on padding with multiplexing. Is long, specialized padding better or is short, indiscriminate padding? And the draft being discussed has not paid attention to the longer stream. Will XTLS allow an attacker to determine what website you're visiting? Likely if you are of high suspect.
That said, the padding strategy somewhat subjective and subject (pun intended) to the threat model. Xray has an opinionated threat model yet advertises itself as the objectively better choice. Trojan and Naïve has a very generic threat model, but it can be easily hammered down (with massive collateral damage) in situations like Iran. Is Xray bad by such advertisement? WireGuard is doing the same thing. Xray did well in being the stable go-to solution for many people.
Please at least take a look at the threat model before starting a flamewar. You can get away with nearly any protocol with a very clean IP. You can get away with Trojan-over-Trojan. There are one thousand weird ways to build a usable protocol, yet people want a stable protocol. There are even times when XTLS can get you into trouble, but how can you know that without learning as much as to become a developer? It is sheer hard to predict new features to build into a protocol. What if another inner ghost leaks that the GFW is using another way of detection instead of TLS-in-TLS length? Just try to be nice please.
@mmmray What's your problem? Isn't it clear that @nekohasekai started the fight at first? And why's that my responses to those unfriendly comments would receive your "thumbs down"? What about them who made their unfriendly comments in the first place? I don't what to do this here either, but they've already sent unfriendly comments. Shouldn't I respond?
grow up my friend
Isn't it clear that @nekohasekai started the fight at first?
I don't care about "original sin". He is attempting to move the discussion elsewhere. You are continuing the flamewar.
@nametoolong, i apprechiate the summary!
but how can you know that without learning as much as to become a developer?
yes exactly. I believe it is not possible to operate any proxy in the long-term without understanding what it does. short-term nothing is blocked.
仅为 @nametoolong 的客观评论点赞，他所提到的一些问题也是我所提过的。For the record，我并不认为 Vision 是最好的方案，我也在尝试给它加更多的可能性、开发其它流控。Vision 和 Trojan 的区别就那些，我们可以从大量用户反馈的区别中得出 GFW 用了什么样的检测手段。
Just to give credit to @nametoolong for his objective comment, some of the issues he mentioned are the same ones I mentioned. for the record, I don't think Vision is the best solution, and I'm trying to add more possibilities to it and develop other flow controls. The differences between Vision and Trojan are just those, and we can draw them from a lot of user feedback. The differences between Vision and Trojan are just that, and we can tell from a lot of user feedback what kind of detection methods GFW is using.