如何搭建HTTPS代理？

[aaro-n]

本人情况说明：

自建已经使用v2ray搭建一个代理，并且使用良好（感谢v2ray项目）。目前碰到一些问题：

1. 使用场景
   1.1 手机上有些软件需要使用v2ray才能访问，软件本身支持设置代理，例如Telegram（socks，MTProxy），Twidere（https）。我想让软件直接设置https代理，不用开v2ray全局（我知道可以设置哪些软件不走代理，但就是不想运行个科学上网软件）。
   1.2 电脑上chrome的SwitchyOmega插件可以设置https代理，桌面端Spotify也可以使用https代理......,电脑上运行的v2ray转socks或https，也可以正常使用。我想让翻墙无感化。
2. 一些想法
   2.1 由于有vps，想要在vps搭建http代理，最好可以在前边使用nginx作为前置。用户-->nginx前置代理-->http翻墙代理，因为还有其他项目，无法空出80和443端口。
   2.2 一些疑虑 因为想要软件直接使用，软件的代理界面会出现用户名和密码，在使用https的情况下，用户名和密码会不会泄漏？例子：https://user:[email protected] ，这个user:pass会不会在公网被明文传输？（因为会用到nginx的htpasswd用户认证，不知道理解的对不对）。
   2.3 GFW HTTP翻墙使用量不会太大，并且有被墙IP或域名的心里准备，被封也无所无，但也希望不要被墙，有些想法：如果user:pass不被明文传输，有没有那种user:pass正确，就可以正常翻墙，无user:pass或者user:pass错误就展示一个正常网站，加强隐秘性。
3. 查找资料
   因为使用v2ray非常好，查找v2ray资料，发现v2ray的http代理不符合我的要求（不想要翻墙客户端打开），用中文和英文在Google上搜索了，都没有找到符合要求的项目（可能关键词不对），因此来这里求助。

   总结：因为一些软件内置http代理，想要在不开翻墙代理的情况下，直接填入域名和用户名密码直接使用。

一些软件代理设置界面截图：

[rowheel]

This shall not be achieved with v2ray-core; try caddy-server instead.

[sundi117]

楼主这个问题想出方案了吗？

[mydogshitgold]

HTTPS is TLS coupled with HTTP in such a way that once the TCP connection is established, a TLS handshake is performed, creating an encrypted tunnel between the client and the server. All HTTP traffic within the tunnel is encrypted, including the URL (so your user:pass is encrypted). However, the TLS handshake does expose information such as the ports, addresses, application layer protocol (alpn), domain name and server certificate.

Theoretically, you should be able to use a web server as a TLS termination proxy for the V2Ray http proxy and simultaneously serve web pages on the same port. Refer to your web server documentation to learn how to do this.

However, HTTP proxy over TLS (aka HTTPS proxy) has many disadvantages.

• It provides weak obfuscation, which can lead to blocking.
• It lacks multiplexing.
• Communication over an HTTPS proxy suffers from much higher latency than stateless protocols such as VMESS, Shadowsocks. Each request sent through an HTTPS proxy requires at least 2 additional round trips (TCP, TLS).

EDIT: less confusing terminology

[nursery01]

However, the TLS handshake does expose information such as the ports, addresses, application layer protocol (alpn), domain name and server certificate.

When both the browser and the server support ECH, how much information an attacker can extract from a certificate?
domain name? time? Get the CA by query up? Or these are encrypted, only password and algorithms?

[mydogshitgold]

When both the browser and the server support ECH, how much information an attacker can extract from a certificate?
domain name? time? Get the CA by query up? Or these are encrypted, only password and algorithms?

If I recall correctly, the ClientHelloInner is completely encrypted, so an attacker in the privileged position can only extract TLS version, packet length, timing, ECH public key, cipher suite, and additionally the whole (not so important) ClientHelloOuter. I don't think they can extract the actual SNI. But you should know that the attacker may just try to force a clear text client hello by dropping or blocking any ECH packets, and they have every reason to do so.

If you want to see for yourself you can capture some QUIC initial packets with wireshark, whichs support decrypting them. Currently the ECH private key used in QUIC is well-known.

---

You can read this blog by cloudflare about ECH

[nursery01]

If I recall correctly, the ClientHelloInner is completely encrypted, so an attacker in the privileged position can only extract TLS version, packet length, timing, ECH public key, cipher suite, and additionally the whole (not so important) ClientHelloOuter. I don't think they can extract the actual SNI. But you should know that the attacker may just try to force a clear text client hello by dropping or blocking any ECH packets, and they have every reason to do so.

I opened ECH in firefox. ->https://github.com/nursery01/browser-ech
I tried fetching data before, but i see "crypto.cloudflare.com" in client hello. I don`t know why.

If you want to see for yourself you can capture some QUIC initial packets with wireshark, whichs support decrypting them. Currently the ECH private key used in QUIC is well-known.

I was just about to check server hello, my pc power is cut✂️by family, so experiment end.



Maybe my way is wrong😐

[mydogshitgold]

I tried fetching data before, but i see "crypto.cloudflare.com" in client hello. I don`t know why

That's the ClientHelloOuter, and crypto.cloudflare.com is the client-facing server for cloudflare edge. If you are confused, read the IETF draft.

[nursery01]

That's the ClientHelloOuter, and is the client-facing server for cloudflare edge. If you are confused, read the IETF draft.crypto.cloudflare.com

ok, i understood now. But the browser still exposes the sni

Maybe v2ray can exploit this mechanism to cheat

ClientHelloOuter sni=www.cloudflare.com (false)
ClientHelloInner sni=cute.cat.abc (true)