TLS Connection - Beats to Redis - ssl

I have Winlogbeat installed on a Windows box using Redis output.
The Redis server is configured for TLS on port 6380.
Both ends start services up successfully but the connection does not succeed. I have tried different combinations of protocols and cipher suites but no luck. What am I missing? The error messages:
Redis:
Error accepting a client connection: error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher
Windows:
ERROR [publisher_pipeline_output] pipeline/output.go:154 Failed to connect to redis(tcp://10.1.1.4:6380): remote error: tls: handshake failure
Here is the redis-server config. The CA is self-signed, 2048-bit key and x509 certificate. The server certificate is also x509. I think I may need to rebuild the CA, but feedback is appreciated on this.
#tls configs
tls-port 6380
tls-cert-file /etc/ssl/redis.crt
tls-key-file /etc/ssl/private/redis.key
tls-ca-cert-file /usr/local/share/ca-certificates/ca.crt
tls-auth-clients no
tls-prefer-server-ciphers no
tls-protocols "TLSv1.2"
tls-dh-params-file /etc/ssl/redis.dh
tls-ciphers DEFAULT
tls-ciphersuites ECDHE-ECDSA-CHACHA20-POLY1305
And the Beats config.
output.redis:
hosts: ["10.1.1.4:6380"]
password: "redispass"
key: "winlogbeat"
db: 0
timeout: 5
data_type: "list"
ssl:
enabled: true
certificate_authorities: ["C:\\Program Data\\Winlogbeat\\ca.crt"]
insecure: true
supported_protocols: [TLSv1.2]
cipher_suites: [ECDHE-ECDSA-CHACHA20-POLY1305]
curve_types: [P-256]

Finally worked it out, in case anyone is interested.
Needed to install and configure the CA with proper params, and then create a SAN server certificate for Redis using IP addresses and a hostname. Here are the articles I followed.
On the server that hosts Redis, create the root CA: https://blog.devolutions.net/2020/07/tutorial-how-to-generate-secure-self-signed-server-and-client-certificates-with-openssl (just the root CA from this article).
Create the Redis server certificate using IP address subject alternative names: https://www.golinuxcloud.com/openssl-generate-csr-create-san-certificate/
Install Redis from source with TLS support: https://godfrey-tutu.medium.com/redis-6-deployment-with-tls-authentication-on-centos-7-8b6e34d11cd0
Beats and Redis will negotiate best encryption. If you keep the existing Redis config and add the TLS piece on a different unused port, then Redis will start up and listen on both.
Here is the new Beat config:
output.redis:
hosts: ["10.1.1.4:6380"]
password: "redispass"
key: "winlogbeat"
db: 0
timeout: 5
data_type: "list"
ssl:
enabled: true
certificate_authorities: ["C:\\Program Data\\Winlogbeat\\ca.crt"]
insecure: true
supported_protocols: [TLSv1.1, TLSv1.2]
And Redis...
tls-port 6380
tls-cert-file /etc/pki/tls/certs/redis.crt
tls-key-file /etc/pki/tls/private/redis.key
tls-ca-cert-file /etc/pki/tls/certs/ca.crt
tls-auth-clients no
tls-protocols "TLSv1.1 TLSv1.2"
tls-prefer-server-ciphers yes

Related

TLS handshake fails intermittently when using HAProxy Ingress Controller

I'm using HAProxy Ingress Controller (https://github.com/helm/charts/tree/master/incubator/haproxy-ingress) for TLS-termination for my app.
I have a simple Node.JS server listening on 8080 for HTTP, and 1935 as a simple echo server (not HTTP).
And I use HAProxy Ingress controller to wrap the ports in TLS. (8080 -> 443 (HTTPS), 1935 -> 1936 (TCP + TLS))
I installed HAProxy Ingress Controller with
helm upgrade --install haproxy-ingress incubator/haproxy-ingress \
--namespace test \
-f ./haproxy-ingress-values.yaml \
--version v0.0.27
, where the content of haproxy-ingress-values.yaml is
controller:
ingressClass: haproxy
replicaCount: 1
service:
type: LoadBalancer
tcp:
1936: "test/simple-server:1935:::test/ingress-cert"
nodeSelector:
"kubernetes.io/os": linux
defaultBackend:
nodeSelector:
"kubernetes.io/os": linux
And here's my ingress:
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: ingress
annotations:
kubernetes.io/ingress.class: "haproxy"
spec:
tls:
- hosts:
secretName: ingress-cert
rules:
- http:
paths:
- path: /
backend:
serviceName: "simple-server"
servicePort: 8080
The cert is self-signed.
If I test the TLS handshake with
echo | openssl s_client -connect "<IP>":1936
Sometimes (about 1/3 of the times) it fails with
CONNECTED(00000005)
139828847829440:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:332:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 316 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
The same problem doesn't happen for 443 port.
See here for the details of the settings to reproduce the problem.
[edit]
As pointed out by #JoaoMorais, it's because the default statistic port is 1936.
Although I didn't turn on statistics, it seems like it still interferes with the behavior.
There're two solutions that work for me.
Change my service's 1936 port to another
Change the stats port by adding values like below when installing the haproxy-ingress chart.
controller:
stats:
port: 5000
HAProxy by default allows to reuse the same port number across the same or other frontend/listen sections and also across other haproxy process. This can be changed adding noreuseport in the global section.
The default HAProxy Ingress configuration uses port number 1936 to expose stats. If such port number is reused by eg a tcp proxy, the incoming requests will be distributed between both frontends - sometimes your service will be called, sometimes the stats page. Changing the tcp proxy or the stats page (doc here) to another port should solve the issue.

How to force 'OpenConnect' client to use TLS 1.0

I'm using 'OpenConnect version v8.05' on Red Hat Enterprise Linux 8.1 (Ootpa) in order to connect to a server.
The server only accepts SSLv3, TLSv1.0 ciphers and I don't have access to the server for security update/upgrade.
When I try to connect:
[root#RHEL8 ~]# openconnect --authenticate XXX.XXX.XXX.XXX:443 -status -msg -debug
MTU 0 too small
POST https://XXX.XXX.XXX.XXX/
Connected to XXX.XXX.XXX.XXX:443
SSL negotiation with XXX.XXX.XXX.XXX
SSL connection failure: A packet with illegal or unsupported version was received.
Failed to open HTTPS connection to XXX.XXX.XXX.XXX
Failed to obtain WebVPN cookie
I have changed OpenSSL Min SSL Protocol by changing:
/etc/crypto-policies/back-ends/opensslcnf.config
MinProtocol = TLSv1.0
Now I'm able to handshake the server using 'openssl s_client -connect'. But the openconnect client is not yet able to connect to the server.
How can I force it to use TLS 1.0?
I have filed an issue on their community issue tracker and got useful info.
It is possible to allow this insecure connection with any version newer than 8.05(currently not available on rpm repositories) as mentioned by the maintainer:
$ ./openconnect --gnutls-priority "NONE:+VERS-SSL3.0:+VERS-TLS1.0:%NO_EXTENSIONS:%SSL3_RECORD_VERSION:+3DES-CBC:+ARCFOUR-128:+MD5:+SHA1:+COMP-ALL:+KX-ALL" ***

How to enable Saltstack ssl connection between master and minion

I try to enable ssl for Saltstack master and minion by following https://docs.saltstack.com/en/latest/ref/configuration/master.html#ssl But I am not sure how to verify it is using SSL.
I added this in master configuration:
ssl:
keyfile: /etc/salt/ssl/master/key.pem
certfile: /etc/salt/ssl/master/cert.pem
ssl_version: PROTOCOL_TLSv1_2
I added similar settings in minion. However, when I use openssl to test the port:
openssl s_client -connect <master ip>:4505 -debug and I get SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol. It seems the SSL is not enabled at all. How to verify if the SSL is enabled? The master and minion communication seems fine. I just to need to verify it is using SSL. I am on Centos 7 with python 2.7. Do I need to install any additional packages?
You also need to add
transport: tcp
Then you will at least get some SSL related error in /var/log/salt/master or /var/log/salt/minion
You can use tcpdump to capture some traffic and analyze it in wireshark to verify if the connection is ssl encrypted.

mosquitto-clients and broker running on SSL

I've managed to setup a broker using SSL using Let's Encrypt certs.
I've tried testing a websockets client connecting to wss://broker:9002/mqtt, and it's working. I've also tried using mqtt.js command-line interface to subscribe to a topic on the broker mqtts://broker:8883/mqtt successfully.
However, I can't get mosquitto_sub and mosquitto_pub to work.
I tried with,
$ mosquitto_sub -h www.my-host.com.ar -p 8883 -t hello -d --cafile fullchain.pem
Client mosqsub/21069-atlantis sending CONNECT
Error: A TLS error occurred.
where fullchain.pem is the same ca cert that's on the server.
The mosquitto.log's broker shows,
1456709201: OpenSSL Error: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca
1456709201: OpenSSL Error: error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake failure
1456709201: Socket error on client <unknown>, disconnecting.
1456709206: New connection from <my-ip> on port 8883.
What could be happening? I didn't provide any cert for mqtt.js lib...
This is my broker conf (splitted in two files),
#################################
# /etc/mosquitto/mosquitto.conf #
#################################
pid_file /var/run/mosquitto.pid
persistence true
persistence_location /var/lib/mosquitto/
log_dest file /var/log/mosquitto/mosquitto.log
listener 1883
listener 8883
cafile /etc/letsencrypt/live/www.my-host.com.ar/fullchain.pem
certfile /etc/letsencrypt/live/www.my-host.com.ar/cert.pem
keyfile /etc/letsencrypt/live/www.my-host.com.ar/privkey.pem
include_dir /etc/mosquitto/conf.d
#############################################
# /etc/mosquitto/conf.d/websockets_ssl.conf #
#############################################
listener 9002
protocol websockets
cafile /etc/letsencrypt/live/www.my-host.com.ar/fullchain.pem
certfile /etc/letsencrypt/live/www.my-host.com.ar/cert.pem
keyfile /etc/letsencrypt/live/www.my-host.com.ar/privkey.pem
Try adding "--insecure" at the end of the mosquitto_sub and mosquitto_pub commands. This allows the clients to bypass the check that matches the certificate hostname with the remote host name. I've had to do this with some of the self-signed certs that I generated.
Here is the relevant comments from the "--help" for those commands:
--insecure : do not check that the server certificate hostname matches the remote
hostname. Using this option means that you cannot be sure that the
remote host is the server you wish to connect to and so is insecure.
Do not use this option in a production environment.

Config SSL mosquitto error

I tried to config SSL for mostquitto following these steps.
When I restart mosquitto, there is an error:
1435120150: mosquitto version 1.4.2 (build date Mon, 18 May 2015 15:25:19 +0100) starting
1435120150: Config loaded from /etc/mosquitto/mosquitto.conf.
1435120150: Opening ipv4 listen socket on port 8883.
1435120150: Error: Unable to create TLS context.
This is my mosquitto config:
pid_file /var/run/mosquitto.pid
persistence true
persistence_location /var/lib/mosquitto/
log_dest file /var/log/mosquitto/mosquitto.log
include_dir /etc/mosquitto/conf.d
bind_address Dell
port 8883
cafile /etc/mosquitto/ca_certificates/ca.crt
certfile /etc/mosquitto/certs/Dell.crt
keyfile /etc/mosquitto/certs/Dell.key
tls_version tlsv1
How to configure it correctly?
Unable to create TLS context suggests that the call to SSL_CTX_new() failed. This is right at the beginning of setting up the SSL options for the listening socket and is very unexpected.
The only things you can do to influence this are to check your version of openssl, and to change/remove the tls_version option. Removing it is the best bet unless you have a particular reason to disallow TLSv1.1 or TLSv1.2 (or TLSv1.3 in the future).
Another solution ... for a [different] specific cause.
For the error "Error: Problem setting TLS options", one specific cause was fixed like this:
-- in the mosquitto config file, the lines of config parameters with cert, key, and CA filenames contained a 'space' character after each filename, and before the end-of-line character.
-- removing the space just before the end-of-line character caused the error to no longer appear.
-- the mosquitto broker then started up with no errors.
Please check client system time and ssl certificate end date, client system time must be in between ssl certificate start time and end time
Check Client System Date :
date
Check openssl certificate end date :
openssl x509 -enddate -noout -in cacert.pem