How to fix ERR_SSL_VERSION_OR_CIPHER_MISMATCH error? - encryption

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

Related

List all Openssl ciphers a server supports

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.

How can we enable Transport layer Security in Hive metastore?

I need to know how to enable Transport layer security in Hive Metastore and how to verify it. Should we create another .xml file specifying the property? This should be based on Thrift url.
I tried to edit two files in hive-metastore by specifying the properties -metastore-site.xml and conf-site.xml. And I am getting the following error even after creating the keys:
[root#primmer1 lh-hms-poc]# openssl s_client -connect 9.30.94.163:9083 -cert cert.crt -key cert.key
CONNECTED(00000003)
139828257847184:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 289 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
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: 1672830872
Timeout : 300 (sec)
Verify return code: 0 (ok)
---

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.

pypi remote repository fails SSL Test

It appears sometime in June of this year our SSL validation inside of Artifactory started to fail for https://files.pythonhosted.org. As a result we are no longer able to resolve remote lookups for python packages not hosted locally.
The error when I click Test on the remote repository settings page with https://files.pythonhosted.org as the hostname:
Connection to remote repository failed: Certificate for doesn't match
any of the subject alternative names:
[r.shared-319-default.ssl.fastly.net]
When I try to validate the SSL using openssl on the host linux server:
openssl s_client -connect files.pythonhosted.org:443
subject=/CN=r.shared-319-default.ssl.fastly.net
If I pass the servername flag to openssl it finds the right cert:
openssl s_client -servername files.pythonhosted.org -connect files.pythonhosted.org:443
subject=/CN=*.pythonhosted.org
How do I go about fixing this in the UI?
server: CentOS Linux release 7.7.1908 (Core)
artifactory version: EnterpriseX license 7.3.2 rev 70302900
EDIT
Appears this is most likely caused by the version of artifactory this specific instance is running. I was able to check a newer version than what this instance is running and it works correctly.
EDIT2
The system.yaml contained the following
extraJavaOpts: -Djsse.enableSNIExtension=false
this was disabling artifactory from resolving SNI enabled domains. Fixed!
I tested the reported scenario. Executing an openssl command to retrieve the certificate from the Python registry is returning certificates with a different CN apart from the expected one.
Command:
openssl s_client -showcerts -connect files.pythonhosted.org:443 </dev/null
I couldn't confirm if this is an issue with a redirect. However, executing the command to retrieve the certificate with server name in specific appears to be revealing the actual certificate for the remote site.
So, Could you please try using the following command, collect the certificate and use this certificate to replace the already amended certificates in support of this remote connection?
openssl s_client -showcerts -connect files.pythonhosted.org:443 -servername files.pythonhosted.org </dev/null
I'm not familiar with the artifactory you mentioned. But I can give you a hint on the certificate part, in general, your issue is caused by the website files.pythonhosted.org support SNI and your client-side cannot recognize the SNI support.
To check the server website ssl information, you can visit:
https://www.ssllabs.com/ssltest/analyze.html?d=files.pythonhosted.org&s=151.101.1.63
In the result, you can see a line "Certificate #2: RSA 2048 bits (SHA256withRSA) No SNI" which means there are 2 certificates in the server, and for more explanation, you can check
https://support.cpanel.net/hc/en-us/articles/360055289933-Why-is-SSLLabs-Certificate-2-RSA-2048-bits-SHA256withRSA-No-SNI-test-showing-an-error-
And OpenSSL older version cannot handle SNI correctly as well, that's why your openssl command is not returning the expected result. Actually, the same command
openssl s_client -showcerts -connect files.pythonhosted.org:443
with OpenSSL 1.0.2k-fips on Oracle Linux 7, it returns:
r.shared-319-default.ssl.fastly.net
with OpenSSL 1.1.1 FIPS on Centos 8, it returns: *.pythonhosted.org
So the issue may be related to https://www.jfrog.com/jira/browse/HAP-556
https://www.jfrog.com/jira/si/jira.issueviews:issue-html/BI-167/BI-167.html

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