Open djs55 opened 6 years ago
Any possibility of movement on this @djs55 ? This is still an incredibly pain point for development with split network access requirements
There is another issue related to the transparent proxy that is affecting TLS HTTP requests but not PLAIN HTTP requests. Whenever the upstream proxy is applying whitelist based on domains the HTTPS requests will fail with a similar error as reported in https://github.com/docker/for-mac/issues/2681
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* error:1408F10B:SSL routines:ssl3_get_record:wrong version number
* Closing connection 0
curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number
This is because the HTTP CONNECT method is done by vpnkit using the IP address instead of the domain name. Thus the upstream proxy if applying a whitelist rule based on the domain found in CONNECT request, will answer an error to the CONNECT request for which no whitelist rule applies.
> CONNECT google.ch:443 HTTP/1.1
vs
> CONNECT 172.217.168.14:443 HTTP/1.1
That is very similar of trying to do the following request via a proxy:
export https_proxy=proxy.example.com:8080
curl https://172.217.168.14
This kind of requests will never pass a proxy applying whitelist rules based on domains.
@djs55 The recent Docker Desktop 4.17.0 release notes indicates that:
Fixed a bug in the transparent TLS proxy where the Server Name Indication field is not set.
https://docs.docker.com/desktop/release-notes/#4170
I couldn't find after a search in vpnkit history the changes for this fix, do you know were it was done?
It might be possible to use TLS SNI to discover the hostname and then to apply domain-based
no_proxy
rules. Currently only IP address-based rules will work for encrypted connections.See [docker/for-mac#2681]