I am running 389-DS on CentOS. Version - '389-ds-base.i686 1.2.11.15-34.el6_5'.
Security scans revealed that NullCiphers were found on Port 389 and 636.
I tried to disable them by shutting down DS, editing the 'nsSSL3Ciphers' on all '/etc/dirsrv/slapd-/dse.ldif' files, and starting DS. nsSSL3Ciphers looks like this now -
modifyTimestamp: 20140915221826Z
nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5,
+rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo
rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs
a_export1024_with_des_cbc_sha
numSubordinates: 1
Scans are still showing Null Cipher on those 2 ports.
Here is the list of null SSL ciphers supported by the remote server :
Null Ciphers (no encryption)
TLSv1
NULL-SHA Kx=RSA Au=RSA Enc=None Mac=SHA1
The fields above are :
{OpenSSL ciphername}
Port
389 / tcp / ldap
636 / tcp / ldap
Any ideas on how i can disable these Null ciphers?
Set nsSSL3Ciphers to the following -
nsSSL3Ciphers: +all,-rsa_null_sha
Related
Trying out Cassandra 4 for encrypted internode communication.
Following settings are made in cassandra.yaml
server_encryption_options:
internode_encryption: all
optional: false
enable_legacy_ssl_storage_port: true
keystore: conf/.keystore
keystore_password: password
require_client_auth: true
truststore: conf/.truststore
truststore_password: password
require_endpoint_verification: false
# More advanced defaults below:
protocol: TLS
store_type: JKS
cipher_suites: [TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384]
However these ciphers are not being listed with nmap --script +ssl-enum-ciphers -p 7000 <hostname>
Have not seen this issue with earlier Cassandra 3.11.x.
Are there any further settings apart from cassandra.yaml which are being missed here for Cassandra 4?
Ok, I think I see what's going on. Before Cassandra 4.0, inter-node SSL traffic used port 7001. However, Cassandra 4.0 allows both encrypted and unencrypted inter-node communication on port 7000...
...unless you explicitly enable the legacy SSL port...
enable_legacy_ssl_storage_port: true
Two possible solutions here:
Run npm against port 7001, and you should see the available ciphers returned.
Set enable_legacy_ssl_storage_port: false, restart, and the npm against port 7000 should work.
My nginx server is successfully verifying most (expected) client certificates, but some older client certificates are getting "400 Bad Request The SSL certificate error" and producing this log entry -- "client SSL certificate verify error: (68:CA signature digest algorithm too weak)"
Is there a way to allow older signature digest algorithms?
Running openssl list -digest-algorithms shows sha1RSA, but it isn't included in the TLSv1.2 - Handshake Protocol - Certificate Request Message.
Versions:
- helm chart nginx-ingress v1.1.3
- nginx-ingress-controller v0.21.0
- nginx v1.15.6
- openssl 1.1.1
-- Update --
To verify client certificates that are signed with weak digest algorithms, append #SECLEVEL=0 to your ssl_ciphers list, i.e. ssl_ciphers 'HIGH:!aNULL:!MD5#SECLEVEL=0';
discussion and openssl reference.
I don't understand the full implications of #SECLEVEL, so best solution is to push for updated client certificates!
I have apache http server with below ciphers in the cipherSuite. After a scan I found some of the ciphers(CBC) are weak and need to be removed. But I am unable to identify which of them are actually CBC. Can you please help?
FYI -
Versions are
Apache 2.4.23; openssl 1.0.2h; RHEL7
SSLCipherSuite:
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:
ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:
ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:
ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:
ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:
DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:
DHE-DSS-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:
AES128-SHA256:AES256-SHA256:AES:DES-CBC3-SHA:
!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:
!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!3DES
CBC ciphers causing vulnerability: How to identify these in above suite?
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A*
I found some ciphers with "CBC3", but when I remove them Apache is not responding for https requests.
Any cipher with CBC in the name is a CBC cipher and can be removed. For improved security, you should also sort the ciphers from strongest to weakest and set SSLHonorCipherOrder on and SSLProtocol all -SSLv3 in your config.
Mozilla has a neat tool for generating secure webserver configurations that you might find useful, notably the modern cipher suite configuration for your Apache and OpenSSL version. After that, try the Qualsys SSL Labs Test to see how you did.
I am very concerned about the difference in performance between HTTPS and HTTP/2.
I am very concerned about the consumed time about each step of the process of connecting.
Include TCP handshakes SSL Handshakes and Client sent Application Data Client received Application Data.
I made a test.
Use Nginx Server, set port 440 : ssl, and port 442 : ssl http2
Turn off ssl_session_cache and ssl_session_tickets, then every request would process TCP Handshakes and SSL Handshakes
// https url : ssl_session_cache off; ssl_session_tickets off;
https://www.example.com:440/index.html
// http/2 url : ssl_session_cache off; ssl_session_tickets off;
https://www.example.com:442/index.html
At the end, I launched the two urls above 1000 times from a android app with OKHttp 3.8.1.
Each request has been added Header Connection : Close.
At the same time, use Wireshark for capturing packets.
The statistical results are unexpected!!!
HTTP/2 consume more time than HTTPS in the step Client Receive Application Data From Server.
Why? I am confused. Am i wrong? Any ideas??? Thank u.
statistical results (Time : ms)
https.url.and.http2.url
nginx.conf
[root#iZ941gs04jwZ ~]# nginx -V
nginx version: nginx/1.12.0
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC)
built with OpenSSL 1.0.2l 25 May 2017
TLS SNI support enabled
configure arguments: --prefix=/usr/local/webserver/nginx --with-http_stub_status_module --with-http_ssl_module --with-pcre=/root/tmp/pcre-8.35 --with-http_v2_module --with-openssl=../openssl-1.0.2l
I am trying to set up ciphers for port 5222 ejabberd 14.07
my ejabberd.yml:
I have removed ECDHE and DHE based ciphers
port: 5222
module: ejabberd_c2s
protocol_options:
- "no_sslv2"
- "no_sslv3"
- "no_tlsv1"
- "no_tlsv1_1"
max_stanza_size: 65536
shaper: c2s_shaper
access: c2s
ciphers: "EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS"
starttls: true
And check with openssl:
$ openssl s_client -connect dev.my.server:5222 -starttls xmpp
CONNECTED(00000003)
^C
Connection accepted (from my server logs):
Accepted connection 10.2.3.1:41007 -> 10.2.3.2:5222
But when I run
openssl s_client -cipher 'ECDHE-RSA-AES256-SHA' -connect dev.mantu.im:5222 </dev/null -starttls xmpp
or -cipher 'DSS' I slill see "Accepted connection", but I am expecting it should fails
What was set up wrong? Or I run uncorrect command to check it?
I suggest you to configure port 5223 with tls: true and then trying to connect without starttls. Without this Accepted connection can mean anything, for example connecting without doing SSL magic.
finally I checked it with this tool tsp hello dump and escalus
./tls-hello-dump eth0 | sed -f ./readable.sed > /var/log/ejabberd/tlshello.txt
and found
10.2.1.18 10.2.1.44 TLSv1 ClientHello TLSv1.2 :TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384:TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384:TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384:TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384:TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA:TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA:TLS_DHE_DSS_WITH_AES_256_GCM_SHA384:TLS_DHE_RSA_WITH_AES_256_GCM_SHA384:TLS_DHE_RSA_WITH_AES_256_CBC_SHA256:TLS_DHE_DSS_WITH_AES_256_CBC_SHA256:TLS_DHE_RSA_WITH_AES_256_CBC_SHA:TLS_DHE_DSS_WITH_AES_256_CBC_SHA:TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA:TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA:TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384:TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384:TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384:TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384:TLS_ECDH_RSA_WITH_AES_256_CBC_SHA:TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA:TLS_RSA_WITH_AES_256_GCM_SHA384:TLS_RSA_WITH_AES_256_CBC_SHA256:TLS_RSA_WITH_AES_256_CBC_SHA:TLS_RSA_WITH_CAMELLIA_256_CBC_SHA:TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256:TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA:TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA:TLS_DHE_DSS_WITH_AES_128_GCM_SHA256:TLS_DHE_RSA_WITH_AES_128_GCM_SHA256:TLS_DHE_RSA_WITH_AES_128_CBC_SHA256:TLS_DHE_DSS_WITH_AES_128_CBC_SHA256:TLS_DHE_RSA_WITH_AES_128_CBC_SHA:TLS_DHE_DSS_WITH_AES_128_CBC_SHA:TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA:TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA:TLS_DHE_RSA_WITH_SEED_CBC_SHA:TLS_DHE_DSS_WITH_SEED_CBC_SHA:TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA:TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA:TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA:TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA:TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256:TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256:TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256:TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256:TLS_ECDH_RSA_WITH_AES_128_CBC_SHA:TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA:TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA:TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA:TLS_RSA_WITH_AES_128_GCM_SHA256:TLS_RSA_WITH_AES_128_CBC_SHA256:TLS_RSA_WITH_AES_128_CBC_SHA:TLS_RSA_WITH_SEED_CBC_SHA:TLS_RSA_WITH_CAMELLIA_128_CBC_SHA:TLS_RSA_WITH_3DES_EDE_CBC_SHA:TLS_RSA_WITH_IDEA_CBC_SHA:TLS_ECDHE_RSA_WITH_RC4_128_SHA:TLS_ECDHE_ECDSA_WITH_RC4_128_SHA:TLS_ECDH_RSA_WITH_RC4_128_SHA:TLS_ECDH_ECDSA_WITH_RC4_128_SHA:TLS_RSA_WITH_RC4_128_SHA:TLS_RSA_WITH_RC4_128_MD5:TLS_EMPTY_RENEGOTIATION_INFO_SCSV:
10.2.1.44 10.2.1.18 TLSv1.2 ServerHello TLSv1.2 cipher TLS_RSA_WITH_AES_256_GCM_SHA384
So ServerHello TLSv1.2 cipher TLS_RSA_WITH_AES_256_GCM_SHA384 always correct cihpers
P.S. I can not remove this posted question