Support for https proxies in Tendermint RPC

[zmanian]

During the stargate launch the earlier available RPC node was the cosmostation's node. I couldn't use it because it was behind an HTTPs proxy.

Tendermint RPC uses the Tendermint Address type which only takes TCP as a network protocol. As result the information to perform an HTTPS handshake on connection isn't passed to hyper when constructing a http connection.

It would be nice to be able to support https proxies.

I suggest we extend the Address type to natively support http and https.

[thanethomson]

So just to clarify here, is this TLS proxy transparent? i.e. it's not an HTTP proxy, but a TLS/TCP proxy?

[tony-iqlusion]

HTTP CONNECT proxies are effectively TCP proxies which piggyback on HTTP for initial setup which specifies the egress destination.

They can be used for any TCP-based protocol. When an HTTPS (or other TLS) session is negotiated over them, they provide end-to-end encryption where the proxy sees only ciphertext.

[thanethomson]

Some discussion I had with the team about this issue yesterday resulted in a little confusion for me wrt your use case. At the risk of being overly verbose, but for the sake of clarity, which of the following two types of proxies best describes your requirement right now?

1. A simple reverse proxy (like a TLS-enabled Nginx proxy, where requests are decrypted at the Nginx server and forwarded in the clear to the RPC endpoint). Here, using hyper-proxy doesn't make sense, and we should rather just enable outgoing TLS connection support (i.e. via hyper-rustls).
2. An HTTP proxy (i.e. we need to send an HTTP CONNECT request to the server to get the server to facilitate a tunnel between the client and the RPC endpoint). Here, using hyper-proxy is necessary.

I've already implemented (1), because it's low-hanging fruit and will be opening a PR for it shortly. Implementing (2) is a little more complicated because hyper-proxy hasn't yet upgraded to Tokio 1.0, but I'm happy to implement it if you need it.

[tony-iqlusion]

We're using an HTTP CONNECT proxy in a standard forward/egress proxy configuration.

It also looks like hyper-proxy just got upgraded to use Tokio 1.0.