List all Openssl ciphers a server supports - http

Is it possible to list all Openssl ciphers a server supports?

It is not possible to ask a TLS server about all the supported ciphers. All one can do is to probe the server for a specific cipher and observe if it reports that the server will support this cipher or not. With openssl command line this would mean to use openssl s_client -no_tls1_3 -cipher ... for probing TLS 1.2 and lower ciphers and openssl s_client -tls1_3 -ciphersuites ... for TLS 1.3 ciphers.
Example for a successful handshake:
$ openssl s_client -no_tls1_3 -cipher AES128-GCM-SHA256 -connect google.com:443
...
SSL-Session:
Protocol : TLSv1.2
Cipher : AES128-GCM-SHA256
And for a failed handshake:
$ openssl s_client -no_tls1_3 -cipher AES128-SHA256 -connect google.com:443
...
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
There are several limits to this approach though:
One can only probe ciphers supported by the version of openssl in use, see openssl ciphers -V
Some server might limit specific ciphers to specific TLS protocol versions, like weaker ciphers only with TLS 1.0. So one also has to iterate over the various TLS protocol versions when probing
Some server limit ciphers only when specific ECC curves are announced as supported by the client
Some servers have different configurations for different domains on the same IP address
Thus, for the successful tests one can be sure that the cipher is supported. For unsuccessful tests one cannot be fully sure that the cipher is not supported since it might only be supported in a specific context. For ciphers not tested one has no idea if these are supported or not.

Related

haproxy not restricting to TLS 1.2

Having troubles understanding where I am messing up, I want to disable TLS 1 and TLS 1.1 so SSL Labs improves my cert score.
I have tried adding the force tls1_2 line in HAproxy as well to no avail. I am still learning more about TLS but from what I understand this should work.
Configuration:
Cloudflare -> Haproxy -> backend server
Cloudflare origin cert is between cloudflare and haproxy
Haproxy Config (in regards to TLS)
global
ssl-default-bind-options ssl-min-ver TLSv1.2 prefer-client-ciphers
ssl-default-bind-ciphers ECDH+AESGCM:ECDH+CHACHA20:ECDH+AES256:ECDH+AES128:!aNULL:!SHA1:!AESCCM
ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
ssl-default-server-options ssl-min-ver TLSv1.2
ssl-default-server-ciphers ECDH+AESGCM:ECDH+CHACHA20:ECDH+AES256:ECDH+AES128:!aNULL:!SHA1:!AESCCM
ssl-default-server-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256```
frontend https-in
bind *:443 ssl crt /etc/haproxy/domainhere.com.pem ssl-min-ver TLSv1.2 force-tlsv12
Openssl.conf
#system Default
openssl_conf = default_conf
[default_conf]
ssl_conf = ssl_sect
[ssl_sec]
system_default = system_default_sect
[system_defualt_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT#SECLEVEL=2
Versions:
HAProxy version 2.4.4-1ppa1
OpenSSL 1.1.1f
The ha proxy config seems correct.
Did you try openssl command on your ha proxy? By varying the tls version?
Something like
openssl s_client -connect <YourHost>:443 -servername <YourHost> -tls1_0
openssl s_client -connect <YourHost>:443 -servername <YourHost> -tls1_1
openssl s_client -connect <YourHost>:443 -servername <YourHost> -tls1_2
Notice that you had to supply the hostname twice. The -connect switch is used to establish the TCP connection, but -servername is used to specify the hostname sent at the TLS level. Starting with OpenSSL 1.1.1, the s_client tool automatically configures the latter.
You’ll still need to use the -servername switch if
you’re using an earlier version of OpenSSL,
you’re connecting to an IP address
the TLS host needs to be different.
To anyone who stumbles upon this after fighting with HAProxy...
Cloudflare -> SSL/TLS -> Edge Certificates -> Minimum TLS Version
Cloudflare still defaults to TLSv1.0 so you will need to change this to get a better SSL Server Test score.

How to fix ERR_SSL_VERSION_OR_CIPHER_MISMATCH error?

How to fix the ERR_SSL_VERSION_OR_CIPHER_MISMATCH error?
In one of our CentOS server, we are encountering the following error in Chrome
A secure connection cannot be established because this site uses an unsupported protocol with Error Code - ERR_SSL_VERSION_OR_CIPHER_MISMATCH
We tried following command - openssl s_client -connect <<domain>>:<<port>> -tls1_2
It gives the following output. It doesn't provide a chain of certificates and negotiated cipher.
$ openssl s_client -connect <<domain>>:<<port>> -tls1_2
CONNECTED(00000003)
139874418423624:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1275:SSL alert number 40
139874418423624:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:598:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1505770082
Timeout : 7200 (sec)
Verify return code: 0 (ok)
We checked available ciphers on VM using command - # /usr/bin/openssl ciphers -v. This command provides a list of available ciphers which also include ciphers supported by TLS 1.2
We also checked certificates. The same certs work on different servers.
Can someone please guide what is missing in this scenario?
When we use openssl, if the connection gets terminated with the alert 40 error, that means we should explicitly specify the servername in our command, so that the server can return the right certificate the client is expecting.
Specify the exact hostname you want with -servername parameter. E.g:
openssl s_client -connect yourserver.domain.com:443 -servername yourserver.domain.com

TLS v1 disable options in Corda

does anybody if is possible to disable TLS v1 in Corda Artemis. I know Corda use TLS v1.2 but our problem is TLS v1 is enable in the system.
If I run "openssl s_client -connect IP:port -tls1" I get a sucessfully respond. Is there a way to disable TLS v1 in corda? Thanks!! –
TLS1 is not enabled. If you run openssl s_client -connect IP:port -tls1 and try and connect to a node, you get a wrong version number error, indicating that TLS1 is not supported.
The list of supported TLS versions can be found here: https://github.com/corda/corda/blob/master/node-api/src/main/kotlin/net/corda/nodeapi/ArtemisTcpTransport.kt. Only v1.2 is supported.

How to identify and remove CBC ciphers in the CipherSuite?

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.

Ejabberd check cipher with openssl

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

Resources