No verification of server certificates

[ericwb]

Pyvmomi uses httplib and urllib which do no do any certificate verification. But most products do prefer to have some control of how host certificates are verified in order to avoid man-in-the-middle attacks.

Probably the easiest way to get this supported properly is to switch from httplib to python requests - http://docs.python-requests.org/en/latest/

[joshk0]

I would love that. I'm actually working really closely with Requests in my current position, so I'll see what I can do.

[pcn]

👍 requests is vastly more useable, and by useable I mean it's harder to make mistakes and easier to get up and running.

[hartsock]

How is this going? I'm willing to slate it for the next release if it's close.

[hartsock]

I noticed this code looks like an attempt to add cert verification but it was commented out for some reason.

[hartsock]

I'm moving this to the next release. We'll accomplish this by moving the library completely onto requests ... I'll want a longer review cycle to evaluate that kind of change.

[jantman]

Just as a comment, if certificate verification is added, please make sure there's an option to disable it.

[mpontillo]

Actually, I would argue that (in order to maintain compatibility with previous versions) verification should be disabled by default. (not because I think not verifying certificates is a good idea in general, but because it would break API compatibility with previous revisions... and I expect that many people would not bother to configure trusted certificates for this purpose, since pyvmomi will usually be run on what amounts to a relatively trusted network.)

[hartsock]

I'll try and do a pull request for this shortly. My instinct is to add option flags to go with default = disabled through out the API. But, do something clever so that when in a "production" class environment we trip something and fall into enabled. Maybe a magic local environment variable for development?

We can discuss it in the pull request.

[pcn]

I really think that a default option is the right way to go - eliminating surprise. Sites/individuals can wrap that and make their own determination as to whether they want a prod/dev split in how certs are treated. In most ops situations your sysadmins will be much happier if dev/stage/qa/test/ci/production all have the same behavior and the same flags enabled.

[hartsock]

@pcn okay, we'll go with easy first.

[hartsock]

Note: see #252 and #212 which are related to this issue.

[tianhao64]

The httplib has already been replaced by request. Thx @michaelrice .Since change 92c1de5, ssoContext can be passed to Connect and SmartConnect to disable the certificate verification.