Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[BUG] Govc client cannot validate server based on thumbprint when proxy is configured #2494

Open
hanlins opened this issue Jun 15, 2021 · 7 comments
Open

[BUG] Govc client cannot validate server based on thumbprint when proxy is configured #2494

hanlins opened this issue Jun 15, 2021 · 7 comments
Labels
lifecycle/frozen

Comments

@hanlins
Copy link

hanlins commented Jun 15, 2021

Describe the bug
When proxy environment variables (e.g. HTTP_PROXY, HTTPS_PROXY) are set, govc client will bypass the thumbprint validation.

To Reproduce
Steps to reproduce the behavior:

  1. Configures the thumbprint file, the connection works.
  2. Then configures the proxy environment variables, the thumbprint validation is bypassed by golang's cert validation.

Expected behavior
When proxy environment variables are being configured, the thumbprint validation in govc client is bypassed. If user are using username/password together with thumbprint to validate the vCenter server, then there's no certificated being distributed to the server thus client won't find and SAN matching vCenter server as there's no CA cert at all and the request will fail.

Affected version
Please provide details on the version used, e.g. release tag, commit, module version, etc.

Screenshots/Debug Output

  1. Here's the environment variables in the testing environment:
export GOVC_URL="https://10.193.1.165"
export GOVC_HOST="https://10.193.1.165"
export GOVC_USERNAME="administrator@vsphere.local"
export GOVC_PASSWORD="Admin!23"
#export GOVC_INSECURE=true
export GOVC_DATASTORE="local-0"
export GOVC_TLS_KNOWN_HOSTS="known_host"

The content of known_hosts file is:

10.193.1.165 20:F3:D4:62:1F:3E:C0:13:B9:F4:90:AD:57:F6:D7:BD:34:F8:C8:1C

Communication with vCenter works:

➜  govc datastore.ls
vCLS (2)
worker-1
  1. Configure proxy variables in the testing environments:
➜  ~ export http_proxy="http://10.182.54.95:80"
➜  ~ export https_proxy="http://10.182.54.95:80"
➜  ~ curl -k -v google.com
* Uses proxy env variable http_proxy == 'http://10.182.54.95:80'
*   Trying 10.182.54.95...
* TCP_NODELAY set
* Connected to 10.182.54.95 (10.182.54.95) port 80 (#0)
> GET http://google.com/ HTTP/1.1
> Host: google.com
> User-Agent: curl/7.64.1
> Accept: */*
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 301 Moved Permanently
< Location: http://www.google.com/
< Content-Type: text/html; charset=UTF-8
< Date: Tue, 15 Jun 2021 22:41:39 GMT
< Expires: Thu, 15 Jul 2021 22:41:39 GMT
< Cache-Control: public, max-age=2592000
< Server: gws
< Content-Length: 219
< X-XSS-Protection: 0
< X-Frame-Options: SAMEORIGIN
< X-Cache: MISS from kube-worker.c55f0f26
< X-Cache-Lookup: MISS from kube-worker.c55f0f26:80
< Via: 1.1 kube-worker.c55f0f26 (squid/3.5.27)
< Connection: keep-alive
<
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com/">here</A>.
</BODY></HTML>
* Connection #0 to host 10.182.54.95 left intact
* Closing connection 0

You can see that the request is forwarded successfully by the proxy.
3. Try previous govc command again with proxy configs and failed:

➜  govc datastore.ls
govc: Post "https://10.193.1.165/sdk": x509: cannot validate certificate for 10.193.1.165 because it doesn't contain any IP SANs

Additional context
Need to prevent golang from overwriting the transport functionality that skips the thumbprint validation.
@github-actions
Copy link
Contributor

Howdy 🖐   hanlins ! Thank you for your interest in this project. We value your feedback and will respond soon.

If you want to contribute to this project, please make yourself familiar with the CONTRIBUTION guidelines.

@hanlins
Copy link
Author

hanlins commented Jun 21, 2021

Seems this is a known issue:

govmomi/session/manager.go

Lines 122 to 125 in 18b53fd

// When http.Transport.Proxy is used, our thumbprint checker is bypassed, resulting in:
// "Post https://sdkTunnel:8089/sdk: x509: certificate is valid for $vcenter_hostname, not sdkTunnel"
// The only easy way around this is to disable verification for the call to LoginExtensionByCertificate().
// TODO: find a way to avoid disabling InsecureSkipVerify.

Are we expecting a fix for this issue? @dougm

@dougm
Copy link
Member

dougm commented Jun 22, 2021

We use a custom http.Transport.DialTLS function to implement the thumbprint check, but that does not apply to proxy connections. Looks like we'd have to implement our own proxy client that does the http CONNECT and TLS session negotiation. Not sure what the correct and simple path for doing this is yet. I've have seen several references to golang.org/x/net/proxy for implementing custom proxy clients, but it isn't clear if we'd need that in this case.

hanlins added a commit to vmware-tanzu/tanzu-framework that referenced this issue Jul 23, 2021
@hanlins
Add logic to validate the known proxy issue in vsphere provider
df627fe 
There's a known issue that if govc client is using http proxy, then its
connection need to be insecure.
Here's the known issue: vmware/govmomi#2494

Signed-off-by: Hanlin Shi <shihanlin9@gmail.com>
@hanlins hanlins mentioned this issue Jul 23, 2021
Closed
5 tasks
@gwang550 gwang550 mentioned this issue Sep 8, 2021
Merged
5 tasks
@github-actions
Copy link
Contributor

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Mark as fresh by adding the comment /remove-lifecycle stale.

@mcwumbly
Copy link

/remove-lifecycle stale

@github-actions
Copy link
Contributor

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Mark as fresh by adding the comment /remove-lifecycle stale.

@lubronzhan
Copy link
Contributor

/remove-lifecycle stale

@lubronzhan lubronzhan mentioned this issue Jul 10, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
lifecycle/frozen
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@dougm @mcwumbly @lubronzhan @hanlins