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，况且我们本就应当只列出我们认为安全的面板，让更多人去用它们

问题太多，懒得评论，折叠了，不浪费时间

暂时 改成端口 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.

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，怎么没一个人能抓住重点？

暂时 改成端口 path 随机生成

仍是明文 HTTP？

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.

such a 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’

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监听是被动行为

只要支持acme自动更新和证书热重载 6天有啥关系呢 虽然xui及其改版好像一直都不支持证书热重载

代理服务没那么高可用性要求，就算不支持热重载，6天重启一次也没啥吧

我说的是面板软件的证书处理 xray本身一直是自动证书热重载的

@RPRX many other panels rely on self-signed certificates as well, yet they are not mentioned in the warning. Could you clarify what specifically makes 3X-UI different in this regard?

@MHSanaei With great power comes great responsibility

3X-UI 是一个出色的面板，占据了至少 50% 的市场份额，正因为如此，我们非常重视该面板的安全标准

根据 GFW 泄露出来的文件，他们有非常先进的 TLS MITM 模块，对自签证书进行 MITM 没有任何难度，所以可信的证书是必要的

acme 自动更新 IP 证书不成问题，是证书热重载有技术困难吗？

@RPRX done

@MHSanaei b38a412 README 已删除针对 3X-UI 的 WARNING 并重新将 3X-UI 添加至 Web Panel 列表

至此对于绝大多数的面板用户，GFW 都无法直接查看他们的明文 HTTP 数据了，这防止了无数的密码和私钥被直接泄露给 GFW

虽然对于高价值目标，GFW 可以选择境外伪造 IP 地址来签发 Let's Encrypt 的 IP 证书，话说这个也上了证书透明度监测机制吗

http连接就是裸奔，网络路由所有节点都可以解析所有网络数据，要求tls 加密是应该的

也要求考虑前端使用nginx反向代理的情况吧。

1. nginx +acme 申请ssl 。 xray - > nginx 这一段使用http
2. nginx + cloudflare 使用ssl。 nginx这里使用cf的自签名ssl
3. 单vps xray多协议同时使用，多域名同时使用，nginx复用80 443 端口
   都是全链路加密

═══════════════════════════════════════════
      ⚠ NO SSL CERTIFICATE DETECTED ⚠     
═══════════════════════════════════════════
For security, SSL certificate is MANDATORY for all panels.
Let's Encrypt now supports both domains and IP addresses!

Choose SSL certificate setup method:
1. Let's Encrypt for Domain (90-day validity, auto-renews)
2. Let's Encrypt for IP Address (6-day validity, auto-renews)
Note: Both options require port 80 open. IP certs use shortlived profile.
Choose an option (default 2 for IP): Using Let's Encrypt for IP certificate (shortlived profile)...

3X-UI 2.8.7 版本版本这里似乎没有考虑 xray + 3X-UI + nginx反向代理时的使用场景.

个人使用场景是：多个不同xray协议同时使用，多域名，nginx反向代理3X-UI ， 多个协议xray流量，复用80,443端口，nginx使用cloudfare自签名证书， cloudflare自动管理ssl证书。从服务器到客户端全两路ssl强加密

@MHSanaei 这样设计存在问题：
1，这里应该添加一个使用nginx 反向代理使用ssl证书的情况
2，80 443端口已经被caddy nginx等占用，这里不应该强制使用80端口
3，3X-UI 之类的ui可以默认选项安装生成自签名ssl，可以禁用http访问，没有ssl证书时使用自签名证书。可选项中应该包含nginx反向代理ssl的使用方法

@RPRX ssl 证书版本1.0 1.1存在漏洞，最好1.2版本以上。ssl加密方法，版本可以在多个地方进行验证限制，可以添加在xray里面，但也应该可以兼容nginx管理ssl

@MHSanaei b38a412 README 已删除针对 3X-UI 的 WARNING 并重新将 3X-UI 添加至 Web Panel 列表

至此对于绝大多数的面板用户，GFW 都无法直接查看他们的明文 HTTP 数据了，这防止了无数的密码和私钥被直接泄露给 GFW

虽然对于高价值目标，GFW 可以选择境外伪造 IP 地址来签发 Let's Encrypt 的 IP 证书，话说这个也上了证书透明度监测机制吗

cloudfalre对于在cf上面管理的域名有ssl证书签发监控功能，并且是免费的email通知。

证书签发机构也存在安全风险，最好不要使用客户端所在国的证书签发机关，在国内就是要使用国外的ssl证书签发机构。算是一个补充吧

国内的ssl证书签发机构发生过好几次严重事故，还可能泄漏私钥给gfw的行政风险，最好不要使用国内签发证书。即使是国外大厂，也有多次ssl证书事故

一开始就说了只是监听公网时需要有效证书啊，到底要说几遍 MHSanaei/3x-ui#3623 (comment) MHSanaei/3x-ui#3646 (comment)

我不想猜测他是故意进行有偏差的实践以让用户对 Xray-core 产生偏见，但目前确实是这么个效果，随便吧

他一刀切弄成任何情况都要自己接 TLS，有用户过去骂，他说 they made me do this，在我再次解释一遍后也没改，我也看傻了

一开始就说了只是监听公网时需要有效证书啊，到底要说几遍 MHSanaei/3x-ui#3623 (comment) MHSanaei/3x-ui#3646 (comment)

我不想猜测他是故意进行有偏差的实践以让用户对 Xray-core 产生偏见，但目前确实是这么个效果，随便吧

@RPRX 在xray的配置文件里面添加一个选项，控制ssl证书由谁管理? 在ssl管理里面标准化一下？

我想到的有xray+acme自动管理， web UI 例如3X-UI 管理，nginx管理
还可以加上证书机构，ssl版本，ssl加密方法等等控制的推荐选项

@appotry https://xtls.github.io/config/transport.html#tlsobject

@appotry 删了，我哪知道他那是什么架构，3X-UI 的问题发到 3X-UI 那边，不要来占用 core 开发者的时间，直接给他 PR 也行

@appotry https://xtls.github.io/config/transport.html#tlsobject

serverName 是否支持多域名数组更好？个人就是使用的多域名同时使用，互为备份

ssl证书可以单域名，也可以多域名，甚至支持ip，不过复杂方法一般收费很贵

可以添加下面这个
ssl证书控制方选项：xray+acme自动管理， web UI 例如3X-UI 管理，nginx管理

在某些xray协议里面，连接外网的时候一定要有一个“ssl证书控制方”，这样限制一下似乎更好？ @RPRX

ssl证书控制方选项：自签名ssl， acme自动管理， web UI 例如3X-UI 管理，nginx管理 等

xray可以新版本直接要求连接外网的时候一定要有一个“ssl证书控制方”，这样web ui就会强制适配新版了

@appotry 我记得 serverName 是仅客户端选项，服务端支持哪些域名由证书决定，所以问题不存在

面板的 TLS 跟 Xray 的 TLS 又不是一回事，改 Xray 有用的话我早改了，还是那句话，有点无端占用开发者时间了

https://hub.docker.com/r/smallstep/step-ca
https://github.com/smallstep/certificates/

step-ca 这个 ssl 管理比较完善，各种功能也有，还是go写的。无论是集成还是参考都不错

serverName是tls config的一个字段 一个字符串
acme之前写过因为依赖太大最后滚了
核心除了手动督促和人为骂两句对第三方软件没有任何约束力 这是显而易见的事

@appotry 为啥要集成那些，核心就纯粹的核心。web-ui 那边做就是了。而且你有需求就让web-ui 那边的人看看有没人愿意集成了。核心没必要做这些。自动签证书已经很成熟了。证书核心都是热加载替换就可以了。

@appotry 我记得 serverName 是仅客户端选项，服务端支持哪些域名由证书决定，所以问题不存在

面板的 TLS 跟 Xray 的 TLS 又不是一回事，改 Xray 有用的话我早改了，还是那句话，有点无端占用开发者时间了

面板的 TLS 跟 Xray 的 TLS 是不一样，我说的就是Xray 的 TLS控制方。

ssl申请的时候域名参数，我只的是这个。可以单域名，泛域名（*.domain.com），多域名，ip证书，混合形式等等

叫什么名字无所谓，如果没有前端cdn管理多域名ssl证书，https://xtls.github.io/config/transport.html#tlsobject 这里看起来似乎没有支持多域名ssl证书，也没有支持混合形式的证书

反正从个人观点来说，core 不要弄那些乱七八糟的东西 core 所用的证书一样可以让web-ui 来处理就是了。

@appotry 为啥要集成那些，核心就纯粹的核心。web-ui 那边做就是了。而且你有需求就让web-ui 那边的人看看有没人愿意集成了。核心没必要做这些。自动签证书已经很成熟了。证书核心都是热加载替换就可以了。

是没有必要支持这个，但如果强制使用，就应该支持常见场景。

xray tls ech --serverName example.com 我看到使用示例，这里最好支持多域名，泛域名，ip域名等等，从说明来看似乎只支持单域名

从功能上来说，step-ca和web ui集成更好。直接使用cdn管理ssl证书最方便，例如cloudflare

哥们这套东西原理是什么都不知道就别指点江山了吧

ssl证书控制方选项：自签名ssl， acme自动管理， web UI 例如3X-UI 管理，nginx管理，cdn 等，其实也就是划分内部、外部ssl控制，命名可以细致化。（这里的确只能控制xray的tls证书，web证书在core没法控制，但如果强制xray tls参数控制，可以提醒webui 使用ssl）

xray可以新版本直接要求使用tls的时候一定要有一个“ssl证书控制方”，不能为空，只能是上面指定列表中的参数。这样web ui就会强制适配新版了，指定xray tls参数的时候，就会解决下面场景兼容问题（可以要求至少支持内部，外部ssl两种方法以上）

═══════════════════════════════════════════
      ⚠ NO SSL CERTIFICATE DETECTED ⚠     
═══════════════════════════════════════════
For security, SSL certificate is MANDATORY for all panels.
Let's Encrypt now supports both domains and IP addresses!

Choose SSL certificate setup method:
1. Let's Encrypt for Domain (90-day validity, auto-renews)
2. Let's Encrypt for IP Address (6-day validity, auto-renews)
Note: Both options require port 80 open. IP certs use shortlived profile.
Choose an option (default 2 for IP): Using Let's Encrypt for IP certificate (shortlived profile)...

另外可以在xray 的readme里面大写黑体，亮眼如红色提醒webui 使用https，特别是订阅一定要使用https。

3X-UI 支持 api 访问控制，使用http是泄漏了所有信息

没法解决所有问题，能解决部分问题也是好的，不能解决问题，提醒解决问题也是好的 @RPRX 是否有参考价值？

可能什么问题都没解决，但是有骚扰价值

@RPRX
Recently, letsencrypt support IP certificate. Therefore, it would be helpful to recommend all the panels to use valid IP certificate.

PS. Hiddify has already added IP certificate.

@hiddify-com 这是在说那个谁吧😁