I read on various forums regarding POODLE vulnerability in SSLv3. It is recommended to disable SSLv3 and support TLS_FALLBACK_SCSV on servers.
How to enable support of TLS_FALLBACK_SCSV on apache2.2?
Upgrade to the latest version of openssl, which automatically supports TLS-FALLBACK-SCSV. Apache will use that.
From https://www.openssl.org/news/secadv_20141015.txt :
OpenSSL 1.0.1 users should upgrade to 1.0.1j.
OpenSSL 1.0.0 users should upgrade to 1.0.0o.
OpenSSL 0.9.8 users should upgrade to 0.9.8zc.
Debian and other Distributions are deploying backports of the TLS-FALLBACK-SCSV update on OpenSSL.
Restart your Apache after the update.
Check your server
SSL Labs will check whether you support TLS_FALLBACK_SCSV.
Notice how https://www.ssllabs.com/ssltest/analyze.html?d=google.com&s=74.125.239.96&hideResults=on notes "TLS_FALLBACK_SCSV supported"
It shouldn't be necessary to do both; TLS_FALLBACK_SCSV is a mechanism to prevent downgrade attacks, but if your server does not allow SSLv3 (or v2) connections it is not needed (as those downgraded connections would not work)
Edit (to incorporate feedback):
Technically TLS_FALLBACK_SCSV is still useful with SSL disabled, because it helps avoid the connection being downgraded to TLS < 1.2. But this is unnecessary to defend against POODLE, since the vulnerable SSLv3 is off.
The only reason TLS_FALLBACK_SCSV is helpful against POODLE is if you need to support SSLv3 clients (really old IE versions or something). Those clients will still be vulnerable to the attack, but modern clients which support that option would be safe against the downgrade attack.
Upgrade to the latest OpenSSL package that implements TLS_FALLBACK_SCSV. Then in your Apache configuration disable SSLv3 as well.
SSLProtocol all -SSLv2 -SSLv3
This answer on the 'askubuntu' stack site goes into a lot more detail and has answers for how to configure a bunch of different servers for this.
https://askubuntu.com/questions/537196/how-do-i-patch-workaround-sslv3-poodle-vulnerability-cve-2014-3566
As far as I understand it, it's not a configuration in Apache but a behavior of openssl.
OpenSSL has added support for TLS_FALLBACK_SCSV to allow applications
to block the ability for a MITM attacker to force a protocol
downgrade.
https://www.openssl.org/news/secadv_20141015.txt
On Debian, you can upgrade openssl without upgrading libssl, you really want libssl to be upgraded. Apache uses libssl.
I can confirm is not need change nothing on Apache (at least for Ubuntu 14.04) I have restarted Apache after the update of openssl and TLS_FALLBACK_SCSV is working.
Put the following line in your configuration file, or replace any existing line starting with SSLProtocol:
SSLProtocol All -SSLv2 -SSLv3
Then run: $ sudo apache2ctl configtest && sudo service apache2 restart
You can test running command $ openssl s_client -connect <host>:<port> -ssl3
TLS_EMPTY_RENEGOTIATION_INFO_SCSV is the magic-word.
For more details, refer to http://www.exploresecurity.com, this is what it says:
TLS_FALLBACK_SCSV is a fake cipher suite advertised in the Client
Hello, which starts the SSL/TLS handshake. SCSV stands for “Signaling
Cipher Suite Value”. The idea of using a cipher suite as a signal is
not new: TLS_EMPTY_RENEGOTIATION_INFO_SCSV is a way clients can
advertise that they support secure renegotiation (addressing
CVE-2009-3555)
So, finally, for a Spring-boot project with embedded Apache Server, configuration would show up something like this:
server.ssl.enabled-protocols=TLSvx,TLSvx.y....
server.ssl.protocol=TLS
server.ssl.ciphers=TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,TLS_............TLS_EMPTY_RENAGOTIATION_INFO_SCSV
server.server-header="Willi Wonka!"
PS - To see all the the Spring-boot configurations / properties, plese visit this: https://docs.spring.io
Related
I have issues when to make my apache server uses TLS1.2. I respect all recommended configuration (ssl.conf, virtuals, ciphers ...) but apache is all the time using TLS1.0. I suspect the version of openssl to be the root cause.
Environment : RHEL 7
openssl version : OpenSSL 1.0.1e-fips
Apache version : Apache/2.4.6
I have this message on browser dev tools even though configuration seems to be ok :
The connection to this site is encrypted and authenticated using TLS 1.0, ECDHE_RSA, and AES_256_CBC with HMAC-SHA1.
TLS 1.0 is obsolete. Enable TLS 1.2 or later.
AES_256_CBC is obsolete. Enable an AES-GCM-based cipher suite.
can you help on this please ?
Make sure you have restarted apache.
And, make sure this line is added, and make sure all other SSLProtocol are commented using # at the start of the line, or removed:
SSLProtocol -all +TLSv1.2 +TLSv1.3
Or, if your version of OpenSSL doesn't support TLSv1.3:
SSLProtocol -all +TLSv1.2
I absolutely recommend you to update to the latest version of Apache (2.4.46 at the time of this post), and OpenSSL 1.1.1.
You can use SSL Labs to test your website's SSL conf.
Next:
AES_256_CBC is obsolete. Enable an AES-GCM-based cipher suite.
For the above, you can test your site on SSL Labs, and see the ciphers that are green and orange, and you can implement them by using https://testssl.sh/openssl-iana.mapping.html for help
I have configured a ListenHTTP 1.7.0 processor in NiFi 1.7.0-RC1. It is listening on a custom port behind a reverse proxy. I have configured a StandardRestrictedSSLContextService with a JKS keystore and have added the keystore password. We have not configured the truststore as we don't expect to need mutual TLS. The certificate is signed by an internal enterprise CA and is (or should be!) trusted by the client.
When I test this with Chrome I receive the following:
This site can’t provide a secure connection
my.server uses an unsupported protocol.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Unsupported protocol
The client and server don't support a common SSL protocol version or cipher suite.
Troubleshooting:
We have tried both TLS and TLSv1.2 in the ListenHTTP processor.
We have treid using curl (Linux) and Invoke-WebRequest (Windows) but have received variations on the bad cipher/SSL version message above.
I don't see anything in the release notes suggesting that the ListenHTTP processor changed much since 1.7.0, so I'm assuming that I don't need to upgrade NiFi.
Can anyone suggest what to try next or explain why we see this error?
I have read the following:
https://www.simonellistonball.com/technology/nifi-ssl-listenhttp/
https://cwiki.apache.org/confluence/display/NIFI/Release+Notes
Nifi: how to make ListenHTTP work with SSL
What version of Java are you running on? Java 11 provides TLSv1.3, which is the default offering if you have generic TLS selected, but NiFi 1.7.0 doesn't support TLSv1.3 (and doesn't run on Java 11). So assuming you are running on Java 8, recent updates have introduced TLSv1.3 but should still provide for TLSv1.2. This can also indicate that the certificate you have provided is invalid or incompatible with the cipher suite list provided by the client. You can use $ openssl s_client -connect <host:port> -debug -state -CAfile <path_to_your_CA_cert.pem> to try diagnosing the available cipher suites & protocol versions. Adding -tls1_2 or -tls1_3, etc. will restrict the connection attempt to the specified protocol version as well.
You should definitely upgrade from NiFi 1.7.0 -- it was released over 2 years ago, has known issues, and there have been close to 2000 bug fixes and features added since, including numerous security issues. NiFi 1.12.1 is the latest released version.
I find that in "SSL Report: google.com"
(P) This server prefers ChaCha20 suites with clients that don't have AES-NI (e.g., Android devices)
I tried to put all chacha20 ciphers at the beginning,doesn't work.
Then I tried to sort ciphers just like the report and it didn't work either.
How to sort the ciphers or configuration the nginx to get it?
Use boringssl to compile nginx.
Boringssl has Equal preference cipher groups
Set ciphers like below,you can get it.
ciphers [ECDHE-ECDSA-AES128-GCM-SHA256|ECDHE-ECDSA-CHACHA20-POLY1305]
Cloudflare cdn services can also do this Cloudflare sslconfig
That's likely because you are using an nginx version that doesn't support those ciphers.
Nginx uses the ciphers implemented on OpenSSL, and Chacha20 was only implemented in OpenSSL 1.0.2, so the version of nginx that you have installed likely uses an OpenSSL version that doesn't have support for those ciphers. For example, nginx-extras 1.10.3 uses libssl1.0.0, so it doesn't support Chacha20.
You can either install a version of nginx that supports a newer release of OpenSSL, or build nginx manually to include such support, like demonstrated in this article.
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.