I have a question regarding the configuration of SSL preferences on OpenShift.
As far I know, the SSL termination in OpenShift is executed on the HAproxy, which serves as reverse proxy to route to user gears.
Is there a possibility, to configure the SSL preferences, to use user specific order of prefered ciphers, and also to turn off some versions of SSL/TLS as it is possible for instance in tomcat, or is the SSL cipher and versions configuration platform specific and can't be changed by user?
Related
We are getting weak cipher vulnerability during system scan and to resolve this I have negated them in string in openssl.conf, but still I am able to connect the local host using these ciphers, e.g. "RC4".
This vulnerability is reported on post 3128 and 8443 in the webserver.
ssl.conf output:
#SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!RC4:!DES:!3DES
I'm still able to connect using the RC4 cipher to the local host.
[XXXXXXXXXX ~]$ openssl s_client -cipher 'RC4' -connect 127.0.0.1:3128
CONNECTED(00000003)
Is it the correct way to test, or I am doing something wrong?
Will this change in openssl.conf remove this weak cipher issue during the next scan?
Per the Apache SSLCipherSuite documentation (bolding mine):
This complex directive uses a colon-separated cipher-spec string
consisting of OpenSSL cipher specifications to configure the Cipher
Suite the client is permitted to negotiate in the SSL handshake phase.
Notice that this directive can be used both in per-server and per-directory context. ...
Without your entire ssl.conf file posted, it's impossible to know what's going on.
But I'd think the answer to your problem in any case is the easiest way to reliably configure SSL on a web server: get your ssl.conf values directly from the Mozilla SSL Configuration Generator. It's simple, repeatable, and well-documented.
Put in your system's specific software versions and required level of security, and you'll get back a set of configuration settings to place in your configuration files.
The site and its usage is full documented at Mozilla's Security/Server Side TLS page:
The goal of this document is to help operational teams with the
configuration of TLS on servers. All Mozilla sites and deployment
should follow the recommendations below.
The Operations Security (OpSec) team maintains this document as a
reference guide to navigate the TLS landscape. It contains information
on TLS protocols, known issues and vulnerabilities, configuration
examples and testing tools. Changes are reviewed and merged by the
OpSec team, and broadcasted to the various Operational teams.
...
Recommended configurations
Three configurations are recommended. Pick the right configuration
depending on your audience. If you do not need backward compatibility,
and are building a service for modern clients only (post Firefox
27/Chrome 22), then use the Modern configuration. Otherwise, prefer
the Intermediate configuration. Use the Old backward compatible
configuration only if your service will be accessed by very old
clients, such as Windows XP IE6, or ancient libraries & bots.
...
I just received an email from Authorize.net informing that they deactivate connections to their server using TLS1.0 and TLS1.1.
Question are Godaddy SSL and Web Host set for TLS1.2 connections and is there anything need to change for configure TLS1.2 for my site?
How to check which TLS use in my website?
How to check which TLS use in my website?
Use Qualys SSL Labs vulnerability tester to check which TLS version you are using: https://www.ssllabs.com/ssltest/
You may certainly see that you support several versions (this is the most common case).
Question are Godaddy SSL and Web Host set for TLS1.2 connections and is there anything need to change for configure TLS1.2 for my site?
You have nothing to do, web hosting services by GoDaddy are already supporting TLS 1.2 connections (and TLS 1.0 and TLS 1.1 - they do not support SSL v3 nor SSL v2 anymore, and it's a good thing).
Looking to port Outbound SSL configuration from Websphere to JBoss. In my case, JBoss is the client. It wants to pass a client cert to a remote machine as part of a 2-way SSL communication.
In Websphere, you explicitly specify...
keystore / keystore password (where are the certs?)
certificate alias (which client cert to apply?)
matching outbound url pattern (when do i apply the client cert?)
You may have many of these configurations. Between these 3 pieces of info, the container can selectively choose when/which client certificate to include when making outbound SSL calls.
What is the JBoss way of doing the same thing as I described above ?
Can this be done by simply configuring your JRE ?
Are there parts of this that cannot be done in JBoss and/or java?
Thanks,
Wade.
I am planning to disable SSL protocol in my site and moving to the TLS secure protocol. I will be making the configuration change in httpd. Does it require any changes to the server and client certificates or credentials which are already in place?
No it doesn't. Only the supportedProtocols needs to change.
I'm using Spring Security for X.509 preauthentication.
To make sure the client sends its certificate per HTTP request, is it necessary to:
Modify pom.xml to set <wantClientAuth> and <needClientAuth> to true
Set Apache's SSLVerifyClient to require reference
Based on reading, the web server must tell the client-side to sends its certificate in order for the client to actually send it. I'm confused if Spring Security AND Apache configuration is required to achieve this.
Spring Security configuration has nothing to do with whether the client sends a certificate or not. That's decided at the SSL protocol level and hence by the negotiation between the client and the server. Your question is a bit unclear in that it refers to a maven pom and an Apache configuration without explaining how your system is set up. Are you running the maven Jetty plugin with an Apache server in front?
Spring Security's X.509 authentication won't work if the SSL connection doesn't terminate at the servlet container. So if you have HTTPS between the client and Apache, and a non-SSL connection from Apache to the servlet container, then the client certificate won't normally be available.
If you are using an AJP connector, then you can configure Apache to pass the certificate on to the back end using the ExportCertData option. If you aren't, you can still take the exported certificate and pass it as a request header (you'll find examples of this elsewhere on SO). You would also need to customize the Spring Security X.509 code to extract the certificate from the header, rather than the standard java property name which it uses by default.