Cent Os 6.5
Vulnerability scan suggests deleting the following weak cipher (Cent Os server 6.5):
3des-cbc
aes128-cbc
aes192-cbc
aes256-cbc
arcfour
arcfour128
arcfour256
blowfish-cbc
cast128-cbc
rijndael-cbc#lysator.liu.se
My questions:
Am I right in saying that in order to delete those weak cipher I only need to add a line in /etc/ssh/sshd_config like the following:
Ciphers aes128-ctr,aes192-ctr,aes256-ctr
Are there any drawbacks? I mean what about clients wanting to connect through ssh to my server?
I'm referring to legacy clients
thanks a lot
Clients that only support weak ciphers would not be able to connect to your ssh service as you suggest.
I do not thing there are many clients that do not support the ciphers you'll keep tough.
Related
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.
I am getting this warning on mobile devices, the full warning is:
The connection uses TLS 1.2
The connection is encrypted using AES_256_CBC, with HMAC-SHA1 for message authentication and ECDHE_RSA as the key exchange.
I am using a dedicated VPS for the website and I have used IISCrypto with best practices applied.
You can see the results of the site scanner with the link below.
Qualys Scan Results
The Schannels I am using are below:
Schannel configuration
Chipher Suit Configuration
The Server is Windows 2012 r2 with IIS
Any help would be very grateful.
Paul.
To cite from the Chromium documentation what you need to do to make this warning go away:
... prioritize an ECDHE cipher suite with AES_128_GCM or CHACHA20_POLY1305. Most servers will wish to negotiate TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.
Looking at what Windows Server 2012 R2 actually supports on ciphers you'll find that it does not support CHACHA20_POLY1305 and that it supports GCM ciphers only with ECC certificates, i.e. it implements ciphers like TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256 but not ciphers like TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.
But, you are using an RSA certificate and not an ECC certificate which means that none of the GCM ciphers supported by your OS can be used with your certificate. The ciphers you need are only supported with Windows Server 2016.
I'm using j2ssh-core-0.2.9.jar to ssh to a Host.
In the logs I can see :
Client Algorithms: [diffie-hellman-group1-sha1]
Server Algorithms: [curve25519-sha256#libssh.org, ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, diffie-hellman-group-
exchange-sha256, diffie-hellman-group-exchange-sha1, diffie-hellman-group14-sha1]
I read the documentation provided on :
https://www.openssh.com/legacy.html
I went to the host to which I'm trying to ssh and executed :
ssh -Q kex
The output is :
diffie-hellman-group1-sha1
diffie-hellman-group14-sha1
diffie-hellman-group-exchange-sha1
diffie-hellman-group-exchange-sha256
ecdh-sha2-nistp256
ecdh-sha2-nistp384
ecdh-sha2-nistp521
diffie-hellman-group1-sha1
curve25519-sha256#libssh.org
I'm not able to understand how i can resolve this issue, because even though in the logs i can see that the server's key exchange methods do not contain diffie-hellman-group1-sha1 but when i execute the ssh-Q kex command on the host, the output shows that diffie-hellman-group1-sha1 is present.
Please help.
Your SSH client, which is now roughly 10 years old does not support the stronger, more secure algorithms of more modern servers.
I recommend (as the author of the API you are using) that you stop using it and move to a different API. There are plenty more up-to-date open source Java SSH APIs available to you including my own J2SSH Maverick, JSch and I'm sure there will be comments providing the case for others.
I have 2 computers - lets name it A and B. Both have the same OpenSSL version installed. Both Debian 8.3.
OpenSSL 1.0.1k 8 Jan 2015
I try to connect to a mailserver via SSL from both.
openssl s_client -host pop.amailserver.net -port 995
From A I need to specify the ssl-version (parameter -tls1 or -tls1_1) to make it work.
If not I get an error.
SSL routines:SSL3_GET_SERVER_HELLO:wrong ssl version:s3_clnt.c:851
...
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.1
Cipher : 0000
But from B it works out of the box without any parameter.
Protocol : TLSv1
Cipher : AES128-SHA
The problem is that some library seems to use this setting and is not able to connect from A (works from B). So I think its the same reason - I am not able to pass some SSL-parameters to the library.
Does anyone knows if this behavior is configured or set somewhere?
There is no global setting for ciphers or protocols which affect all OpenSSL based applications on the system. My guess is that the difference is in the network, like
there is a SSL intercepting middlebox (firewall or similar) somewhere
the target is different, i.e. A and B use different IP addresses for connecting to the server. This might be because the server is reachable by IPv4 and IPv6 but one system has IPv6 connectivity while the other does not. But there are also other reasons why different IP addresses might be used.
I was told to remove SSL_RSA_WITH_3DES_EDE_CBC_SHA from ciphers list since it is weak. When I looked at sslEnabledProtocols, I didn't see SSLv3. Following is what I have.
ciphers=TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA
sslEnabledProtocols=TLSv1,TLSv1.1,TLSv1.2
Question 1: Since SSLv3 is no longer listed on the sslEnabledProtocols, Should I assume that SSL_RSA_WITH_3DES_EDE_CBC_SHA is disabled automatically without removing it physically from ciphers? All ciphers starting with SSL_ are related to SSLv3?
Questions 2: Why both SSL_RSA_WITH_3DES_EDE_CBC_SHA and TLS_RSA_WITH_3DES_EDE_CBC_SHA have same OpenSSL name of DES-CBC3-SHA?
No. Confusingly this cipher suite is also available in TLS - sometimes called TLS_RSA_WITH_3DES_EDE_CBC_SHA but often not.
https://mta.openssl.org/pipermail/openssl-users/2015-April/001055.html
Note that if you remove that you will remove access from some older users (including IE8/XP). Always best to run scan through https://www.slllabs.com/ssltest/ to see which clients should be able to connect or not - and similarly this scan looks at SSL and TLS support and not just SSL despite its name :-) I imagine it will show a number of older clients using that cipher suite. So you can only disable if you're prepared to cut them off so you'll need to decide how much traffic that represents and if you want to do that or push back on this plan.