Sounds like a good idea. On 1/2/14 9:51 AM, "Demetrius Tsitrelis" <demetrius.tsitre...@citrix.com> wrote:
>It might also be good to be able to globally specify other >characteristics of the SSL/TLS configuration - for example, the list of >supported ciphers. > >-----Original Message----- >From: Demetrius Tsitrelis [mailto:demetrius.tsitre...@citrix.com] >Sent: Tuesday, December 24, 2013 10:11 AM >To: dev@cloudstack.apache.org >Subject: RE: TLSv1 vs TLS vs SSL use throughout CS > >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/XenServerCo >>n >>nectionPool.java:90: javax.net.ssl.SSLContext sc = >>javax.net.ssl.SSLContext.getInstance("TLS"); >> >>plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/NiciraNv >>p >>Api.java:555: SSLContext sc = >>SSLContext.getInstance("SSL"); >> >>plugins/network-elements/palo-alto/src/com/cloud/network/utils/HttpClient >>W >>rapper.java:42: SSLContext ctx = >>SSLContext.getInstance("TLS"); >> >>plugins/storage/volume/solidfire/src/org/apache/cloudstack/storage/datast >>o >>re/util/SolidFireUtil.java:703: SSLContext sslContext = >>SSLContext.getInstance("SSL"); >> >> >>services/console-proxy/server/src/com/cloud/consoleproxy/ConsoleProxySecu >>r >>eServerFactoryImpl.java:71: sslContext = >>SSLContext.getInstance("TLS"); >> >>services/console-proxy/server/src/com/cloud/consoleproxy/ConsoleProxySecu >>r >>eServerFactoryImpl.java:94: sslContext = >>SSLContext.getInstance("TLS"); >> >>services/console-proxy/server/src/com/cloud/consoleproxy/util/RawHTTP.jav >>a >>:236: sslContext = >>SSLContext.getInstance("SSL", "SunJSSE"); >> >>services/console-proxy-rdp/rdpconsole/src/main/java/streamer/SocketWrappe >>r >>.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/EasySSLProtocolSocket >>F >>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"); >> >> >
