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.
...
Related
Since TLS1.3 support in OpenSSL 1.1.1 which was released on September 11th 2018, I wonder if I can get my Apache2 server to support it so my visitors can benefit from improved security and speed.
I understand that there are several ways to make this happen:
A backport of Apache which has it, but isn't it potentially insecure to run this kind of unoffical frankenware? I also cannot seem to find it.
Wait until an Apache2 version comes out that supports it and then compile it from source and install it. Unfortunately I cannot find information on when this comes out or if it already exists, and which version I should be downloading.
Adjust Apache2's config to use other openssl libraries (separately installed and compiled from source). Here, again, I cannot seem to find instructions on how to get this done.
I anticipate this question coming up pretty often in the near future so I hope to solicit an exhaustive answer for everyone who intends to support TLS1.3.
PS I'm also not sure if Apache2 uses the installed OpenSSL library or if it has its own module compiled (much the way it does with PHP)?
Starting with Apache version 2.4.36 (current one right now is 2.4.37) support for TLS1.3 has been added. In combination with OpenSSL 1.1.1 you can enable support for it at any time after updating both. In your SSL.conf you should make a few minor adjustments.
SSLProtocol -all +TLSv1.2 +TLSv1.3
#You don't have to explicitly enable it, but this can be considered secure
SSLCipherSuite EECDH+AES256-GCM:EDH+AES256-GCM:AES256+EECDH:AES256+EDH:!AES128
#these secure suites are used up to TLS1.2
SSLCipherSuite TLSv1.3 TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384
#these suites are used for TLS1.3 only
If you don't want to specify the suites for TLS1.3 the default 3 ones
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
are used (in that order). I changed that for my config since I wanted to get rid of all AES128 suites.
If you are ok with the default setting, then basically upgrading Apache and OpenSSL is enough to get you started. Qualys SSL Test should confirm whether TLS1.3 is enabled etc.
I have some vulnerabilities with ciphers. Anonymous chipers, ssl rc4 cipher suites supported, ssl medium strength cipher.
And i am trying to fix it with
openssl ciphers -v ‘!aNULL:!eNULL’
openssl ciphers -v ‘ALL:!LOW’
and others commands but when I reload the nessusd scan, I still have the vulnerabilities.
Someone can help me please.
Adding to #vcsjones answer, you do not want to rebuild OpenSSL. You do not want to become dependent upon keeping an up-to-date, custom OpenSSL build.
You simply need to configure your Apache install to use the proper ciphers.
And the easiest way to do that is to use the Mozilla SSL Configuration Generator to generate the proper options for the versions of web server and SSL provider you're using.
You can only remove ciphers from OpenSSL by recompiling it without the ciphers you want. The command you entered above just simply lists ciphers that meet the criteria you entered.
The correct solution however is to configure the software that is using OpenSSL to not use those ciphers from OpenSSL. For example, with nginx you might do something like this:
ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
It depends on the software you are trying to configure. There is ample documentation on Stack Overflow, Server Fault, etc. on how to configure nginx, Apache, etc.
I'm using WHM I had installed ssl certificate on my website it's working good but issue is that this tool https://www.ssllabs.com/ssltest/index.html saying > This server accepts the RC4 cipher, which is weak, I'm using apache server WHM with cPanel, Please help me in details, Thank you so much.
You will need to stop supporting RC4 ciphers to stop this warning from appearing. https://mozilla.github.io/server-side-tls/ssl-config-generator/ has a nice interface where you can plug in your Apache version, choose how flexible you want to be in terms of supporting older client (Modern vs. Intermediate vs. Old), which comes with a security tradeoff, and make the recommended changed to your Apache config file.
The relevant lines are:
SSLProtocol xxx
SSLCipherSuite xxx
SSLHonorCipherOrder on
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?
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.