Is it possible to enable SSL on the MSOpenTech Redis distribution - redis

I am trying to host the MSOpenTech Redis instance securely. Looking at the base Redis Documentation I see a reference to using an SSL proxy on a linux box. Is there a windows equivalent or is the intended usage pattern to limit access via network constraints?

I was able to accomplish this using stunnel to perform the SSL offloading. I had to convert my server pfx to a pem using openssl and place it in the conf directory of the stunnel install. To keep it clean I move the port redis is listening on to 6380 so the connection topology is client ---(TLS 1.2) --> server:6379 --> Localhost:6380.
StackExchange.Redis Client Initialization
ConfigurationOptions options = new ConfigurationOptions
{
options.Ssl = true;
Password = "foobared"
};
options.EndPoints.Add("localhost:6379");
Stunnel Configuration
[redis-proxy]
sslVersion = all
options = NO_SSLv2
options = NO_SSLv3
cert = stunnel.pem
accept = 6379
connect = 6380
Openssl Command
openssl pkcs12 -in myservercert.pfx -out stunnel.pem -nodes

Related

Configuring filebeat to graylog with TLS (connection reset)

I have successfully created a graylog server (in docker container) that ingests logs from filebeat on a separate machine.
However I of course would like to have the messages encrypted. I am attempting to set this up however I cannot seem to get graylog to accept the connection, instead it is always being reset by peer:
{"log.level":"error","#timestamp":"2023-01-04T15:08:57.746+0100","log.logger":"publisher_pipeline_output","log.origin":{"file.name":"pipeline/client_worker.go","file.line":150},"message":"Failed to connect to backoff(async(tcp://<graylog_ip>:5044)): read tcp 192.168.178.99:54372-\><graylog_ip>:5044: read: connection reset by peer","service.name":"filebeat","ecs.version":"1.6.0"}
(Without tls the connection works as intended, a new line appears in graylog every time one is added to my test log file.)
Setup Details
I created a filebeat.crt and filebeat.key file with openssl. I confirmed that the hostname for the certificate was the same hostname for the server with graylog on it:
openssl genrsa -out filebeat.key 2048
openssl req -new -x509 -key filebeat.key -out filebeat.crt -days 3650
From my knowledge, a CA should not be required since I have copied the key myself, filebeat can just encrypt the data it sends with the filebeat.crt, then the server can decrypt with filebeat.key (perhaps this is not correct of me to imagine?)
I then copied both files to the server and local machine. In my compose file I mounted the key into the graylog container and restarted. Then I set up the input configuration that was working previously to have:
bind_address: 0.0.0.0
charset_name: UTF-8
no_beats_prefix: false
number_worker_threads: 12
override_source: <empty>
port: 5044
recv_buffer_size: 1048576
tcp_keepalive: false
tls_cert_file: /etc/graylog/server/filebeat.crt
tls_client_auth: disabled
tls_client_auth_cert_file: <empty>
tls_enable: true
tls_key_file: /etc/graylog/server/filebeat.key
tls_key_password: ********
Then in filebeat I have the following configuration (I also tried converting and using filebeat.pem for the certificate, but no change):
output.logstash:
hosts: ["<graylog_ip>:5044"]
ssl.certificate: '/etc/pki/tls/certs/filebeat.crt'
ssl.key: '/etc/pki/tls/private/filebeat.key'
I really cannot see the issue, any help would be greatly appreciated!
First, try to debug filebeat using
/usr/bin/filebeat -e -d '*' -c filebeat_5.1.2.conf
Probably you will discover that CA is needed or something like that.
But my best quess is that filebeat tries to verify hostname and certivicate name, your generated certificate could not have CN identical to hostname.
Proper solution is using:
ssl.verification_mode: none
Well, this solution works for me.

Python secure channel gRPC 'ssl_transport_security.cc:1807] No match found for server name' on remote instance

I have a Debian GCP instance that I'm trying to run a Python gRPC server. My instance has a static IP and I'm trying to establish a secure channel between my remote instance (server) and a local client.
I have generated self-signed OpenSSL certificates on the server and I am using the same certificates on the client. To generate I've used:
openssl req -newkey rsa:2048 -nodes -keyout ML.key -x509 -days 365 -out ML.crt
My server is set up like so (the .key and .crt files are loaded with an open as 'rb'):
server_credentials = grpc.ssl_server_credentials(((private_key, certificate_chain,),))
self.server.add_secure_port('0.0.0.0:%d' % self.port, server_credentials)
self.server.start()
My client is set up as:
host = '78.673.121.16' #this is the instance's static IP
port = 9063
certificate_chain = __load_ssl_certificate() #this loads the certificate file
# create credentials
credentials = grpc.ssl_channel_credentials(root_certificates=certificate_chain)
# create channel using ssl credentials
channel = grpc.secure_channel('{}:{}'.format(host, port), credentials)
and then I proceed to make a request.
At the server I am met with the following error, in response to my request:
E1017 17:21:22.964227087 1881 ssl_transport_security.cc:1807] No match found for server name: 78.673.121.16.
I have tried to change the Common Name (CN) of the certificate to localhost, 0.0.0.0 and 78.673.121.16 but to no avail.
Is there any suggestion?
I just had a similar problem, and was able to get it resolved finally. In my case I was hosting the server in a kubernetes cluster with a static ip and port. The key components of the solution were (in the server certificate):
Use the static IP address as the Common Name
Add the static IP address as a DNSName within the SubjectAlternativeName extension of the certificate
Step 2 turned out to be critical. In python (using grpc version 1.34.0) this was accomplished by:
from cryptography import x509
host = '78.673.121.16'
builder = x509.CertificateBuilder()
...
builder = builder.add_extension(x509.SubjectAlternativeName([x509.DNSName(host)]), critical=False)
try passing these options in secure_channel function call
options = {
'grpc.ssl_target_name_override' : 'localhost',
'grpc.default_authority': 'localhost'
}
channel = grpc.secure_channel('{}:{}'.format(host, port), credentials, options)
I have failed to find how to solve this and have opted to set up a permanent DNS for my instance instead. I was using GCP which, as of the time of writing, doesn't staightforwardly provide a way to assign this to an instance.
I switched to Azure, assigned the DNS to my instance and used that DNS and CN on my self-signed SSL certificate.
After that I changed the client (the server remains as originally) as:
host = 'myinstance.westus.azure.com' #this is the instance's DNS
port = 9063
This resolved my issue.

How to enable SSL on Apache Airflow?

I am using Airflow 1.7.0 with a LocalExecutor and documentation suggests that to enable SSL, we need to pass cert and key path and change the port to 443 as below
[webserver]
web_server_ssl_cert = <path to cert>
web_server_ssl_key = <path to key>
# Optionally, set the server to listen on the standard SSL port.
web_server_port = 443
base_url = http://<hostname or IP>:443
I have created cert and key generated using OpenSSL. The details supplied while creating the cert/key too are right.
However, the Airflow UI is still http and not https.
Any pointers would help!
Thank you!
Solved in this question How to enable SSL on Airflow Webserver? and answer https://stackoverflow.com/a/56760375/512111.
In short: generate a key, crt pair with
openssl req \
-newkey rsa:2048 -nodes -keyout domain.key \
-x509 -days 365 -out airflow.crt
and set in airflow.cfg like
web_server_ssl_cert = /path/to/airflow.crt
web_server_ssl_key = /path/to/airflow.key
Leave the webserver port unchanged. Restart the airflow webserver, go to https://hostname:port et voilà.
Airflow 1.7.0 doesn't support SSL. I just checked the webserver code of airflow 1.7.0. The code is given below. This function just starts the flask/gunicorn application on HTTP with the host and port. If you provide the certificate and mention the port as 443, it will simply start the application on http://<host>:443. It doesn't accept the SSL key and certificate. The webserver function of Airflow 1.7.0 is given below.
SSL feature is available with the latest version of the Apache Airflow. Please use the latest version for SSL support.
def webserver(args):
print(settings.HEADER)
from airflow.www.app import cached_app
app = cached_app(configuration)
workers = args.workers or configuration.get('webserver', 'workers')
if args.debug:
print(
"Starting the web server on port {0} and host {1}.".format(
args.port, args.hostname))
app.run(debug=True, port=args.port, host=args.hostname)
else:
print(
'Running the Gunicorn server with {workers} {args.workerclass}'
'workers on host {args.hostname} and port '
'{args.port}...'.format(**locals()))
sp = subprocess.Popen([
'gunicorn', '-w', str(args.workers), '-k', str(args.workerclass),
'-t', '120', '-b', args.hostname + ':' + str(args.port),
'airflow.www.app:cached_app()'])
sp.wait()
Go to AIRFLOW_HOME -> airflow.cfg. It has section named [webserver], under that there are two config properties like below:
web_server_ssl_cert =
web_server_ssl_key =
if there is no value like above means Airflow webserver is running on http (without certificate).
To enable SSL, use .p12 certificate (one you must have ordered) and use openssl to extract certificate and private key from .p12 file. openssl mostly ships with Linux so you can directly run on linux terminal.
Step1: Extract certificate using below command
openssl pkcs12 –in /path/cert.p12 -nokeys -clcerts –out /path/mycert.crt
Step2: Extract key using below command
openssl pkcs12 –in /path/cert.p12 -nocerts –out /path/mykey.key
Step3: Once certificate and key is generated, update airflow.cfg for
web_server_ssl_cert and web_server_ssl_key. Restart Airflow webserver.. are you
are done. Browse Airflow UI with https.

configuring gitlab with SSH support

I am trying to setup gitlab on my server with SSL support. I am using a different port for the gitlab as follows in my nginx settings:
external_url 'https://myserver.com:2440
nginx['redirect_http_to_https'] = true
I also setup the SSL certificates as:
nginx['ssl_client_certificate'] = '/etc/ssl/AlphaSSLroot.crt'
nginx['ssl_certificate'] = '/etc/ssl/org.crt'
nginx['ssl_certificate_key'] = '/etc/ssl/org.key'
However, when I try to connect to my gitlab installation as https://myserver.com:2440, it comes back with the server refused to connect error. If I configure using http, it works.
I wonder if there is anything else I need to do to enable SSH here. I have my main website running on an apache web server using the same SSL certificate but on a completely different port (8080). So, I think I should be able to use the certificates.
It turns out that this was because of the passphrase and I had to remove that using
openssl rsa -in www.key -out new.key
and use the new.key in nginx.

Dovecot with virtual hosts and SSL - wrong certificate?

I'm trying to set up Dovecot with multiple vhosts using SSL.
I've set up my main domain (example.de) and for my vhosts (example2.com & example3.co.uk) I'm using the local -option.
My problem:
When I connect to my server, it complains about a wrong hostname
(example3.co.uk) on my main and other domain for the certificate.
How can I make dovecot use the correct certificate for each host?
Here's my dovecot config:
listen = *
ssl = yes
protocols = imap pop3
disable_plaintext_auth = no
auth_mechanisms = plain login
mail_access_groups = vmail
default_login_user = vmail
first_valid_uid = 2222
first_valid_gid = 2222
#mail_location = maildir:~/Maildir
mail_location = maildir:/home/vmail/%d/%n
passdb {
driver = passwd-file
args = scheme=SHA1 /etc/dovecot/passwd
}
userdb {
driver = static
args = uid=2222 gid=2222 home=/home/vmail/%d/%n allow_all_users=yes
}
service auth {
unix_listener auth-client {
group = postfix
mode = 0660
user = root
}
user = root
}
service imap-login {
process_min_avail = 1
user = vmail
}
ssl_cert = </etc/pki/tls/certs/example.de.crt
ssl_key = </etc/pki/tls/private/example.de.key
local ohmygodpresents.com {
ssl_cert = </etc/pki/tls/certs/example2.com.crt
ssl_key = </etc/pki/tls/private/example2.com.key
}
local ohmygodpresents.co.uk {
ssl_cert = </etc/pki/tls/certs/example3.co.uk.crt
ssl_key = </etc/pki/tls/private/example3.co.uk.key
}
How can I make dovecot use the correct certificate for each host?
Its not Dovecot per se.
The client needs to use TLS 1.0 or above, and it needs to utilize the Server Name Indication (SNI) extension. Otherwise, Dovecot does not know which virtual server the client is attempting to connect to when the channel is being set up.
You can duplicate/test it with OpenSSL s_client. For example, a "good" connection:
openssl s_client -tls1 -starttls smtp -connect mail.example.com:587 -servername mail.example.com
In the above example, Dovecot will know to send the certificate for example.com when the SSL/TLS connection is started. Even though a STARTTLS extension is used in mail, Dovecot does not know the virtual server because the RCPT command has not yet been sent. Because the RCPT command has not been sent, Dovecot does not know the user or his/her domain.
Here's a "bad" connection. Its SSLv3, so it cannot utilize SNI (SNI is a TLS extension):
openssl s_client -ssl3 -starttls smtp -connect mail.example.com:587
Here's another "bad" connection. Its TLS 1.0, but it does not utlize SNI:
openssl s_client -tls1 -starttls smtp -connect mail.example.com:587
You can also duplicate/test/observe with Wireshark. SNI is sent in the plain text as part of the ClientHello. So you will be able to see protocols, cipher suites, extensions like SNI, and other parameters. Everything in SSL/TLS's handshake and key exchange are plain text (some hand waiving). The plain text messages are integrity checked later when the Finished messages are sent.
You can disable SSLv2/SSLv3 and force TLS, and things will work as expected for most clients. However, a client does not have to send the SNI extension. Windows XP clients will be a problem - they utilize TLS 1.0 but omit SNI. So there's really no fix other than using a modern client.
Your other option is to create a "super certificate". That is, use a certificates with all the DNS names that the mail server serves. In your case, use one certificate with SANs of DNS:3und80.de, DNS:ohmygodpresents.co.uk, DNS:example1.com, etc. Every time you add a new domain or remove an existing domain, you will have to get a new certificate.
See https://doc.dovecot.org/configuration_manual/dovecot_ssl_configuration/
it is not
local domain.com { ...
it is
local_name domain.com { ...