If all of the servers and clients support the latest TLS version (1.2) then that is the preferred option.
If not, perhaps we could configure fallback behavior with a list of acceptable SSL/TLS versions? So, if the admin lists TLS 1.2 and TLS 1.1 as acceptable then 1.2 would be tried first and then 1.1; if the last one failed then the connection would fail. How about that? The SSLContext.getInstance() method also takes a parameter for the security provider and in one case below someone has named a specific one - SunJSSE. It might be good to allow an admin to configure the provider as well so that providers with other characteristics (FIPS, etc.) could be easily chosen. -----Original Message----- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Monday, December 23, 2013 3:00 PM To: dev@cloudstack.apache.org Subject: Re: TLSv1 vs TLS vs SSL use throughout CS Why not set it to the highest secure protocol level always? On 12/20/13 12:56 PM, "Demetrius Tsitrelis" <dtsitre...@live.com> wrote: > > >I was looking at the SSL code in CloudStack and noticed that there are >about a dozen calls to the >SSLContext.getInstance() method. Some of them use the "SSL" protocol >while >others use "TLS" or "TLSv1". So I'm wondering if it makes sense to >expose a configuration setting which specifies an organization's >minimum secure protocol level and then use that in all of CloudStack. >Is there a need to maintain distinct protocol configurations for each >SSL/TLS connection? Here's the usage list today: > > >plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServerCon >nectionPool.java:90: javax.net.ssl.SSLContext sc = >javax.net.ssl.SSLContext.getInstance("TLS"); > >plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/NiciraNvp >Api.java:555: SSLContext sc = >SSLContext.getInstance("SSL"); > >plugins/network-elements/palo-alto/src/com/cloud/network/utils/HttpClientW >rapper.java:42: SSLContext ctx = >SSLContext.getInstance("TLS"); > >plugins/storage/volume/solidfire/src/org/apache/cloudstack/storage/datasto >re/util/SolidFireUtil.java:703: SSLContext sslContext = >SSLContext.getInstance("SSL"); > > >services/console-proxy/server/src/com/cloud/consoleproxy/ConsoleProxySecur >eServerFactoryImpl.java:71: sslContext = >SSLContext.getInstance("TLS"); > >services/console-proxy/server/src/com/cloud/consoleproxy/ConsoleProxySecur >eServerFactoryImpl.java:94: sslContext = >SSLContext.getInstance("TLS"); > >services/console-proxy/server/src/com/cloud/consoleproxy/util/RawHTTP.java >:236: sslContext = >SSLContext.getInstance("SSL", "SunJSSE"); > >services/console-proxy-rdp/rdpconsole/src/main/java/streamer/SocketWrapper >.java:130: SSLContext sslContext = >SSLContext.getInstance("TLSv1"); > > utils/src/com/cloud/utils/nio/Link.java:430: sslContext = >SSLContext.getInstance("TLS"); > >utils/src/org/apache/commons/httpclient/contrib/ssl/EasySSLProtocolSocketF >actory.java:114: SSLContext context = >SSLContext.getInstance("SSL"); > > vmware-base/src/com/cloud/hypervisor/vmware/util/VmwareClient.java:102: > javax.net.ssl.SSLContext sc = >javax.net.ssl.SSLContext.getInstance("SSL"); > >vmware-base/src/com/cloud/hypervisor/vmware/util/VmwareContext.java:80: > javax.net.ssl.SSLContext sc = >javax.net.ssl.SSLContext.getInstance("SSL"); > >
