XTLS
README.md: Only list secure web panels
查看 https://t.me/projectXtls/358 所关联的消息，Xray 应当只列出安全的 Web 面板，否则任何协议上的安全设计都是空谈
安全的 Web 面板不应允许明文 HTTP，应强制不对公网开放并让用户使用 SSH 端口转发，或者有有效证书和网页伪装的 HTTPS
@MHSanaei @alireza0 @qist @hiddify-com @Krr0ptioN @SaintShit @VZiChoushaDui
感谢各位长期以来的努力与支持，但安全漏洞不容忽视，请抓紧时间做出改变，我将于晚些时候合并这个 PR
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，~~有人注意到我那天在 Project X Community 后面加上了 Not Porn-jet X Hub 吗~~
有的人把面板放在nginx后面（二楼说的那样） 要我看顶多默认引导用户设置证书和路径（大多数时候可能路径都够了 因为连接panel大概也不是直连）
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
不是强制 HTTPS，我的意思是，强制不对公网开放，直到用户配置了有效证书以及网页伪装（base path 分流），且只允许 HTTPS
要我看顶多默认引导用户设置证书和路径（大多数时候可能路径都够了 因为连接panel大概也不是直连）
相当一部分用户就没买域名，只想用不需要域名证书的协议如 REALITY，哪来的有效证书？“连接panel大概也不是直连”是错误说法
Those panels made all options available, it's user's job to not misconfig it you make unnecessary pressure on developers
Those panels made all options available, it's user's job to not misconfig it you make unnecessary pressure on developers
但凡你有点研究，就会知道“最不安全的因素就是人”已经是共识，一开始就该设计好规则来限制人为因素的影响，比如 Rust
并且我不认为要求安全实践是 unnecessary pressure，况且我们本就应当只列出我们认为安全的面板，让更多人去用它们
a valid ssl certificate by default is not possible and i am sure nobody will use SSH Tunnel! to access their Panel I guess the best is to create a random self signed certificate for each installation (at Marzban Install Script)
or you can use your REALITY project experiment to make a valid ssl cert for everyone(w/o need to buy a domain)!
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.
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.
What's you guys' problem?
我要求 SSH 或 TLS 的主要原因是 防止 GFW 记录你操作面板时产生的明文 HTTP 流量，NOT probing，怎么没一个人能抓住重点？
This enforcement is against the main goal of panels which is simplicity. An advanced user knows about security principles and will follow! Please be informed that people can use a simple reverse-proxy to access web panel via pure http and even remove the base-path.
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:
- clients should only accept subscription URLs with HTTPS -- Streisand already does this. It's not clear to me how v2rayNG would transition existing installations -- maybe show a huge warning or attempt a redirect?
- panels should enforce HTTPS redirects for the entire panel if the subscription URL prefix is HTTPS, because then it can be assumed that SSL is set up correctly (at least for the subscription, but I think most of the time, subs and admin are hosted on the same domain)
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. However, implementing such a tunnel falls outside our scope and responsibility. It is up to the panel administrator to choose from the thousands of available solutions.
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’
such a tunnel
SSH Port Forwarding
SSH port forwarding, also known as SSH tunneling
https://t.me/projectXtls/370
我发起这个 PR 的核心意图是给这些面板说：不要搞明文 HTTP 以避免被记录
我不懂为什么这个难以理解，为什么不断有人提 irrelevant 的“随机路径”
甚至有支持这些面板的 end-users 给我点 thumbs-down，不知道你们有没有注意到，APT-ZERO 是第一个，你们正在追寻他
多少有点搞笑，不是，是太搞笑了
我推荐 SSH 端口转发的原因是，每个桌面操作系统都内置了 SSH，只需要一条命令即可开启端口转发，并不困难
自签 TLS 证书的特征过于明显，并且要占用 443 端口，会和 REALITY 冲突（非自签可能也是），所以我不推荐
至于 @mmmray 提到的订阅，我认为客户端应要求正常的 HTTPS，毕竟订阅可以是独立的地址，不需要和节点们在同一机器上
虽然自签特征明显，但是特征也不具有唯一性，毕竟现存的很多web管理面板基本上在不设置有效证书的情况下就是使用的自签，以至于443占用……实际使用的时候很多用户会分不同端口，当然想共用端口，现在也有stream分流可以和reality共存。 但总而言之，需要解决的问题是“ 不要搞明文 HTTP 以避免被记录”，那么无论是SSH转发和自签SSL都可以解决这个问题，那么就是好方法，以至于具体选择哪个，还是给面板开发者自行选择比较好，毕竟无论哪个方法都已经解决了现有需求
虽然自签特征明显，但是特征也不具有唯一性，毕竟现存的很多web管理面板基本上在不设置有效证书的情况下就是使用的自签
这样的话，应当同时装上其它面板比如 wordpress，然后路径分流到 Xray 面板，但自签证书防不了中间人攻击
以至于443占用……实际使用的时候很多用户会分不同端口，当然想共用端口，现在也有stream分流可以和reality共存
“实际使用的时候很多用户会分不同端口”这条不对吧，还有“stream分流”违背了 REALITY 的安全要求
中间人问题，没记错的话可以通过指定和在本地信任特定证书解决。以至于reality 443端口问题，现在既然没有证据证明使用443会比使用其他端口更加安全，那么分端口就是可以接受的。 但无论是是否安装其他面板，对SSL下的中间人攻击的考虑，面板使用ssl导致的reality端口冲突问题，都已经超出“ 不要搞明文 HTTP 以避免被记录”这个问题本身的范畴，就我个人意见上来讲，强制启用HTTPS或者SSH转发应该是针对这个问题本身最好的解决方案。
强制监听127.0.0.1，仅允许在https连接面板的情况下更改监听地址，在SSH上打印证书指纹，然后登录时强制校验（？ 一点拙见 ~~中间人攻击应该算主动行为吧~~ ~~明文HTTP监听是被动行为~~
强制监听127.0.0.1，仅允许在https连接面板的情况下更改监听地址，在SSH上打印证书指纹，然后登录时强制校验（？ 一点拙见
我个人（仅代表个人）认为比较推荐的配置： 1.默认 初次安装监听127，用户通过ssh编辑配置文件/选择更改监听IP。 2.强制 启用HTTPS，移除HTTP访问，初次安装使用自生成证书，界面提示用户尽快更换有效证书。 3.增加SSH转发配置途径。
在这里建议再多，至今也没有一个面板遵循安全建议，就差把那行 SSH 端口转发命令贴上来了。协议设计得再好，GFW 还是能通过明文 HTTP 拿到你的对称密码来解密流量、拿私钥来中间人攻击，或者直接封锁服务器，然后小白们又会叫“Xray 被封了”。
我觉得非 core 开发者，以及数量最多的、这些面板最广泛的支持者们（小白）是因为缺乏专业知识而没有意识到问题的严重性。
或许我应该直接给他们说：你一次 HTTP 明文，只要 GFW 想，你后续的代理流量对它来说都是明文，TLS、REALITY 形同虚设。
现在意识到这个问题有多严重了吗？
虽然我觉得这样管太宽不好 不过还是提供一个办法 可以考虑用 cloudflared 的 quick tunnel 建立一个反向直接穿出来 也不需要域名不需要直接连接服务器 https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/do-more-with-tunnels/trycloudflare/
虽然我觉得这样管太宽不好
不是管太宽，这就是目前 Xray 生态中最大的安全漏洞，因为用面板的人是最多的，可视化的东西对新手来说是最简单的
想象一下，你是一个新手，翻出来一段时间后想自建，YouTube 上基本都是教你用面板，然后 http//ip，bingo
很难想象去年我第一次看到这样的视频时，看到 http://ip 时有多震惊，我都没想过还能有这种操作
保守估计 80% 以上的 Xray 服务端都是这样搭的，~~再这样下去我可要写 panel-killer 了，把你上 pornhub 的记录都列出来~~
Since all the newcomers want is a mean to connect, it is of a somewhat unrealistic expectation to get them roped into any sense of safety, not to mention experienced users may not follow conventional configurations either, compromises have to be made. Here are my own pennies for the thought.
- Define a customizable list of trusted sources, which should permit SSH port forwarding as well as niche setups. Defaults to
10.0.0.0/8,127.0.0.0/8,fc00::/6and200::/7, and a warning should be present when the list is being modified. - If access is attempted from outside the list of trusted sources, TLS is demanded but not required. A disruptive warning should be displayed whenever unprotected access is established, something along the lines of "Issues rose from configuring via unsafe channels are ignored unconditionally".
cloudflared tunnel suggested by @Fangliding seems to be a good alternative too.
