We are using JBoss 7.1 in our application on Windows platform.
Is this particular version of JBoss vulnerable to POODLE??
All SSL implementations are vulnerable to POODLE attack.
For details how to disable SSLv3 for in EAP6 (AS7) see https://access.redhat.com/articles/1232123
Related
I was wondering if TLS 1.2 is supported by "camel-ftp" library for Java. The version used is 2.17.0.redhat-630262. Or should we upgrade the version to the latest for getting TLS 1.2 support? The Java version is 8.
The SSL support is provided by the underlying JDK. Java 8 has TLS V1.2, so this is available to camel -ftp (sftp endpoint). If you set securityProtocol to TLS, you will get the TLS protocols.
You may want to ensure that only the TLS V1.2 protocols are enabled in your jre/lib/security/java.security file, as the older, weaker, TLS versions are enabled by default.
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.
Considering the POODLE attack, I want to disable the SSLv3 in my web app deployed on IBM WebSphere 6. There are a few concerns I cant address:
1. How to disable SSL and enable TLS in WAS 6.0 and 6.1?
2. When a client hits the url of my application in browser, and the browser supports SSL, the request will be initiated with SSL. Is there such a possibility wherein end user will get a handshake exception as the WAS 6 will have SSL disabled?
3. Is there a change required in application configuration or changing web server properties will help?
You don't need to change anything in your application.
There is already fixpack provided for latest WebSphere versions - check this page Vulnerability in SSLv3 affects IBM WebSphere Application Server
For V6.1.0.0 through 6.1.0.47:
Apply Interim Fix PI28796 : Will upgrade you to IBM Java SDK Version 5.0 Service Refresh 16 Fix Pack 7 + APAR IV66111 for change to
disable SSLv3 by default.
6.0 is soo old, that I don't remember if it even supports TLS. You will have to dig in the admin console somewhere in SSL settings (the exact path might be different) Security > SSL > SSL_configuration_name and change the protocol to TLS.
If you access WebSphere via web server (Apache or IHS), then you need to disable SSLv3 on the web server instead of application server. For details see Vulnerability in SSLv3 affects IBM HTTP Server
Add the following directive to the httpd.conf file to disable SSLv3
and SSLv2 for each context that contains "SSLEnable":
# Disable SSLv3 for CVE-2014-3566
# SSLv2 is disabled in V8R0 and later by default, and in typical V7
# and earlier configurations disabled implicitly when SSLv3 ciphers
# are configured with SSLCipherSpec.
SSLProtocolDisable SSLv3 SSLv2
Stop and restart IHS for the changes to take affect.
This is closely related to
Using nxlog to ship logs in to logstash from Windows using om_ssl
Using SSL to ship from NXlog to Logstash
I have a working NXlog and Logstash configuration as described in the above links.
However, the TLS connection fails with following exception in the logstash log:
OpenSSL::SSL::SSLError: Client requested protocol SSLv3 not enabled or not supported
It seems that NXlog relies on SSLv3 instead of TLS 1.x to do the SSL handshake. However, the former has been disabled in recent Java versions (as used by logstash) due to the POODLE vulnerability.
So how can I disable SSLv3 on the client side and force NXlog to use TLS 1.2?
I have to answer this one myself (after getting help on the NXlog community forum).
TLS is only supported by nxlog-ce-2.9.1347 and later.
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