net4people
Web Panels like 3X-UI are leaking an unimaginable amount of passwords and private keys to the GFW
https://github.com/net4people/bbs/issues/446#issuecomment-2625123949
I do not know the origin of the dispute
我无法在那个 thread 中回复，所以开一个新的，正好也可以在这里讨论一下这个问题，纯技术而言，这场冲突的根源是：
- 基于 Xray 的 3X-UI 等面板提供默认的明文 HTTP 访问，这不仅暴露服务器，还使得各种密码、代理私钥等被 GFW 截获
- 并且 YouTube 上的视频基本都是教世界各地的新手使用 http://ip 访问面板，导致占人数最多的新手处于危险中
- 所以我要求 3X-UI 等面板禁止公网明文 HTTP，毕竟还有 SSH 端口转发、免费 TLS 证书等，但有些面板无论如何都不改
我认为我的做法是负责任的，是某些面板作者及他们的一部分支持者没研究过反审查，导致他们意识不到问题的严重性，当然这只是尽可能往好的方向想（一开始我都想不到），而往另一个方向想就是另一回事了，在此不表，我希望这个 thread 只讨论技术
但是话说回来技术上也没什么讨论的余地，配置面板，尤其是这种反审查软件的面板，本来就不应该允许用公网明文 HTTP，从第一个 X-UI 出现时这种行为就是完全错误的，现在矫正起来竟然如此艰难，有些面板宁愿停更也不愿删掉公网明文 HTTP
参考 why our community hopes web panels like 3X-UI ban plain HTTP for public network: https://github.com/XTLS/Xray-core/pull/3884#issuecomment-2620895112
I was unable to reply in that thread, so I opened a new one, where I can also discuss this issue. Technically speaking, the root cause of this conflict is that
- Panels such as 3X-UI, which is based on Xray, provide default cleartext HTTP access, which not only exposes the server, but also allows various passwords, proxy private keys, etc. to be intercepted by the GFW
- And videos on YouTube basically teach novices around the world to use http://ip to access the panel, putting the most numerous group of novices at risk
- So I demand that panels such as 3X-UI block public HTTP over plaintext. After all, there are also SSH port forwarding, free TLS certificates, etc., but some panels will never change no matter what.
I think my approach is responsible. It is that some panel authors and some of their supporters have not studied anti-censorship, which has caused them to fail to realize the severity of the problem. Of course, this is just thinking in the best possible direction (at first I couldn't even think of it), and thinking in the other direction is another matter. I hope this thread will only discuss technology
But then again, there is really not much room for discussion on the technical side. Configuration panels, especially those for anti-censorship software, should never have allowed cleartext HTTP over the public network in the first place, this behavior has been completely wrong since the first X-UI appeared, and it is surprising that it is now so difficult to correct. Some panels would rather stop updating than delete cleartext HTTP over the public network
Reference why our community hopes web panels like 3X-UI ban plain HTTP for public network: https://github.com/XTLS/Xray-core/pull/3884#issuecomment-2620895112
It's all are already answered by developers, stop repeating 3X-UI/X-UI or Marzneshin and other panels leaked nothing, they didn't blocked TLS, if having the option to use the panel without TLS is equal to leaking, then you leaked traffic of millions of users to GFW by allowing them to use the non-encrypted VLESS with no TLS (Unlike the Trojan)
All of your accusations are already answered, but you never answered the mentioned questions at https://github.com/net4people/bbs/issues/446#issue-2820663321 you blocked everyone who asked those questions at your github repo or telegram group, why? why never answered those questions?
Sorry, it's my mistake that I hadn't block @APT-ZERO personally : (
It's done now.
Even though how RPRX here approached the glaring problems here could have been better, there's no denial that leaving the fundamental configurations exposed has been an issue in dire need of fixing. To be frank, the counter-arguments APT-ZERO had put out here have quite some comedic value, especially regarding the claim that the panel devs in question responding to all the questions and derived allegations the broader encrypted proxy community has presented, all the while attaching the delusional accusation that RPRX was the one who dodged the questions.
So let's tackle some smaller fries here. I doubt that permitting the decoupling of encryption from non-encrypted transport protocols proves to be as problematic as exposing the actual configurations making your clusters tick to the state-sponsored censors. TLS (and by extension, REALITY) isn't the only way proper security could've been achieved, whereas EPs can also perfectly function over mixnets and overlay networks which provide E2EE. Not unlike there are many ways to have a house prepared for burglar intrusion, for an analogy. In contrast however, exposing the configurations containing sensitive fields like UUIDs used by various other components of the EP... I dunno, kinda sounds like someone just handing out keys to your own house to everyone observing afar?
In terms of hatred... I admit I don't have enough pennies to spare for a fresh new subscription of Telegram Premium, so the best I could've done would've been manually copying and pasting messages into Google Translate. But from the messages observed during the peaks of the conflicts, I must ask, who is harbouring hatred against whom? It doesn't take a pea-sized brain to acknowledge that the majority of the hate speech wasn't in an East-Asian language, and when it was, the translation weirdly stood on the same ground with the panel zealots, consisting largely of clueless Iranian nationalists who were borderline racist. Enjoy a piece of appetizer first, which was sadly removed.
بسوز چینی بسوز بسوز چون بهترین پنل دنیا را یک ایرانی ساخته با افتخار ایرانی هستیم و میمانیم❤️🔥❤️🔥 زنده باد ایران ❤️❤️🔥🇮🇷
Let's sample another piece of message.
伊朗国内的每个人都知道，他们为了向伊朗人以及其他与伊朗条件相似的国家提供免费互联网接入付出了多少努力。他们将Xeri核心和XUI面板升级到了极致，以至于超越了原版和中文面板。他们添加了中国面板甚至不敢想象的功能。你永远不能质疑伊朗人的知识和专业技能。仅仅因为你与他们意见不同，这并不是玷污他们知识的理由。我们伊朗人现在和将来都会感谢这位先生。我们仍然没有忘记那块丑陋、质量低劣的中国面板。你跟那个中国小组呆在一起，别干扰我们那个超级先进的小组。这是中国人嫉妒的表现，因为伊朗人已经超越了你们。
Considering that the panels provide no more than a graphical abstraction for the underlying functionalities of the core, it's flat out hilarious to see the panel cultists accusing the insistence of enforcing bare-bones security practices being an act of jealousy from who truly supply them with underlying technologies. Too sad I wasn't able to grab a bucket of microwavable popcorn to munch on with the free entertainment. I doubt anyone had seen the cultists contributing to the encrypted proxy landscape with either code or constructive criticism, apart from them repeatedly inciting hate speech against the EP developers, which I believe observers like @iambabyninja are quite acquainted with. The icing on top of this whole situation would be the bleak contemporary landscape, in which the panels with bad security practices receives substantial financial gain, yet the people truly behind the running gears securing the connections of the masses receive next to no compensation.
From the experiences with dealing with panel cultists who don't understand frank will just attack whoever holds contradictory opinions in swarms not unlike mosquitos, I'll just leave this commentary with a fresh coat of paint. Feel free to watch the paint dry, I'll just finish my remaining portion of Sunday roast ;)
PS: Oops, I thought faster than I typed.
first, like vless, we can also use trojan without tls, but this has nothing to do with security, because anyway connection between browser and final-server is tls-encrypted.
second, changing early-data header name has no effect on cloudflare detection, because anyway in header-value we have base64 of vless/trojan header and vless/trojan headers are easy detectable.
third, quic is not removed, just replaced with xhttp-h3.
fourth, http-panel is real danger It exposes all the information of ordinary users, and expert-users can edit the code themselves to access http.
In addition, in iran, after opening whatsapp and getting meta ips out of the block, all services except telegram are accessible with serverless methods, and the panels are slowly losing their necessity.
@wkrp May I ask why the response towards APT-ZERO was regarded as off-topic, when all that I did was presenting what's considered facts regarding the situation against every fraudulent point APT-ZERO raised? Was it because I was replying to a comment already derailing the discussion?
Discussion of panels, and ways of accessing them, is on topic, but only if the comments are civil and productive. If not, I will delete this thread as I have now deleted #446 (which I should have done earlier). If you are going to fight, do it somewhere else; here we must work together. Authoritarians love nothing better than when they people they rule fight each other, instead of the people directing their anger at the rulers. I help you in your time of need, as I hope you will help me in mine.
@APT-ZERO, you should know better than to repost a comment that has been moderated. I have temporarily blocked your account from the repository. I understand that interpersonal conflicts are real and cannot just be ignored, but I must see more of an effort to overcome the conflicts, not inflame them.
@wkrp May I ask why the response towards APT-ZERO was regarded as off-topic, when all that I did was presenting what's considered facts regarding the situation against every fraudulent point APT-ZERO raised? Was it because I was replying to a comment already derailing the discussion?
I think your comment was made in good faith. But yes, I want to stop what I see as an off-topic and unproductive line of discussion. I understand the desire to respond to accusations that are felt as unjust. Our goal is not to see how long we can prolong an argument.
I don't have much experience with panels. If most online tutorials (e.g. YouTube) demonstrate setting up plaintext access to panels, are there any examples of tutorials that show how to do it in a safer way? With encrypted access, e.g., TLS or SSH? How much more complicated is it?
Is it a question of awareness by users, as well as defaults offered by the software?
I have been using both Xray and 3X-UI panel for years. I love and thank both contributors from the deepest of my heart. Let's stop fighting each other and work together.
My two cents on the issue:
Both author could make the potential risk of HTTP clear and the solution clear. I think a ssh -D 8888 server command and config a proxy in your browser/computer is a very simple step before configuring the panel.
Let every old and new user know about this.
For the general audiences, using HTTP is just making your server an easy target and might cost you money to replace IP/server. Let them know and let them decide.
Censorship is a pressure Gov force on people and they say its for their own good. Forcing others to do or stop doing something for their own good is kind of similar. Those are the things you guys fought from the beginning. Don't forget that and work together.
===== Translated by AI ====
我已经使用Xray和3X-UI面板多年。我从心底里爱并感谢这两位贡献者。让我们停止互相争斗，一起合作。
关于这个问题，我的两点意见：
两位作者可以明确HTTP的潜在风险，并提供解决方案。我认为在配置面板之前，使用ssh -D 8888 server命令并在浏览器/计算机中配置代理是一个非常简单的步骤。告诉所有新老用户这一点。
对于普通用户来说，使用HTTP只是让你的服务器成为一个容易攻击的目标，可能会花费你更换IP/服务器的钱。告诉他们这些信息，让他们自己决定。
审查是政府对人民施加的压力，他们说是为了人民的利益。 强迫别人为了自己的利益去做或停止做某事是相似的。这些是你们一开始就为之奋斗的事情。不要忘记这一点，一起合作。
dear wkrp i personally dont consider it pointless arguments as rprx itself did it here again by himself without answering prior question in xray thread he mentioned. i think we can also discuss the technical side that rprx is letting people use plaintext when not doing anything about allowinsecure, vless+no tls. should we also open an issue here that why nginx does not ban plain http in not local binds? or is this leaved to users to decide?
@IMIEEET I think I can answer part of the query for him.
why nginx does not ban plain http in not local binds?
Because the purpose of nginx is not anti-censorship.
why not doing anything about allowinsecure, vless + no tls.
The insecure option is provided because the connection can be unencrypted when used on an intranet, or when there is an encrypted external transport layer. xtls has reminded users in the tls documentation and vless documentation that you need to have a trusted transport layer when using these features.
Danger This should not be set to true in deployments for security reaons, or it can be susceptible to man-in-the-middle attacks. Danger Currently, VLESS does not provide built-in encryption. Please use it with a reliable channel, such as TLS.
Also, unencrypted cross-border proxies will not work at all in China and will be quickly blocked by the national firewall, so in fact no Chinese use plaintext cross-border proxies. You might say that Iran's national firewall doesn't censor plaintext, so it can be used that way. Although I don't know why the Iranian government doesn't censor plaintext, because technically it's much easier to censor plaintext than ciphertext. National gateways, ISP gateways can quickly trace or block certain domains, certain keywords if they find them in plaintext packets. But the Iranian government doesn't do that. One speculation is that the Iranian government does not block plaintext in order to peek at the privacy. Of course none of us have definitive proof of this, and it remains only speculation. But just because it hasn't happened yet doesn't mean the risk doesn't exist. The Chinese firewall has already demonstrated that this risk exists. As a known security vulnerability, it is necessary for us to be proactive in patching it. Rather than waiting for news of a vulnerability being exploited by censors or hackers to break before remedying it. What I'm most puzzled about as an observer in this dispute is: why is pointing out a security vulnerability being blamed?
@IMIEEET 为什么 Nginx 不禁止明文 HTTP？为什么浏览器不禁止明文 HTTP？因为它们是通用软件，并非针对反审查而设计
himself without answering prior question in xray thread he mentioned
我不确定 prior question 指的是什么，我没有回避过任何问题，只要我看到了我就回答过（APT-ZERO 问的那些搞笑问题除外）
关于 plain VLESS 的话题我也早就回复过：https://github.com/XTLS/Xray-core/pull/3884#issuecomment-2621464261
Secondly, your argument is completely illogical. By this logic, since you exclusively develop the Xray core, and all clients are using this core to connect, while you still haven't equipped the VLESS TCP protocol with encryption or removed it, does that mean you have also been hired by the government to expose people's data?
Because everyone knows that VLESS protocol's encryption is
none, if you still want to deploy plain VLESS, it is your own choice.But when newbies following YouTubers to visit http://ip, they just exposed their data to GFW, even without knowing how to fix it. Then they start using the proxy, with passwords and private keys held by GFW, and they may won't even notice that.
That's the key difference.
并且我在 Telegram channel 中说过，网上关于 VLESS 的教程都是些 REALITY、TLS 等带加密的，而不像面板一样都是些 http://ip
这里最大的区别是“是否自愿”，大量新手是在缺乏相关知识的情况下跟着 YouTuber 访问 http://ip ，而非机场主非要部署明文代理
Why doesn't Nginx block plaintext HTTP? Why don't browsers block plaintext HTTP? Because they are general-purpose software and not designed to counter censorship.
himself without answering prior question in xray thread he mentioned
I'm not sure what the prior question refers to, but I have not avoided any questions. I have answered any questions I have seen (except for the silly questions asked by APT-ZERO).
I also replied to the topic about plain VLESS a long time ago: https://github.com/XTLS/Xray-core/pull/3884#issuecomment-2621464261
Secondly, your argument is completely illogical. By this logic, since you exclusively develop the Xray core, and all clients are using this core to connect, while you still haven't equipped the VLESS TCP protocol with encryption or removed it, does that mean you have also been hired by the government to expose people's data?
Because everyone knows that VLESS protocol's encryption is
none, if you still want to deploy plain VLESS, it is your own choice.But when newbies following YouTubers to visit http://ip, they just exposed their data to GFW, even without knowing how to fix it. Then they start using the proxy, with passwords and private keys held by GFW, and they may won't even notice that.
That's the key difference.
And as I said in the Telegram channel, the online tutorials on VLESS are all about REALITY, TLS and other encryption, unlike the panel, which is all about http://ip
The biggest difference here is “voluntary or not”. A large number of novices follow YouTubers to visit http://ip without the relevant knowledge, rather than the airport master deploying the plaintext proxy by force
@livingfree2023 关键问题是占人数最多的新手并没有“自己决定”的能力，他们只会跟着 YouTuber 访问 http://ip 、难以脱离教程
Censorship is a pressure Gov force on people and they say its for their own good. Forcing others to do or stop doing something for their own good is kind of similar. Those are the things you guys fought from the beginning. Don't forget that and work together.
Not similar at all
强制性的 censorship 是首先为了统治者的利益而服务的，而强制性的安全设计是真的 for people's own good，这是本质区别
反审查面板禁止公网明文 HTTP 是最基本的安全设计，我说过，就像你设计手雷要有拉环，开车要系安全带，出太空要穿宇航服
就像现在很多网站会强制 HTTPS，以及 TLSv1.3 移除了 TLSv1.2 中一些不够安全的加密套件，难道这些都是错误的吗？显然不是
The key problem is that most beginners do not have the ability to “make their own decisions”. They just follow the YouTubers to visit http://ip and find it difficult to break away from the tutorials.
Not similar at all
Compulsory censorship is first and foremost in the interests of the rulers, while compulsory security design is really for people's own good. This is the essential difference
The anti-censorship panel prohibits cleartext HTTP over the public network as the most basic security design*. As I said, it's like designing a grenade with a pull ring, wearing a seat belt while driving, and wearing a spacesuit when going into space*
Just like how many websites now enforce HTTPS, and TLSv1.3 removes some of the less secure encryption suites in TLSv1.2. Are these all mistakes? Obviously not
@CrazyBoyFeng @RPRX nginx is used everywhere https is about privacy at whole not to be only used in anti-censorship tools no matter if data is sensitive or not, yet nobody wants to remove it because of its flexibility like safe/secure/local. the secure part of http is not about censorship, it does not matter if its a xray web panel, another core web panel or a panel that uses nginx or others as web front. any plaintext panel that contains sensitive data needs https not only this panels. they dont ban http bacause they know the users are not only youtube newbies but actual people who know the difference between good and bad cipher connections. just because the doc says vless encryption is none it does not stop all those newbie to stop using plain vless. i have seen big vpn sellers in telegram in my country that encourage their users to "enable allowinsecure to access secure vpn", in this example both the problematic seller and poor people who use them are in danger, should we also label the op as dangerous? and the xray clients that dont go further and prevent that in their own level? one might say that allowinsecure can be used as debugging purpose but we can make this option in clients to turn off after certain amount to encourage people to stop using it. but rprx, you as a creator of a anti-censorship core cant/should not/most not enforce certain policies to downstream projects like web panles using it. before v2rayn released linux version of client i had to use 3x-ui as a client on my pc but enforcing of https and random webpath is not what i look for in local setup as it keep me from freely using it as i want in the name of freedom. between the privacy and freedom of users there is a narrow line here that a lot of people in this argument are missing, either sticking at one of this two
@wkrp
I don't have much experience with panels. If most online tutorials (e.g. YouTube) demonstrate setting up plaintext access to panels, are there any examples of tutorials that show how to do it in a safer way? With encrypted access, e.g., TLS or SSH? How much more complicated is it?
Is it a question of awareness by users, as well as defaults offered by the software?
事实上，即使是没有禁止公网明文 HTTP 的面板，在前段时间也加上了对明文 HTTP 不安全的警告，以及 SSH 端口转发的提醒
但他们仍然提供了明文 HTTP 的选项（最方便，相当于默认），且 YouTube 上大量教程都是 http://ip ，而安全访问的教程少得可怜
再加上看这些教程的往往都是些新手，他们人数最多、缺乏相关知识且不会脱离当前教程，能搭好就用，造成大量密钥被 GFW 截获
我们无法纠正网上的所有教程，唯一的办法是从源头禁止公网明文 HTTP，毕竟 SSH 端口转发就一行命令，还有大量免费 TLS 途径
In fact, even the panels that do not prohibit cleartext HTTP on the public network have also added warnings about the insecurity of cleartext HTTP and reminders about SSH port forwarding in the past.
However, they still provide the option of cleartext HTTP (the most convenient, which is equivalent to the default), and there are a large number of tutorials on YouTube, all of which are http://ip, while there are very few tutorials on secure access.
Plus, the people watching these tutorials are often novices. They are the most numerous, lack the relevant knowledge, and will use whatever they can get their hands on without thinking about it, causing a large number of keys to be intercepted by the GFW
We cannot correct all the tutorials on the internet, the only way is to ban cleartext HTTP from the public network at the source. After all, SSH port forwarding is just one line of code, and there are many free TLS options
我认为所有参与这个 thread 的人都应该达成一个基础共识：我所描述的问题切实存在、已经且仍在大量发生，我们需要解决这个问题
@IMIEEET 而你所做的只是在诡辩，要么说 Nginx 怎么不禁用明文 HTTP，要么就是从根源上否认我们需要促使面板改变
Well，我没有权力迫使别的项目做任何事情，而是反审查相关项目的维护者有义务做出改变去解决安全问题，无需来自于别人的压力
@IMIEEET 这是你最大的认知错误
I think everyone involved in this thread should reach a basic consensus: the problem I described does exist, has occurred, and is still occurring in large numbers, and we need to solve it
@IMIEEET All you're doing is sophistry, either saying how Nginx doesn't disable plaintext HTTP, or denying from the root that we need to prompt the panel to change
Well, I have no power to force another project to do anything. Instead, it is the maintainers of the project concerned who are obligated to make changes to address security issues, without pressure from others.
@IMIEEET This is your biggest misconception
@IMIEEET 或者说，就算我不是 Xray 的开发者，而只是一个反审查领域的研究者，就像 @wkrp ，也有权利去促进解决这一问题
这无关 force，无关 violate anyone's freedom，这只是面板的明文 HTTP 已经被大量滥用、需要被解决而已，为什么总有人不懂？
Or, even if I'm not a developer of Xray, but just a researcher in the field of anti-censorship, like @wkrp, I also have the right to help solve this problem
This has nothing to do with force or violating anyone's freedom. This is just the plaintext HTTP on the panel that has been massively abused and needs to be solved. Why can't people understand this?
@IMIEEET 我本来还想反驳你说的其它话，但我发现你整个思维逻辑就是错误的，屁股决定脑袋、在故意诡辩，我决定不浪费时间
I was going to refute the rest of what you said, but I realized that your entire line of thinking is flawed, that you're letting your butt decide your brain and deliberately being argumentative. I decided not to waste any more time.
@IMIEEET 或者说，就算我不是 Xray 的开发者，而只是一个反审查领域的研究者，就像 @wkrp ，也有权利去促进解决这一问题
这无关 force，无关 violate anyone's freedom，这只是面板的明文 HTTP 已经被大量滥用、需要被解决而已，为什么总有人不懂？
You are free to not waste your time and not respond to this as you stated but for the record i dont reject the technical and security research of this matter but it all started when you accused mhsanaei as someone from gov who is deliberately not forcing https. If you believe in what you say and you dont do this by force do exactly as title of issue in your repo: only list secure web panels, no less no more Not to accuse those who dont follow your rules and lie, no one is against insecurity specially in this bbs repo
@IMIEEET 首先我说过 net4people 这个 thread 只是技术讨论，如果你想要争论其它问题可以去 https://github.com/XTLS/Xray-core/pull/3884#issuecomment-2620895112
并且我在那里说过很多次，我不会无端指责别人，我对他们的看法都是基于他们的诡异行为，毕竟你无法保证所有人都是“好人”
First of all, as I said, the net4people thread is for technical discussions only. If you want to argue about other issues, go to https://github.com/XTLS/Xray-core/pull/3884#issuecomment-2620895112
And as I've said many times there, I don't make groundless accusations against people. My opinions of them are based on their strange behaviour. After all, you can't guarantee that everyone is a “good person”.
@IMIEEET 你时间多的话，不如你提出一个针对当前问题的 有效解决方案？注意是有效，而不是 YouTuber 还能继续教 http://ip
If you have time, why not propose an effective solution to the current problem? Note that it must be effective, not just something where a YouTuber can keep on teaching http://ip
I don't have much experience with panels. If most online tutorials (e.g. YouTube) demonstrate setting up plaintext access to panels, are there any examples of tutorials that show how to do it in a safer way? With encrypted access, e.g., TLS or SSH? How much more complicated is it? Is it a question of awareness by users, as well as defaults offered by the software?
事实上，即使是没有禁止公网明文 HTTP 的面板，在前段时间也加上了对明文 HTTP 不安全的警告，以及 SSH 端口转发的提醒
但他们仍然提供了明文 HTTP 的选项（最方便，相当于默认），且 YouTube 上大量教程都是 http://ip ，而安全访问的教程少得可怜
再加上看这些教程的往往都是些新手，他们人数最多、缺乏相关知识且不会脱离当前教程，能搭好就用，造成大量密钥被 GFW 截获
我们无法纠正网上的所有教程，唯一的办法是从源头禁止公网明文 HTTP，毕竟 SSH 端口转发就一行命令，还有大量免费 TLS 途径
I agree with RPRX that 3X-UI should do at least something, anything to stop the leaks. I am not familiar with other panels but it sounds like they have a good start.
Let's put 3X-UI aside, say if GFW, who has unlimited money and man-power to develop/bribe a very good panel and find a very influential Youtuber to lure millions of users to this un-intended way of using xray-core, what can we do about it?
- Maybe we could contact some Youtuber about this, see if they can make a new video about this topic, they will benefit from this new video too.
- Maybe RPRX could modify xray-core's license to enforce certain usage?
To be honest, none of the above can do much.
In the worst case scenario, a large number of users will leak their private keys and their VPS IP so that GFW can listen to their traffic. I don't think they will leak their gmail passwords or email contents since they are encrypted by browser/client. But their internet history could be leaked. Their own IP addresses can be leaked and with ISP's data, their identities can be traced. That's the biggest issue maybe?
我同意RPRX的观点，3X-UI至少应该采取一些措施来阻止泄漏。虽然我对其他面板不熟悉，但听起来他们有一个很好的开端。
先撇开3X-UI不谈，假设GFW有无限的资金和人力来开发/贿赂一个非常好的面板，并找到一个非常有影响力的Youtuber来引诱数百万用户以这种意外的方式使用xray-core，那么我们能做些什么呢？
或许我们可以联系一些Youtuber，看看他们是否可以制作一个关于这个话题的新视频，他们也会从这个新视频中受益。
也许RPRX可以修改xray-core的许可证来强制某些用途？
说实话，以上方法都不太有效。
在最坏的情况下，大量用户将泄露他们的私钥和VPS IP，这样GFW就可以监听他们的流量。我认为他们不会泄露他们的Gmail密码或邮件内容，因为这些都是由浏览器/客户端加密的。但他们的上网历史可能会被泄露。他们自己的IP地址也可能被泄露，通过ISP的数据，他们的身份可以被追踪。这可能是最大的问题？
من با RPRX موافقم که 3X-UI باید حداقل کاری برای متوقف کردن نشتها انجام دهد. من با سایر پنلها آشنا نیستم، اما به نظر میرسد آنها شروع خوبی داشتهاند.
بیایید 3X-UI را کنار بگذاریم، بگوییم اگر GFW، که دارای پول و نیروی انسانی نامحدود برای توسعه/رشوه دادن به یک پنل بسیار خوب است و یک یوتیوبر بسیار تاثیرگذار را برای جلب میلیونها کاربر به این روش ناخواسته استفاده از xray-core پیدا کند، ما چه کاری میتوانیم انجام دهیم؟
شاید بتوانیم با برخی از یوتیوبرها تماس بگیریم، ببینیم آیا آنها میتوانند یک ویدیوی جدید درباره این موضوع بسازند، آنها هم از این ویدیوی جدید بهرهمند خواهند شد. شاید RPRX میتواند مجوز xray-core را برای اجرای استفاده خاصی تغییر دهد؟ صادقانه بگویم، هیچکدام از موارد بالا نمیتوانند کار زیادی انجام دهند.
در بدترین حالت، تعداد زیادی از کاربران کلیدهای خصوصی خود و IP VPS خود را نشت خواهند داد تا GFW بتواند به ترافیک آنها گوش دهد. فکر نمیکنم آنها رمزهای Gmail یا محتوای ایمیلهای خود را نشت دهند چون توسط مرورگر/کلاینت رمزگذاری شدهاند. اما تاریخچه اینترنت آنها میتواند نشت شود. IPهای خودشان میتواند نشت شود و با دادههای ISP، هویت آنها قابل ردیابی است. شاید این بزرگترین مسئله باشد؟
网上流行的搭建私人代理的面板大都基于 Xray-core，其中 3X-UI 是占市场份额最多的，当我促使那些面板进行改变时，我曾经以为 3X-UI 的主要开发者 @MHSanaei @alireza0 会重视并致力于彻底解决这个问题，但他们并不想，反倒是其它面板禁止了 http://ip
注：以上仅为事实陈述，不包含任何引申猜想
Most of the popular panel builders for private proxies on the Internet are based on Xray-core, and 3X-UI is the one with the largest market share. When I urged those panels to make changes, I once thought that @MHSanaei @alireza0, the main developer of 3X-UI, would value and be committed to completely solving this problem. However, they did not want to. Instead, other panels banned http://ip
Note: The above is only a statement of facts and does not contain any extrapolated conjectures.
I agree it is really easy to implement zerossl ip certificate I don’t know why he is insisting so much on keeping the http in a twitter thread with some iranian developers he stated that it’s because of compatibility with the previous users but it still doesn’t make sense since giving them a warning for next update and implementing it in next version is really easy
https://x.com/vahidfarid/status/1879379958432502101
@RPRX I am sympathetic to the argument you are presenting. Defaults matter, and accessibility of documentation matters. If it is true that the easiest path to setting up a circumvention web panel leads to one with a plaintext HTTP configuration, the panel software does not discourage such a configuration, and the tutorials a beginner is likely to find reinforce such a configuration, I agree that is a problem. Developers should strive to provide users with safety in the most common or default configuration. (Even if there is a way for advanced users to disable the default protections.) I agree that whether Nginx or some other software supports plaintext protocols is not relevant.
I continue to feel frustration at your techniques of advocacy. In my view, the approach you are taking is unnecessarily antagonistic, and is itself the source of some of the resistance you are encountering. My perception as an outsider is that, intentionally or not, you are creating a situation where, for your advocacy to succeed, other people must lose face. This has the effect of cementing opposition to the idea, rather than achieving acceptance of it. If a panel adopts secure access protocols in the default configuration, that should not be a "defeat" for the panel developers, but rather a victory for them and everyone else. (Keep in mind that I do not have personal experience with these panels and may be overlooking something important.)
I am not sure I agree with the "only way" of https://github.com/net4people/bbs/issues/448#issuecomment-2650999588. There may be many small and large steps that can be taken to improve the situation. Think of how Let's Encrypt caused a much greater fraction of the web to become more secure, mainly by offering convenience. Of course, if a releasing a new version of software, with backward-incompatible defaults, is required for security, then at some point its developers must bite the bullet and do it. If upstream developers are (for whatever reason) dead-set against implementing any change, then I'm not sure much can be done, other than advocacy and awareness-raising with users.
On that note, is anyone aware of panel configuration guides that show how to do it in the right way? Most YouTube tutorials give bad advice, you say; are there any that give good advice? Are there any written guides such as "How to set up 3X-UI with an SSH tunnel" or "How to set up 3X-UI with a self-signed TLS certificate"? Can you share links? If there are not, then establishing such a guide could be a good way to make progress. Even if it does not immediately become the default, it will have value for at least some users; but additionally, actually writing down the steps will reveal the major difficulties and points of friction, which can inform decisions by upstream developers to make the process easier.
why not doing anything about allowinsecure, vless + no tls.
The insecure option is provided because the connection can be unencrypted when used on an intranet, or when there is an encrypted external transport layer.
Then why VLESS or Trojan non tls is not limited to Private network IP Ranges? why not disallow non tls vless/trojan to external IPs? And why allowinsecure even exist, isn't SHA Pinning enough? the only usage of allow insecure is to help Mitm attackers If this option was not exist then v2rayNG and other clients would support SHA Pinning but i asked them and they didn't accepted because they believe it's useless when allowInsecure option is there in settings(option is global and dangerous but they prefer it instead of supporting SHA Pinning)
xtls has reminded users in the tls documentation and vless documentation that you need to have a trusted transport layer when using these features.
Read the next line from RPRX to get your answer
In fact, even the panels that do not prohibit cleartext HTTP on the public network have also added warnings about the insecurity of cleartext HTTP and reminders about SSH port forwarding in the past.
However, they still provide the option of cleartext HTTP (the most convenient, which is equivalent to the default), and there are a large number of tutorials on YouTube, all of which are http://ip/, while there are very few tutorials on secure access.
There is many tutorials that uses VLESS non TLS, if you only care about youtube then check this https://youtu.be/n3590uJANd8?t=653 is this 46k viewed video enough for you to limit non tls vless/trojan to Private IP Ranges?
Check this one with 15k subscribers and 20k telegram subscribers https://www.youtube.com/watch?v=x5oSs-eEPhY Uses 3X-UI with TLS but still uses VLESS non TLS!
And you still provide the option of cleartext non TLS VLESS/Trojan outbound to external IPs?
- Do not call it a "security issue" if it is not considered a CVE.
- YouTubers provided guidance only. People blindly copy the work of others without modification take responsibility for themselves. Neither Youtubers' fault nor users's fault is the author's fault.
- "Strongly recommended" does not mean "must", and "should not" does not mean "must not". No one has the right to slander others or force others to remove some features in their software.
- A simple warning is enough and don't try to be over-engineering. is not If one insists on continuing despite the warning, just respect their fate. However, it is the freedom of the author to add such warning or not. Software authors have no obligation to teach users how to use their software correctly. Users should have basic knowledge. AFAIK the author even made a videos about howto setup a secure panel.
- Proxy software are "universal" tools and of course are not for anti-censorship only. Why assume its scope of action?
- It makes no sense to remove a basic function of a free software. Anyone can fork and add it back and share modified versions. Why waste time in a cat-and-mouse game?
@fodhelper allowInsecure 和 pin 证书这两个功能都是源自 v2ray-core，且前者比后者早了大概五年
在 Xray-core 制定的分享链接标准中 https://github.com/XTLS/Xray-core/discussions/716 ，allowInsecure 不允许被分享，旨在阻止这样的节点被方便地传播
不过我不确定这样做是否足够，我确实考虑过彻底移除 allowInsecure 选项，但仍有一些特殊用途确实需要这个选项
这与面板不设置任何门槛即可默认的、且已经被大量滥用的、靠纯记录流量即可获取数据的 http://ip 问题的严重程度不可一语
在大量的 VLESS REALITY/TLS 教程之外，你当然可以找到 YouTuber 教 VLESS non-TLS 的例子，但是面板问题的情形是与之完全相反
@fodhelper allowInsecure and pin certificates are both features derived from v2ray-core, and the former is about five years older than the latter
In the sharing link standard formulated by Xray-core https://github.com/XTLS/Xray-core/discussions/716, allowInsecure does not allow sharing and is intended to prevent such nodes from being easily spread
However, I'm not sure if this is enough. I did consider completely removing the allowInsecure option, but there are still some special uses that really require this option
This is not to mention the severity of the problem with http://ip, which does not set any threshold and can be abused by simply recording traffic to obtain data by default.
In addition to the numerous VLESS REALITY/TLS tutorials, you can of course find YouTubers teaching VLESS non-TLS examples, but the situation with the panel problem is the exact opposite.