WIP: SNI-aware proxy with tokio

[selfhoster1312]

This is really bad code and does everything very wrong, sorry about that, it's just a proof-of-concept. I just submitted this because it took me a while to figure it out already, and people seemed interested in #58 (5 upvotes at the time of writing).

Supports:

• tokio runtime
• monoio runtime
• TCP connections
• QUIC connections

It's very quick & dirty, as it will peek in the stream to find the TLS handshake (i couldn't find a peek equivalent in monoio, so only tokio is supported for now), which will be parsed a second time if the connection is not reverse proxied without TLS termination.

Also, i mostly have no idea what i'm doing with that backend TcpStream reading/writing, i just hacked this around, but i'm guessing it's possible to pipe actual tcp_stream into dest_stream without dark magic (i just don't know how).

Testing

It's using the proxy_tls directive in vhosts. For example:

google.com:4443 {
  proxy_tls "142.250.178.131:443"
}

Now you can curl it:

curl -v -4 --connect-to 'google.com:443:127.0.0.1:4443' https://google.com

Additional notes

• it's very cumbersome to get SNI from rustls without consuming the connection (hence the peeked buffer hack), there's plenty of issues about it upstream, and i don't understand why the maintainers don't want to make it easier (i had to fork rustls to make more types public, but there may be a simpler way)

[selfhoster1312]

Hello @DorianNiemiecSVRJS, i'm still interested in this feature even though this PR is indeed stale! I can rebase on 3.x given some guidance on the new codebase. From what i can read there's now a hinted_hostname that's extracted from SNI on TCP/quic connections. Does that mean that 3.x already implements SNI-aware reverse-proxying? Or should i still update this PR to add the actual setting?

[DorianNiemiecSVRJS]

Hello @DorianNiemiecSVRJS, i'm still interested in this feature even though this PR is indeed stale! I can rebase on 3.x given some guidance on the new codebase. From what i can read there's now a hinted_hostname that's extracted from SNI on TCP/quic connections. Does that mean that 3.x already implements SNI-aware reverse-proxying? Or should i still update this PR to add the actual setting?

Your PR would implement SNI-aware L4 proxying (if I read it correctly), but Ferron 3's reverse proxy implements L7 proxying, which would require a TLS certificate for the proxy.

Yes, you can optionally close this PR and create a new one against the develop-3.x branch. And yes, hinted_hostname in http-server is derived from SNI hostname.

By the way, Ferron 3 uses zincio async runtime, which has zincio::TcpStream::peek(), unlike monoio.