README.md: Only list secure web panels #3884
Conversation
|
forcing https is not good, for example i use haproxy to put all my services ( phpmyadmin , marzban , webhooks and... ) behind single port, that's where i use my certificate not on marzban |
|
@MHSanaei Your favorite， |
|
有的人把面板放在nginx后面（二楼说的那样） |
不是强制 HTTPS，我的意思是，强制不对公网开放，直到用户配置了有效证书以及网页伪装（base path 分流），且只允许 HTTPS |
相当一部分用户就没买域名，只想用不需要域名证书的协议如 REALITY，哪来的有效证书？“连接panel大概也不是直连”是错误说法 |
|
Those panels made all options available, it's user's job to not misconfig it |
但凡你有点研究，就会知道“最不安全的因素就是人”已经是共识，一开始就该设计好规则来限制人为因素的影响，比如 Rust 并且我不认为要求安全实践是 unnecessary pressure，况且我们本就应当只列出我们认为安全的面板，让更多人去用它们 |
This comment was marked as spam.
This comment was marked as spam.
|
|
|
暂时 改成端口 path 随机生成 |
|
Marzban and Marzneshin use nodes, and the proxy server runs on these nodes, not the main panel. The connection between the nodes and the panel is fully encrypted with mTLS, so there’s no way it’s exposed to the public. The user and GFW don't even know about the main server – it’s only there to monitor the user from the nodes. So, trying to force anything through this method is pointless for a panel like this. Also, I should mention – using a 256-character path makes any idea of panel probing useless. There's no need to force the user through TLS. I would suggest being a bit more flexible in these cases – Xray Core has much more significant topics to focus on rather than getting too involved in how panels operate. It's a good point, though. But there's no need to be overly harsh, as it could lead to unnecessary backlash. |
What's you guys' problem? 我要求 SSH 或 TLS 的主要原因是 防止 GFW 记录你操作面板时产生的明文 HTTP 流量，NOT probing，怎么没一个人能抓住重点？ |
仍是明文 HTTP？ |
Hiddify already uses self-signed certificate for people who don't own any domain, but it's in the list too
Marzban nodes are exposed to public and detectable because they used 'Gozargah' as CN of their mTLS certificate
Just change default listen ip to localhost to force users to config a valid TLS or use SSH port forwarding to access their panel (although everyone will bypass it and use HTTP again lol) |
|
This enforcement is against the main goal of panels which is simplicity. In another hand, admins will reach the panel only in case of any need. But usage of core is always active between clients and server ports. IMHO alerts in panel are enough. |
|
Counterproposal:
I think the combination of those two requirements will set the right incentives, and there is no need to think about how to get encrypted HTTP by default in panels' one-click installer, or whether the panel is behind nginx. I think it would still be nice if panels ask for a domain in their one-click installers and automatically install SSL and set the right subscription URLs, but it can be left for future research. I think SSH port forwarding is "too difficult" and also doesn't give you a working solution for subscription URLs anyway. Path prefixes are offtopic for this discussion -- they are important security features but it's not what RPRX is pushing for right now. |
|
The primary advantage of using an HTTPS connection is to prevent MITM from accessing packet contents in plain text. However, for scanners, this provides little benefit as they can still gather information if the root or a simple base-path is left exposed. The only effective method for restricting public access to the admin panel is through a secure tunnel. |
SSH Port Forwarding |
|
I think it's just a matter of making the panel only listen to 127.0.0.1 by default and then a reminder to use SSH port forwarding, and if the user tries to reverse proxying or whatever, it's their fault and ‘we've tried to protect their data’ |
SSH port forwarding, also known as SSH tunneling |
|
我发起这个 PR 的核心意图是给这些面板说：不要搞明文 HTTP 以避免被记录 我不懂为什么这个难以理解，为什么不断有人提 irrelevant 的“随机路径” 甚至有支持这些面板的 end-users 给我点 thumbs-down，不知道你们有没有注意到，APT-ZERO 是第一个，你们正在追寻他 多少有点搞笑，不是，是太搞笑了 |
|
我推荐 SSH 端口转发的原因是，每个桌面操作系统都内置了 SSH，只需要一条命令即可开启端口转发，并不困难 自签 TLS 证书的特征过于明显，并且要占用 443 端口，会和 REALITY 冲突（非自签可能也是），所以我不推荐 至于 @mmmray 提到的订阅，我认为客户端应要求正常的 HTTPS，毕竟订阅可以是独立的地址，不需要和节点们在同一机器上 |
|
虽然自签特征明显，但是特征也不具有唯一性，毕竟现存的很多web管理面板基本上在不设置有效证书的情况下就是使用的自签，以至于443占用……实际使用的时候很多用户会分不同端口，当然想共用端口，现在也有stream分流可以和reality共存。 |
这样的话，应当同时装上其它面板比如 wordpress，然后路径分流到 Xray 面板，但自签证书防不了中间人攻击
“实际使用的时候很多用户会分不同端口”这条不对吧，还有“stream分流”违背了 REALITY 的安全要求 |
|
中间人问题，没记错的话可以通过指定和在本地信任特定证书解决。以至于reality 443端口问题，现在既然没有证据证明使用443会比使用其他端口更加安全，那么分端口就是可以接受的。 |
|
怎么这个问题能搞上这么久啊 其实事情也很简单，建议面板作者维护者作出默认情况下足够安全的修改，修改通过则可以继续留在 Xray-core 的 README 里面（相当于是一种认可和宣传），不通过或者不计划修改就从 README 移除，并不是一定要改了才能使用。 至于明文 HTTP，它的问题是传输路径上任何人都可以看到传输的内容并且可以被注入修改，这个是已经明确存在的问题，不只是 HTTP 头能被看到，网页内容也能被中间人轻易阅读甚至被修改，要是明文 HTTP 没这些问题那么现在流行 HTTPS/TLS 的原因又少了两个。 挺赞同这次修改的，而且也同意 #3884 (comment) 所言，毕竟作为一个反审查的工具来说，有时候因为使用的周边项目设计欠妥导致被封，那么小白一般不会骂周边项目而更可能会认为是主项目的问题（就像是 Windows 上面有个写得不好的第三方驱动导致系统更新之后发生问题，但是用户一般不会骂第三方而是骂微软一样），莫名其妙背黑锅，主项目的开发也很难做。 既然业界都在采用 HTTPS/TLS 作为主流，那么这个方案也是通过了大家都实践认可。同样，SSH 作为一个广泛使用不断发展的协议，其安全性也毋庸置疑，用 TLS 或者 SSH 转发来封装 HTTP 流量无疑是合适的（而且现在操作系统几乎都能用 SSH，配置上为了安全多走一步也是可以的）。 一句曾经很流行的话：理想很丰满，现实很骨感。在安全上面尤其如此。不能说“怎么使用软件都是自由的”作为默认就不安全的借口，对于会面向非专业人士的工具来说安全总是要排首位的，更别说大部分人都是直接用默认配置的。 对了再补点事实：谷歌退出大陆事件的时候，不用 HTTPS 来搜索特定字词是可以触发来自审查的连接重置的。审查明文 HTTP 其实不太难，但是在需要高截杀率的关键时期会不会再上这类措施是真的不好说。 |
|
@QqhaZxAtbwhhk2Gl 的后续回复我删了，这就是个非蠢即坏的典型代表，不删的话看一次想吐一次，想反驳他吧又会浪费时间，好奇的可以看 https://t.me/projectXray/4027091 以及群友的反应和评价，“这不是晶哥 我不知道谁是了”，blocked 这个小号 |
我都没想到这问题甚至需要讨论，只能说非蠢即坏的人太多了 赞同你的看法：如果要做一个基于 Xray 的东西，必须在默认情况下足够安全而不是破坏 Xray 的安全性，否则动机会被合理怀疑 这件事没得洗，问他们明文 HTTP 对用户有什么好处，他们答不上来还说反正免责、就是不改，只能认为他们已经被 GFW 收买了 |
|
以及，有人觉得我写在 README 中的 Warning 措辞不恰当，damaging the community 什么的，我重申一遍： 默认支持公网明文 HTTP、并导致大量用户滑落至公网明文 HTTP 的面板才是 damaging the community 且鉴于这种行为等价于已被 GFW 收买，我不认为我与他们还有任何 friendly relationship 需要维护， 当然也有小概率不是坏、就是蠢，总之效果是等价的，他们就是纯粹的帮了 GFW，所以我觉得我的 statement 恰如其分 |
That's why the panels should remove http://ip entirely, instead of "let the user choose", as they are "choosing" the wrong way |
|
x-ui usually show it's not secure whenever I connect to the web panel without SSL. Unless they've removed all of the warnings and just defaulting to the plain http, I don't see a problem. That said, I don't know anything about their affiliation with the gov but if it's true, it's better safe than sorry. |
I don't see a problem? 你们这些人就是理解不了问题的关键，我最后说一遍 这个安全要求并不是为知道 TLS 的必要性并使用 HTTPS 的人准备的，而是为看个 YouTube 视频就跟着输入 http://ip 的小白们准备的，他们才是占绝大多数，小白永远是最多的，所以需要把 http://ip 这条路堵死，让他们不得不使用 SSH 端口转发 所以你们觉得加个 warning，然后让用户选择就够了，其实远远不够，因为小白并没有什么判断能力，你们也都是这么过来的 这个安全要求，就是为了让占绝大多数人的小白也不至于把本应只存在于服务端的密码、私钥等泄露给 GFW 麻烦你们有点人性，而不是冷冰冰地看着小白去送人头、坐视不管，谁当年不是小白？ |
|
I’ve been silently watching what’s been happening within and around the community over the past week, and I’m simply shocked. Throughout the discussions, I haven’t heard a single convincing argument or reason for keeping access to the panel via HTTP. And do you know why? Because there simply is no valid argument or reason for it. Instead of accepting this as a given and implementing it in their software products, some developers are actively sabotaging it. For example, in the case of Marzban, external developers released a special guide and repository to reinstate insecure access. Some in the community are even attempting to report the xray-core repository on GitHub to have it blocked due to the new warning message. Arguments and debates are happening in every local chat about this. I really can’t understand—does this simple truth that one should not interact with the panel (or any site, for that matter) via HTTP really warrant such resistance? What are the developers’ reasons for opposing this? What is their interest or gain? Many claim it’s in the users’ best interest, but no, they’re actually harming their users by allowing the panel to be used in this way. Some mention warnings or banners in the interface, but users disregard these banners. Some developers resist simply because they feel someone is dictating what they should do, not realizing that the problem has become so large it can no longer be ignored, and now even third parties have to intervene. I want to thank every engineer, programmer, hosting provider, guide creator, and anyone else who has responded to this issue and helped make these tools much safer to use. Thanks to you, GFW will have fewer reasons and opportunities to hinder access to an open internet. Once again, a huge thank you to all. And to those who oppose this, I urge you to reconsider your responsibility to your users. If you can’t help, at least don’t hinder. |
|
* README.md: Only list secure web panels * List Marzban * List Xray-UI * List Hiddify * Add warning * Update warning
|
The latest 3x-ui update raises some questions:
Disabling HTTP access should be a basic requirement; without it, there’s no point in further bypassing censorship. If a security measure is optional, users will likely ignore it, especially if it makes using the panel easier. You refer to user opinion by holding a poll, but making decisions in such matters requires at least some level of competence. Most users tend to choose the simplest option, often knowingly ignoring risks for the sake of convenience. In my opinion, this feature should be enabled by default. |
|
我觉得从另一个角度解读 @MHSanaei 发起的这个投票 https://t.me/XrayUI/203 ，已经很能说明问题了： 将近一半人反对禁用公网 HTTP，这说明绝对不要把安全问题的选择权交给你的小白用户们，我都说了他们没有什么判断能力 |
|
前面还有很多人说 let the user choose，这下就很搞笑了吧 投反对的加上投无所谓的加上投不知道的，这说明绝大多数人 choose 了公网明文 HTTP，现在还喜欢 let the user choose 吗 |
|
|
@junx964 |
~~ 面板全是面对小白的？， 有点技术的去手搓，不然不支持自定义？ ~~ |
因为眼瞎，什么时候说过要把内网明文 HTTP 也禁了？ |
|
Because having options isn't a bad thing. That said, I agree we should make HTTPS the default. When I first set up my Xray server, it took me two weeks to understand everything then actually make it work, and HTTPS was the last of my concerns. If people are just following a YouTube video to the letter, they're likely to ignore any warnings. But I also understand the other side of the argument—you can’t fully foolproof anything if the user isn’t being careful. |
|
我看到 @MHSanaei 发了一个关于 SSH port forwarding 的视频 https://t.me/XrayUI/207 ，应该已经明白了这么简单的操作对小白来说也没难度，没必要再留着公网明文 HTTP，所以 3X-UI 会禁用它吗？ |
查看 https://t.me/projectXtls/358 所关联的消息，Xray 应当只列出安全的 Web 面板，否则任何协议上的安全设计都是空谈
安全的 Web 面板不应允许明文 HTTP，应强制不对公网开放并让用户使用 SSH 端口转发，或者有有效证书和网页伪装的 HTTPS
@MHSanaei @alireza0 @qist @hiddify-com @Krr0ptioN @SaintShit @VZiChoushaDui
感谢各位长期以来的努力与支持，但安全漏洞不容忽视，请抓紧时间做出改变，我将于晚些时候合并这个 PR