I'd like to restrict SSL protocols to TLS 1.2 on Vert.x 2.1.5 as http server and client. I'm using jdk 7. Does anyone have experience on how to do it?
Oracle says here that SSL protocols should be restricted on JRE 7 by explicitly setting enabled protocols on the SSL Engine:
sslEngine.setEnabledProtocols(new String[] {"SSLv2Hello", "TLSv1", "TLSv1.1", "TLSv1.2"});
Now check out TCPSSLHelper.java class in Vert.x v2.1.5. There is a constant containing the list of enabled protocols, and it's used to set enabled protocols on the SSL Engine:
// Make sure SSLv3 is NOT enabled due to POODLE issue
private static final String[] ENABLED_PROTOCOLS =
{"SSLv2Hello", "TLSv1", "TLSv1.1", "TLSv1.2"};
Change that value to {"TLSv1.2"}; to limit support to TLSv1.2.
For a quick test:
Create the org.vertx.java.core.net.impl package in your own project
Copy TCPSSLHelper to your package and edit the enabled protocols constant
Build and run.
CURL using the specific protocol directives, and see that server will only connect with TLSv1.2.
Your source will typically come before third party source on the classpath, so this change will override the class in the Vert.x lib and is all you need to restrict to TLSv1.2.
Ideally this would be submitted back to Vert.x as a patch, where the protocols are read on command line as properties.
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.
...
We use UnboundID (unfortunately the old version that should be upgraded soon).
I want to configure multiple TLS protocols for LDAP over SSL connection: TLSv1, TLSv1.1, TLSv1.2.
Unfortunately, com.unboundid.util.ssl.SSLUtil#createSSLContext(java.lang.String, java.lang.String) supports only a single value:
public SSLSocketFactory createSSLSocketFactory(final String protocol)
throws GeneralSecurityException
{
return createSSLContext(protocol).getSocketFactory();
}
How to configure multiple TLS protocols?
If you put "TLSV1.2" it will use any protocol version from there back as far as the JDK supports. What you are doing is configuring the highest TLS protocol version to use.
Specific settings for unboundid-ldap-sdk are controlled by:
com.unboundid.util.SSLUtil.setDefaultSSLProtocol("TLSv1");
com.unboundid.util.SSLUtil.setEnabledSSLProtocols(Arrays.asList("TLSv1"));
As shown in Documentation.
Adobe documentation for AEM 6 says
"Check the Use SSL or Use TLS checkboxes when configuring the LDAP
Identity Provider."
What protocol will be used if I check both boxes? Does TLS override the SSL config option? It seems to work with one or both checked, but I can't verify which protocol was used. Is checking just TLS sufficient to ensure I have a connection using the TLS protocol?
There are 2 ways to secure LDAP connections :
One is to connect to the LDAPS port (636 by default) using SSL (or
the later TLS versions). This is the legacy and non-standard way to
do it, also generally known as "Use SSL".
One is to connect to the LDAP port (389), and then enable TLS using
the LDAP StartTLS extended operation (which negotiates SSLv3 or TLS
protocols). It is generally known as "Use TLS".
The underlying version of the protocol used (SSLv3, TLSv1.0, TLSv1.1...) depends on the settings of the LDAP server or the LDAP client library.
I hope this helps.
Is it possible to globally disable TLS 1.1 for an application that is indirectly using OpenSSL?
I would like to disable TLS 1.1 for a C application that makes soap HTTPS calls using gSOAP.
Disabling TLS 1.1 fixes a intermittent SSL connection problem I have been experiencing for the last few days (SSL routines:SSL3_GET_RECORD:wrong version number).
Currently TLS 1.1 is disabled by using a custom build of gSOAP but ideally I would like to disable the protocol using a config file or some code in my application.
Ubuntu 12.04.5 LTS
OpenSSL 1.0.1-4ubuntu5.20
gSOAP 2.8.4-2
Although there is a global OpenSSL config file it can not be used to restrict the default SSL version(s). And unfortunately there seems to be no API or configuration for the gSOAP library to restrict the SSL version. So you must probably live with your custom build version and hope that someday they provide an API to set the SSL version.
At a minimum you will need gSOAP 2.8.28. Use the SOAP_TLSv1_2 option with soap_ssl_client_context() and soap_ssl_server_context() to restrict the TLS protocol to TLSv1.2 only. TLS1.0/TLS1.1/SSLv3 are disabled. You can't combine the SSL/TLS protocol options, so only TLSv1.2 will be enabled with this option. This works with OpenSSL 1.0.1 or later and recent GNUTLS versions. Perhaps there will be new options in upcoming gSOAP releases to support subsets of protocols, which would be nice.
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.