-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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会比使用其他端口更加安全,那么分端口就是可以接受的。 |
* 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 会禁用它吗? |
支持 @RPRX,如果方便但不安全的使用方式广泛传播成为了习惯甚至共识,那肯定是GFW非常乐意看到的。 |
如果为了安全,并达到默认情况下安全的标准,提供一个bind address选项,默认绑定到127.0.0.1,并告知用户绑定公网地址的风险就足够了(还可以同时引导用户开启https或subpath相关功能),更多的安全措施可能会是没必要的,在很多的安全模型中(例如你提到的使用SSH Port Forward)添加一个不被真的信任的自签TLS并不会比HTTP提供任何更多的安全性 如果你真的在乎安全,那么你可以使用mtls,其次http basic auth也是简单可用的 |
你猜小白是能看懂你讲的这些,还是只会跟着 YouTube 视频敲 http://ip |
跟他们说都是废话,我就是纯小白,几年前开始用XRAY,对LINUX的所有了解仅仅是“听说”,更不要说一步步买服务器搭建。没有小小白的那种文章,我不可能用了这么多年。当时我记得收藏XRAY项目的时候好像是5000不到的收藏。 |
说起来 @MHSanaei 发起的那项投票存在一个严重错误,即他没有事先向小白用户们解释公网明文 HTTP 的危害到底有多大 如果连小白用户都知道了一次明文 HTTP,导致 SS/VMess 对称密码泄露会导致 GFW 可以直接解密所有流量,TLS/REALITY 私钥泄露会导致 GFW 可以中间人攻击未来的所有连接,投票结果绝对会逆转,比如 Xray 这边支持禁止公网明文 HTTP 的人占大多数 如果用户投票的结果是 3X-UI 不禁止公网明文 HTTP 的最终借口,不知道是否可以先普及下上述知识再重新投票? |
教程做的是否详细,是否假设阅读者没有任何使用经验与教程本身内容的正确性无关 |
那么如果问题是用户是否会看的话,直接在3X-UI里面加大字报告知风险也视为一种解决办法? |
3X-UI 里已经有“大字报”了,但你平时会在意 warning 吗?小白们还是会照着 YouTube 敲 http://ip ,所以彻底封掉才能彻底解决 |
重点是我又不是说不让配置,不是说非 HTTPS 不可,开个 SSH 端口转发也没什么难度对不对,一行命令连小白都能学会 只能说是这次真触及到某些人的利益了:有想让人们用 HTTP 的 GFW,有不想流失一丁点小白用户的开发者,才会阻力这么大 |
有人说没完没了了,我想说的是,这件事还真就没完,隔三岔五我就会拿出来说,REALITY 的文章中我也会 diss 因为这件事涉及到最核心的 REALITY 私钥泄露问题,总不能我这里各种安全设计,你那里直接送出私钥,是猪队友来搞笑的吗 |
To 胡桃:GFW 一直在搞阴的,识别了协议但不封、留着监控,三四年前的代理圈几乎所有开发者都知道,没给你们说而已,具体细节看去年我在 net4people 说的那些,REALITY 公私钥的设计就是防止 GFW 拿客户端配置来解密, |
在厉害的墙国,翻墙必须以安全为第一,明明很简单的改动,有人就是想各种借口狡辩。但凡这种人,统统都能归类为“匪”,没有之一。 |
To GG Bond:自信点,Xray-core 早就是使用最广泛的代理平台了,如果没百十号人时刻盯着,你也太小瞧世界第二大经济体了 |
|
可配置的话那不到时候教程继续教怎么关,反正肯定比教怎么配ACME简单 |
查看 https://t.me/projectXtls/358 所关联的消息,Xray 应当只列出安全的 Web 面板,否则任何协议上的安全设计都是空谈
安全的 Web 面板不应允许明文 HTTP,应强制不对公网开放并让用户使用 SSH 端口转发,或者有有效证书和网页伪装的 HTTPS
@MHSanaei @alireza0 @qist @hiddify-com @Krr0ptioN @SaintShit @VZiChoushaDui
感谢各位长期以来的努力与支持,但安全漏洞不容忽视,请抓紧时间做出改变,我将于晚些时候合并这个 PR