隔壁漏洞贴延伸，纯使用 tls 进行不可描述行为时的可行性？

[imdong]

看到隔壁帖子说的漏洞，就想目前应该很多人都是 +tls 后使用的，似乎实际上起保护作用的是 tls ？

既然如此，为何不直接使用 tls 呢？

刚刚动手在海外服务器上配置了一下 Nginx，

location /confused {
    proxy_pass https://$http_x_host/;
}

似乎原理上没啥问题（这不就是原来的 WebProxy 嘛），如果只是浏览器使用，似乎都不需要安装客户端（但 JS 方面体验不好）

验证上上，也可以直接使用 ngx_http_auth_basic_module ，

至此只需要做一个客户端，简单的将请求中的 Host 转换为 X-Host 就可以了？

看到 他们在 Github 上也有人提议直接使用 tls 作为保护？为何没人响应？

我自觉点，直接发到水深火热了。。。

2020-6-2 17:17:18 Update: 不死心，我挪到问与答了，等会也许又进去了。。。

[msg7086]

当然可以，SNI 造假然后内部拿真实域名连接。
然而这只能跑 HTTP 协议啊，其他软件咋办？又不是只有浏览器需要攀爬。

[imdong]

@msg7086 [哦!.jpg]
是的，突然想到这一层，似乎可以用自签可信根证书来搞定这个问题。

或者是和现在同样，本地创建一个 SOCKS5/HTTP 代理，然后将 https://www.google.com/test 转换为 `https://jump_server/confused --header "X-Uri:https://www.google.com/test"

[msg7086]

只考虑 HTTP 协议的话怎么都行啦，你可以找找 Domain fronting 的资料。

反正不管怎么说，你这都没法解决纯 TCP 和纯 UDP 的连接问题，最终你还是要在 TCP 和 UDP 上加入对方的 IP 和端口，以及验证信息，然后重新发明酸酸或者肥二。

[imdong]

@msg7086 谢谢 我懂了 之前只考虑了 http/s，没想到纯 TCP/UDP 。谢谢。

[codehz]

其实你这个想法就是以前的网页代理，现代版的也有就是那个 jsproxy