I'm trying to configure an embedded Tomcat server so that it can serve HTTP2 in FIPs mode, using BouncyCastle's FIPs libraries. I've set the accepted protocols to TLSv1.2+TLSv1.3. I've tried various suggested cipher suites, but it seems no matter what I set as the cipher suite, Chrome/FF rejects connections on the grounds of "Inadequate Security". If I disable HTTP2, it does not matter what I set as the cipher suite - it just works.
I'm a bit confused.
When BC is in FIPS mode, it requires PKIX as algorithm for the KeyManagerFactory and TrustManagerFactory:
Security.setProperty("ssl.KeyManagerFactory.algorithm", "PKIX");
Security.setProperty("ssl.TrustManagerFactory.algorithm", "PKIX");
Without these two lines the server will be unable to retrieve the keys required by the cipher suite.
Related
Hello I recently set up SSL on my server, and the clients that connect to it need to know what cipher suit to use. I use Let's Encrypt certbot on an Ubuntu 20 server and NGINX webserver.
I was following this tutorial from start to finish: MQTT Broker Setup but it doesn't really get into that level of detail. However, my client devices lists:
Is there a default cipher suit that I can expect or a way to look through the lets encrypt files on the server to see what it is using? In general who determines the cipher suit to be used?
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'm running a web application that communicates with various APIs. One API requires TLSv1.2 while another will not support something that current (TLSv1 or TLSv1.1).
Does Websphere support multiple SSL versions?
I've found documentation about successfully changing the version of SSL, however I really need to be able to run TLSv1.1 and 1.2 together (if that's even possible) or run one version for one application while another for another application.
According to documentation for setting up SSL in WebSphere, to support the use of TLS 1.0, 1.1 and 1.2, I need to enable SSL_TLSv2:
Question: WAS is act SSL client, What does remote SSL server support
only TLSv1.0 or TLSv1.1 and Similar WAS is act SSL Server, What does
Remote SSL client does support only TLSv1.0 or TLSv1.1 or TLSv1.2.
What to do in order to work such environments?
Answer: There is an alternative option, SSL_TLSv2, which will enable
support for TLSv1.0, TLSv1.1, and TLSv1.2 in the environment. Please
use this setting SSL_TLSv2 in environments where support for multiple
TLS protocols is required, or if you are not sure whether your WAS
environment interacts with other servers or clients using non-TLSv1.2
protocols then, you can configure WAS to use SSL_TLSv2 using same
steps as given in the above.
Note:
Without poddle fix and configured WAS to use SSL_TLSv2
SSL_TLSv2 ==> Enables all SSL v3.0 and TLS v1.0, v1.1 and v1.2
protocols. Accepts SSLv3 or TLSv1 hello encapsulated in an SSLv2
format hello.
If you installed Poddle fix (will disable SSLv3 ) and configured WAS
to use SSL_TLSv2
SSL_TLSv2 ==> Enables these three TLS v1.0, v1.1 and v1.2 protocols.
So, changing the QoS settings to SSL_TLSv2 allows SSL Handshakes to multiple TLS versions when required.
A client installed on jBOSS is trying to access a secured website configured on DataPower xi50v6.0.0.2 appliance. The connection is getting failed at SSL handshake.
I have taken a packet capture at DataPower and observed that SSL Handshake is failing with the Description:Handshake failure(40).
However, at the Client Hello step, I have observed that, only one Cipher Suite is specified which is : TLS_EMPTY_RENEGOTIATION_INFO_SCSV.
The TLS protocol used ( as per packet capture) is TLS1.1. Can this Cipher Suite be a problem?
In the DataPower system logs I can see below error:
Request processing failed: Connection terminated before request headers read because of the connection error occurs
Update:
The client application is running on jBOSS7.I have asked our jBOSS administrator to check the configuration at jBOSS end. I somehow got the access to server where jBOSS instance is installed and checked domain.xml where the ssl is configured. Where exactly in domain.xml, ths configuration related to cipher suites can be found?
I have observed that, only one Cipher Suite is specified which is : TLS_EMPTY_RENEGOTIATION_INFO_SCSV
This is no real cipher. If no other ciphers are specified then the client does not offer any ciphers at all which means that no shared ciphers can be found and thus the handshake will fail. It looks like the client is buggy. Reason might be a failed attempt to fight POODLE attack by disabling all SSL3.0 ciphers, which in effect disables all ciphers for TLS1 1.0 and TLS 1.1.
I am trying to set the allowed ssl cipher suites for the embedded jetty server in my application. If I only use IncludeCipherSuites setting for SslContextFactory in the xml file setting for some reason when I run sslscan it only lists the ciphers for TLSv1.2 and not TLSv1.1 or TLSv1.0. I need to be able to have jetty use all three TLS versions. Is there anyway I can set the IncludeCipherSuites for Jetty so that I can set the list correctly.
Jetty 9.3.8 disables the SLOTH vulnerable ciphers that prevent proper encryption with the latest versions of Chrome (if you re-enable the SLOTH vulnerable ciphers you'll see a broken padlock icon in Chrome).
You'll want to setup a ${jetty.base}/etc/tweak-ssl.xml and appropriate entry in your ${jetty.base}/start.ini
Note: you should be using a split ${jetty.home} and ${jetty.base} directory structure and not modifying the ${jetty.home} contents
Documented here: https://www.eclipse.org/jetty/documentation/current/configuring-ssl.html#configuring-sslcontextfactory-cipherSuites
As for what configuration to use, that's up to you decide.
Know that excludes win over includes. If the cipher suite is excluded, no addition of it in the includes list will enable it.
Also be aware, that the JVM itself is also disabling various old protocols and cipher suites, following the same guidelines and updated specs that Jetty is with regards to security. In the near future you'll have to also re-enable those ciphers and protocols at the JVM level.