公网开放服务通过 https+basic auth 是否能抵御一些 0day 漏洞？
从这次飞牛 0day 这么恶劣的影响来看，在公网上开放服务真的是非常危险，尤其是碰到 0day 漏洞持续这么久不作为，更加重了影响。
我为了方便一些服务使用，比如 dokuwiki, mtphotos 以及自己用 docker 部署的一些小工具，都还是开放了公网的端口访问，采用 DDNS 。
目前我的方案是这样，即使服务原生还权限验证包括什么 2FA 啥的，我都把它们部署在内网提供 http 服务，然后自己部署了一套 caddy （之前是用 nginx)来提供 https 再加一层 basic auth 认证。
比如 dokuwiki 和 mtphotos ，他们本身都有用户名认证，但是我在外网需要访问的时，打开对应的端口时需要先输入外层的 basic auth 认证才会进入这些服务自己的登陆界面，再输入用户名密码。
这套方案是之前在公司部署 jira 和 confluence 时折腾出来的，老早部署了 jira 之后三天两头被网关发邮件说有漏洞，后来在外面套了一层 https+basic auth 之后就再也没被扫到过了。
按我的理解，这些漏洞不管怎么严重最终都是需要通过开放的端口来进行命令注入的，只要最外层的 https basic auth 不泄漏其实他们就进不去那些有漏洞的服务端口。
这个方案有两个缺点，一是每次需要输入两次认证，有些浏览器似乎会较长时间记住外层的 basic auth 比如 firefox 但是 safari 就需要每次都输入（不过只要网页不关闭就不需要重复输入）；二是有些服务是占用了 http header 里的 auth 字段导致外层的 basic auth 和服务的用户认证冲突。
这里要表扬一下 mtphotos ，最早的时候 mtphotos 就是使用了 http header 里的 auth 字段来传输认证导致和我外层的 basic auth 冲突，后来在群里提出这种用户之后（虽然有其它用户不屑这种用法），作者很快就更新了认证机制，现在不管是网页打开 mtphotos 还是 app 连接 mtphotos 都支持这种双层认证。
不知道这种方案有没有其它缺陷？ https 的 basic auth 应该是最简单粗暴，除了中间人攻击外应该不会有什么漏洞绕过吧？
我为了方便一些服务使用，比如 dokuwiki, mtphotos 以及自己用 docker 部署的一些小工具，都还是开放了公网的端口访问，采用 DDNS 。
目前我的方案是这样，即使服务原生还权限验证包括什么 2FA 啥的，我都把它们部署在内网提供 http 服务，然后自己部署了一套 caddy （之前是用 nginx)来提供 https 再加一层 basic auth 认证。
比如 dokuwiki 和 mtphotos ，他们本身都有用户名认证，但是我在外网需要访问的时，打开对应的端口时需要先输入外层的 basic auth 认证才会进入这些服务自己的登陆界面，再输入用户名密码。
这套方案是之前在公司部署 jira 和 confluence 时折腾出来的，老早部署了 jira 之后三天两头被网关发邮件说有漏洞，后来在外面套了一层 https+basic auth 之后就再也没被扫到过了。
按我的理解，这些漏洞不管怎么严重最终都是需要通过开放的端口来进行命令注入的，只要最外层的 https basic auth 不泄漏其实他们就进不去那些有漏洞的服务端口。
这个方案有两个缺点，一是每次需要输入两次认证，有些浏览器似乎会较长时间记住外层的 basic auth 比如 firefox 但是 safari 就需要每次都输入（不过只要网页不关闭就不需要重复输入）；二是有些服务是占用了 http header 里的 auth 字段导致外层的 basic auth 和服务的用户认证冲突。
这里要表扬一下 mtphotos ，最早的时候 mtphotos 就是使用了 http header 里的 auth 字段来传输认证导致和我外层的 basic auth 冲突，后来在群里提出这种用户之后（虽然有其它用户不屑这种用法），作者很快就更新了认证机制，现在不管是网页打开 mtphotos 还是 app 连接 mtphotos 都支持这种双层认证。
不知道这种方案有没有其它缺陷？ https 的 basic auth 应该是最简单粗暴，除了中间人攻击外应该不会有什么漏洞绕过吧？