TLSv1.0 vsphere web client plugin

[dkfje]

During the installation of new plugins, vSphere web client server would do an HTTPS get on the URL that was registered in the vCenter server.  The connection that it makes is TLSv1.0.   If the URL that is specified doesn't support TLSv1.0 anymore due to the POODLE attack.  Is there an update to vSphere web client server to address this issue?  I see that it works if you upgrade the JDK that vSphere web client uses to JDK 1.8.

[laurentsd]

What version are you using?

The current 6.0 version has this in server/configuration/tomcat-server.xml and AFAIK there is no security issue.

sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2"

[dkfje]

vSphere web client 5.5 and vSphere 6.0.  Is that settings for the client to use or is that for the server to allow a particular protocol to connect to?

[dkfje]

vSphere web client 6.0 has those settings but it doesn't seem to help.  Here is the log:

[2016-01-12T14:58:16.806-08:00] [ERROR] vc-extensionmanager-pool-185 70000165 100006 200002 com.vmware.vise.vim.extension.VcExtensionManager                  Package com.acme.plugin.vsphere was not installed!

Error downloading https://10.124.224.57/download/acme-plugin.zip?version=1.0.1. Make sure that the URL is reachable then logout/login to force another download. java.net.SocketException: Connection reset

at java.net.SocketInputStream.read(Unknown Source)

at java.net.SocketInputStream.read(Unknown Source)

at sun.security.ssl.InputRecord.readFully(Unknown Source)

at sun.security.ssl.InputRecord.read(Unknown Source)

at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)

at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)

at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)

at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)

at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)

at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source)

at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)

at java.net.HttpURLConnection.getResponseCode(Unknown Source)

at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(Unknown Source)

at com.vmware.vise.util.http.ConnectionManager.connect(ConnectionManager.java:186)

at com.vmware.vise.util.http.SimpleHttpClient.connect(SimpleHttpClient.java:218)

at com.vmware.vise.util.http.SimpleHttpClient.executeMethodResponseAsStream(SimpleHttpClient.java:109)

at com.vmware.vise.vim.extension.VcExtensionManager.writePackageToFile(VcExtensionManager.java:864)

at com.vmware.vise.vim.extension.VcExtensionManager.downloadPackage(VcExtensionManager.java:811)

at com.vmware.vise.vim.extension.VcExtensionManager$1.call(VcExtensionManager.java:633)

at com.vmware.vise.vim.extension.VcExtensionManager$1.call(VcExtensionManager.java:625)

at java.util.concurrent.FutureTask.run(Unknown Source)

at com.vmware.vise.util.concurrent.QueuingCachedThreadPool$QueueProcessor.run(QueuingCachedThreadPool.java:866)

at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)

at java.util.concurrent.FutureTask.run(Unknown Source)

at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

at java.lang.Thread.run(Unknown Source)

[Peter_Ivanov]

This is configuring the incoming connections to the tomcat server.

This will not change the way HTTPS connection is opened to download the plugins. It is using SSLContext.getInstance when creating the https client.

You can configure the SSLContext to use TLS using Java parameter -Dhttps.protocols.

However you cannot ask your plugin users to do this with their Web Client setup.

In the upcoming update 2 release there are fixes related to TLS. IFAIK U2 should use TLS by default when establishing HTTPS connections to different services (including downloading plugins). But you will have to wait a little more

Also we plan to switch to Java 8 soon, but I cannot commit to a release.