Plaintext TCP connection to proxy when http_proxy points to HTTPS URL

[uchi-mata]

What version of gRPC are you using?

Most recent, I tested with https://github.com/grpc/grpc-go/tree/master/examples/helloworld/greeter_client

What version of Go are you using (go version)?

go version go1.14.2 darwin/amd64

What operating system (Linux, Windows, …) and version?

macOS 10.14.6

What did you do?

I used the sample greeter_client:

1. Adjust host greeter_client connects to (i.e. not localhost)
2. Build greeter_client
3. Run greeter client: http_proxy="https://myproxy:443" ./greeter_client

What did you expect to see?

I expected a TLS connection to myproxy:443 over which a HTTP CONNECT request is performed.

What did you see instead?

I saw a plain-text non-TLS connection to myproxy:443 over which the HTTP CONNECT request took place.

[menghanl]

Proxy doesn't control transport credentials. To use TLS, please see https://github.com/grpc/grpc-go/tree/master/examples/features/encryption#tls

[uchi-mata]

Hi @menghanl,

I'm not sure we talked about the same thing. E.g. if I use the same setup with curl, curl uses an HTTPS connection to the proxy server - and I believe this is also the common conception of the proxy environment variables even though there is no formal standard. Let me know if I may provide more detail or attempt a PR if someone deems this to be relevant.

Best,
Matthias

[menghanl]

Oh, I see.
gRPC's proxy dialer doesn't recognize "https" in the address. And there's no easy way to add another TLS handshake.
There can potentially be two TLS handshakes, one for the proxy, one for the application.

Why do you want to the proxy connection also to be TLS, instead of between client and the backend?

[uchi-mata]

Hi menghanl,

there's three reasons I opened the bug:

1. The expected behavior based on practice by other tools would be that the connection happenes via TLS. Troubleshooting this (connecting via HTTP to a HTTPS-only proxy resulting in an error) might be effort for various users.
2. Some users might be located behind an enterprise HTTPS-only proxy (which I've seen before), they could not connect through the proxy then without additional steps like a local stunnel-to-proxy.
3. Doing the connect request via HTTP instead of HTTPS transfers the target destination unencrypted. In some - admittedly quite niche - cases, this can already be a security concern.

However, I fully understand that this might be quite some effort and low priority! I still thought it might be a valid thing to make the team aware of :) I'd also be happy to extend the documentation on that so that users at least can read up on the behavior and work around it.

Thanks,
Matthias

[menghanl]

The current proxy solution has some other problems, for example #3401. We have plans to update the proxy APIs (an separate proxy plugin instead of using dialer). We can see if this problem can be better solved in the new API.

[uchi-mata]

Awesome, thank you!