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.
Related
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.
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
I am new to ssl / networking and want to utilize mutal ssl ( client verifies server and server verifies peer) I found a white paper (http://www.infidigm.net/articles/qsslsocket_for_ssl_beginners/) online that gave me some guidance for setting up my certs and keys. Now this paper utilizes a local host ip address as the clients cert file. I want to switch this to a register domain name (scp.radiant.io). This FQDN is local to my ubuntu os for testing purposes
updated my localhost to have a domianname (scp.radiant.io). by modifying this file sudo nano /etc/hosts/ to say 127.0.0.1 scp.radiant.io localhost
Next I create certificate and private keys for both client and server
a. Steps for gen certs example for server below. same commands are run for client to create client certs
openssl req -out server_ca.pem -new -x509 -nodes -subj "/C=$COUNTRY/ST=$STATE/L=$LOCALITY/O=$ORG/OU=$ORG_UNIT/CN=server/emailAddress=radiant.$EMAIL"
mv privkey.pem server_privatekey.pem
touch server_index.txt
echo "00" >> server_index.txt
openssl genrsa -out server_local.key 1024
openssl req -key ${NAME}_local.key -new -out server_local.req -subj "/C=$COUNTRY/ST=$STATE/L=$LOCALITY/O=$ORG/OU=$ORG_UNIT/CN=scp.radiant.io/emailAddress=$EMAIL"
openssl x509 -req -in ${NAME}_local.req -CA ${NAME}_ca.pem -CAkey server_privatekey.pem -CAserial server_index.txt -out server_local.pem
b. this generates a CaCerts (server_ca.pem and client_ca.pem)
c. this generates a Local Cert files (server_local.pem and client_local.pem).. THIS IS WHERE I SET FQDN to scp.radiant.io
d. this generate a LocalKey (server_local.key and client_local.key)
I use the generated cert files for setting up the ssl configuration on the QSslSocket for both sides like so
//client socket setup
config.setPrivateKey("server_local.key");
config.setLocalCertificate("server_local.pem");
config.addCaCertificate("client_ca.pem");
config.setPeerVerifyMode("QSslSocket::VerifyPeer");
sslSocket->setSslConfiguration(config);
sslSocket->connectToHostEncrypted("scp.radiant.io",1200);
// server socket setup
config.setPrivateKey("client_local.key");
config.setLocalCertificate("client_local.pem");
config.addCaCertificate("server_ca.pem");
config.setPeerVerifyMode("QSslSocket::VerifyPeer");
sslSocket->setSslConfiguration(config);
sslSocket->startServerEncryption()
When running this code i get the following error in my ssl errors. "The host name did not match any of the valid hosts for this certificate
Now if I change the client socket to use this when connecting sslSocket->connectToHostEncrypted("scp.radiant.io",1200,"scp.radiant.io"); it will work.
I dont understand why I have to set the peerVerifyHost argument when connecting encrypted. I would like use the same certificates for my WebSockets implementation for this as well but the QWebSocket class does not allow you to set the peerverifyHost when connecting. So I must be doing something wrong at the cert level or the os level for my FQDN. any networking and ssl help would be helpful
I think you can ignore this error using "ignoreSslErrors" and let the handshake continue
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.
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