I am looking for some ideas on disabling TLS 1 and 1.1 in order to get the TLS version 2 working on my Apache Knox appliance. I tried :
Add a line in the gateway-site.xml file
<property>
<name>ssl.exclude.protocols</name>
<value>TLSV1.1</value>
<description>Excluded SSL protocols.</description>
</property>
Add the last line in the knoxsso.xml file :
<topology>
<gateway>
<provider>
<role>webappsec</role>
<name>WebAppSec</name>
<enabled>true</enabled>
<param><name>xframe.options.enabled</name><value>true</value></param>
<param><name>strict.transport.enabled</name><value>true</value></param>
</provider>
Try adding SSLv3, RC4, MD5withRSA, DH keySize < 768, TLSv1, TLSv1.1 to following property in /$JAVA_HOME/jre/lib/security/java.security
jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768, TLSv1, TLSv1.1
Restart knox and run following to verify:-
nmap -sV --script +ssl-enum-ciphers -p $(port) $(hostname -f)
Related
I am getting Error While running Nginx
Getting this in error log file the event "ngx_master_9488" was not signaled for 5s
I am using Windows Operating System
Please help me to solve this issue.
You can specify passphrase in text file, and connect it via ssl_password_file directive. Something like this:
listen 3001 ssl;
ssl_certificate cert.pem;
ssl_certificate_key key.pem;
ssl_password_file pass.txt
It will happen when when you enable ssl in nginx with key and pem file generated from openssl having a pass phrase for the key file.
Use the below command to remove the pass phrase from key file and refer the new file (serverunsecure.key) in nginx configuration.
openssl rsa -in server.key -out serverunsecure.key
i'm trying to run a server using Nginx with sslv3 and ciphers RC4-SHA:RC4-MD5 support (i need exactly these ciphers).
I was able to do this on Ubuntu 16.04 using Openssl 1.0.2u source + last nginx version source (nginx-1.19.6). I builded Nginx using this command:
./configure --with-http_ssl_module --with-openssl=/path/to/openssl-1.0.2u --with-openssl-opt=enable-ssl3 --with-openssl-opt=enable-ssl3-method --with-openssl-opt=enable-weak-ssl-ciphers
Nginx config i used is:
server {
listen 443 ssl;
listen [::]:443 ssl;
ssl_protocols SSLv3;
ssl_ciphers RC4-SHA:RC4-MD5:#SECLEVEL=0;
ssl_certificate /path/to/server-chain.crt;
ssl_certificate_key /path/to/server.key;
server_name server.name.net;
underscores_in_headers on;
proxy_pass_request_headers on;
location / {
proxy_set_header X-Forwarded-Host \$host:\$server_port;
proxy_set_header X-Forwarded-Server \$host;
proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for;
proxy_pass http://127.0.0.1:9000;
}
}
After setting up nginx config file everything worked perfectly. I was able to obtain the ssl certificate using this command from an Ubuntu 14.04 machine:
openssl s_client -connect MyIP:443 -ssl3 -cipher RC4-SHA:RC4-MD5.
I tryed to do the same thing building Nginx with Openssl 1.1.1i source with the same configuration options, but after setting up nginx conf file, when i try to run openssl s_client -connect... command, i get this error:
CONNECTED(00000003)
140420793624224:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:339:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 7 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : SSLv3
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1612540521
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
In Nginx error.log file i got this:
SSL_do_handshake() failed (SSL: error:141FC044:SSL routines:tls_setup_handshake:internal error) while SSL handshaking, client: 192.168.1.10, server: 0.0.0.0:443
Did something change with openssl 1.1.1? Am i missing any configuration options to enable SSLv3 + RC4-SHA:RC4-MD5?
Thanks for any tips!
In the end i was able to fix this!
I downloaded the last openssl source (1.1.1i) and the last nginx source (1.19.6).
I compiled and installed openssl with the following commands:
./config enable-ssl3 enable-ssl3-method enable-weak-ssl-ciphers
make
sudo make install
I edited openssl.cnf file (/usr/local/ssl/openssl.cnf) adding
openssl_conf = default_conf
at the beginning of the file and adding
[default_conf]
ssl_conf = ssl_sect
[ssl_sect]
system_default = system_default_sect
[system_default_sect]
CipherString = ALL:#SECLEVEL=0
at the bottom of the file. This enables old ciphers (i needed RC4-SHA and RC4-MD5).
Then i compiled and installed nginx with the following commands:
./configure --with-http_ssl_module --with-ld-opt="-L/usr/local"
make
sudo make install
After configuring nginx for ssl certificates i was able to get them using the openssl s_client... command!
SSL Ciphers in nginx need to be supported by your openSSL Version. From the openSSL Changelog of 1.0.2h and 1.1.0:
RC4 based libssl ciphersuites are now classed as "weak" ciphers and are disabled by default. They can be re-enabled using the enable-weak-ssl-ciphers option to Configure.
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
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