i have password with "Config set require pass", my app web use HTTPS. How dangerous is it not to use ssl with redis? it is required?
That totally depends on your implementation.
if it's setup in trusted private network then it's perfectly okay to not use SSL.
However if your Redis-client talk to your Redis-server over the public network then it's wise to implement a SSL encrypted connections.
You can check out this article for more read https://redislabs.com/blog/stunnel-secure-redis-ssl/
Related
In a scenario where there are thousands of webservices are there reasons to use also a signed cert for each microservice or it's just going to add overhead? Services communicate via VPC sitting behind a firewall while Public endpoints are behind a nginx public facing a valid CA cert.
Services are on multiple servers on aws.
From my limited experience, I believe that it is overkill. If an attacker has access to listen in or interact with your internal network then there are most likely other issues which you should be contending with.
This article on auth0.com explains the use of SSL only on connections to the external client. I also share this view and believe implementing SSL at an individual service level would get extremely difficult unless you where running some form of proxy such as HAProxy or Nginx on each individual host which is sub-optimal, especially if you're using a form of managed cluster like Kubernetes or Docker Swarm.
My current thoughts are its fine to run SSL just for your edge services, ensure you lock down your AWS network using something like Scout2 and run unencrypted for inter-service communication on your lan.
unless all intranet in the cloud are fully VLAN-configured and isolated, is it possible for other hosts that you don't own that are on the same LAN to steal your password by running a simple tcpdump? if that's the case, we need ssl or other encryption internally on the cloud too.
In our environment,we often reinstall our machine with the same hostname.
So,everytime I sync the configuration vai puppet,SSL authentication will fail.
How can I totally disable SSL authentication?
The assumption that connections are authenticated and identified through trusted SSL certificates runs very deep in Puppet's core. There is no way to make Puppet run through unencrypted channels only.
Things you can try:
holding on to signed certificates and getting them back onto machines just when they are re-provisioned
creating a hook that will make the master revoke the old certificate when a machine is decommissioned/recommissioned
With the latter approach, the signing of fresh certificates will be eased considerably. You might even implement an autosigning scheme, although that is tricky to do in a secure fashion.
I'm looking to configure wcf to transport data from one web server to another web server with exactly one service host and exactly one client.
Is there a simple security configuration available that does not require x509 certificates?
Additional info:
I may be looking for a simple configuration (message is okay) that could use a predetermined username / pw / enc, etc. I'd also like to avoid sending a password in cleartext.
If by "simple security configuration" you mean encrypting the transmissions between the end points, there's no simple, easy way without using x509 certificates, short of creating some kind of elaborate VPN connection point to point.
But using certificates with WCF doesn't have to be painful or expensive. Using message-level encryption (xml based) is easy enough to configure and get running, and since the communication is always between points "A" and "B", the obvious problems associate with using message encryption (distributing the certificates) isn't a problem at all.
The steps would be:
-Generate a self-signed x509 cert with public and private keys and copy to both servers
-Configure your clients and host to use message security
-install certs on both servers (plenty of documentation available, like this one)
-Configure your host and clients to find the certificates during startup
-run and test
After you've got everything running, you'd obviously replace your self-signed cert with a commercial version.
You didn't mention your platform. Are you on Windows? If so, you can use Windows credentials with message-level encryption and no need for certificates. Here is a step by step guide on how to do it.. Hope this helps!
We are setting up replication between RavenDB instances running in server mode. The instances are in different availability zones so we need a secure connection between the servers. According this this post SSL is not supported in server mode but
should be easy to add
Is there an extensibility point in the API where SSL support can be plugged in?
The API doesn't have any place for this currently, but I'm sure it would be a welcome contribution if you were so inclined to write this and submit a pull request. The underlying server is just a System.Net.HttpListener, which can be wired for ssl.
Your entry point would be at Raven.Database.Server.HttpServer.StartListening()
You would want the SSL certificate to be as easy to configure as the hostname or port. The cert itself should probably be pulled in from the Windows certificate store.
All,
It is possible to use IIS (or similar) to handle the ssl side of https communications. Is there something similar that can handle the ssl side of a TCP/IP message?
Basically I have a client device sending a non-http message over a TCP connection and want a server that can handle the crypto and certificate side of SSL for me and forward the plain text on to another server.
The openSSL s_server command seems correct but the documentation states "It's intended for testing purposes only" while I need something robust. Is the documentation out of date?
Thanks,
Patrick
You are after the stunnel program:
Stunnel is a program that allows you to encrypt arbitrary TCP connections inside SSL (Secure Sockets Layer) available on both Unix and Windows. Stunnel can allow you to secure non-SSL aware daemons and protocols (like POP, IMAP, LDAP, etc) by having Stunnel provide the encryption, requiring no changes to the daemon's code.
I don't think the documentation is out of date. "For testing purposes only" is their release from liability.
It sounds like you want an SSL tunnel. You could setup a tunnel to the SSL server, send the packets through the tunnel, and then have that server forward the result on. There are lots of tutorials on using SSH to setup tunnels over SSL.