Vulnerability scan shows that my server (server1821) is currently vulnerable to TLS ROBOT
Server is AIX.
How do I check for this vulnerability and how to fix this?
I checked with my vender and I got the reply as :
Does the scan report which ports are vulnerable? Those applications using TLS protocol with RSA ciphers need to be altered so they no longer use RSA. We need to do this at the application level.
Not sure about this suggestion.
The TLS ROBOT advisory site ((https://robotattack.org/) doesn't have any answers with respect to AIX.
A simple command shows this"
serverl1821 2 % cat /etc/ssh/sshd_config |grep -i rsa
#HostKey /etc/ssh/ssh_host_rsa_key
serverl1821 3 %
Can anyone help me here?
Your application vendor is absolutely correct. First of all you have to ask you security guys, where they found the vulnerability. Not only the server name, but also the port.
Then the problem may be in one of the following component:
OpenSSH
OpenSSL
IBM GSKit
Java
Every of the components requires different tuning to disable RSA ciphers.
To make it more complex every application can come with their own SSL/TLS library and their own set of settings.
The vulnerability may have nothing to do with ssh. You should update GSKit package. This is the package which implement SSL/TLS in AIX. And do not forget to restart web/application server.
Related
I'm getting this error when i try to connect to a SSL (protocol v3) LDAP server in Apache Directory Studio.
I'm connecting to a LDAP server on port 636 (ldaps) with SSL encryption.
ERR_04120_TLS_HANDSHAKE_ERROR The TLS handshake failed, reason: Unspecified: The server selected protocol version TLS10 is not accepted by client preferences [TLS12]
I'm using Apache Directory Studio Version: 2.0.0.v20210213-M16 on MacOS 11.2.3 (20D91)
java.version=16
java.vendor=Azul Systems, Inc.
It seems that "some" update maybe disabled TLS1.0 on my mac???
Any clues how to fix this?
So this may be a little late, but you need to follow the instructions here.
An update to the JDK has disabled TLS1 and TLS1.1 support by default. You can change the defaults so they are no longer disabled.
Basically you need to find the jdk.tls.disabledAlgorithms property in ${JAVA_HOME}/conf/security/java.security file and remove the offending algorithm from the list (TLS1).
Once you do this, you should be good to go.
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 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 have a site which is served over HTTPS, but which iTunes can't find. My suspicion is that it's related to the iTunes backend server being Java 6, and Java 6 not supporting SNI. SSL Labs seems to hint that my site does require SNI (see this report, and search for SNI), but I can't think why. Have I misunderstood multi-domain certificates? I've got multiple sites running on the same server, but my understanding was that as long as all the URLs were listed as Subject Alternative Names on the certificate, that all would be well.
Does anyone know a good way to check if a URL requires SNI support on the client to access it? I don't have a Windows XP/Java 6 install around to play with sadly.
The reports from SSLLabs regarding SNI are usually correct. Your understanding that SNI is not needed if your certificate contains all possible hosts is correct too. But, not needed in theory does not mean that your server setup does not require SNI anyway.
I don't have a Windows XP/Java 6 install around to play with sadly.
Given that you only specify what you don't have I will assume that you have everything else which might be used. A simple way to check is openssl:
# without SNI
$ openssl s_client -connect host:port
# use SNI
$ openssl s_client -connect host:port -servername host
Compare the output of both calls of openssl s_client. If they differ in the certificate they serve or if the call w/o SNI fails to establish an SSL connection than you need SNI to get the correct certificate or to establish a SSL connection at all.
An easy way to check if a site relies on SNI is this:
openssl s_client -servername alice.sni.velox.ch -tlsextdebug -msg \
-connect alice.sni.velox.ch:443 2>/dev/null | grep "server name"
And if in that output you see the following, it means the site is using SNI.
TLS server extension "server name" (id=0), len=0
The above is a summary of an answer at serverfault.
Nginx in general, and your site in particular, accepts but doesn't require SNI. To test this you cannot easily use Oracle Java out of the box, because its cacerts does not include DST Root CA X3 which is the root cert used (initially) by 'Let's Encrypt' who issued your site's cert; this is true for all versions of Oracle Java up to current (8u74). Windows (hence IE and Chrome on Windows) and Firefox do have this root cert; I can't say for other OS or browsers.
To fix this so you can easily test, either:
use Oracle Java 6 but modify JRE/lib/security/cacerts to add the DSTX3 cert, obtained either from your OS or browser, or by following the link at https://letsencrypt.org/certificates/ to https://www.identrust.com/certificates/trustid/root-download-x3.html -- except that page nonstandardly gives you only the base64 body of the cert so you must manually add the PEM header and trailer lines before Java keytool will import it.
use Oracle Java 6 as-is but configure your application (with system properties) to use a custom truststore which you create containing the DSTX3 cert as above.
use a version of Java 6 that does include this root cert in cacerts. In particular I use CentOS 6 and its openjdk packages (for 6, 7, and 8) use a systemwide CA 'bundle' that includes DSTX3, which is what made it easy for me to do this test. I expect, but can't confirm, that other RedHat variants do the same. For other distros and platforms I can't say; if not, see above.
Monitor the connection attempt with wireshark or similar to see that the ClientHello does not contain SNI, but the connection succeeds and is successfully used for an HTTP request.
If you actually want to communicate with the server instead of testing it for SNI, simply omit the final 'monitor' step.
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