![]() ![]() My convention is to use the default config file (/etc/stunnel/nf) that ships with the stunnel4 package for the client configuration and a modified copy of that as a config (/etc/stunnel/nf, in this specific case) for the server. Now, keep in mind that if one of the nodes you have stunnel installed on is acting as both a stunnel client and stunnel server you need to have at least one stunnel server running for the client entries in a config file and one for the server entries in a config file. You don't want to troubleshoot multiple applications if something is not playing nice.Ī simple aptitude install stunnel4 on the master and slave should do the trick. If you are going to be using this for the same purposes I am ensure that you have a working MySQL master/slave setup. Our installation targets are an Ubuntu servers and will therefore be flavored accordingly but you should be able to easily adapt anything mentioned here for your platform of choice. See this Ubuntu thread for more info on rebuilding the MySQL package with SSL support if you're so inclined. I also needed a similar solution for several other applications that need secure communications channels so I've decided on this solution throughout my architecture. ![]() MySQL seems to support SSL but the package requires a rebuild with the required options which would mean I need a non-standard MySQL package which makes me itchy. In my case I needed to get a MySQL master/slave pair to replicate via a secure channel. They have a really comprehensive examples section on their site which I highly recommend you have a look at. Having Stunnel provide the encryption, requiring no changes to the daemon's code. You to secure non-SSL aware daemons and protocols (like POP, IMAP, LDAP, etc) by SSL (Secure Sockets Layer) available on both Unix and Windows. Stunnel is a program that allows you to encrypt arbitrary TCP connections inside The stunnel home page describes stunnel as: Lets explore the setup of the third option then, stunnel. ![]() OpenVPN has also provided very little stability requiring frequent restarts. SSH tunnels are very convenient but tend to be unstable requiring restarts every now and again. ![]() There may be other options but these are the main ones I have had experience with. The third seems to be the best way to transparently insert encryption into an existing architecture without requiring massive changes. The first two options have obvious drawbacks in terms of time and choice. Treat the encryption layer as an abstraction that the client/server is not aware of.Only use existing applications that support client/server encryption.Write our own software that supports client/server encryption.This has some interesting implications as most software servers do not support encryption or encrypted tunnels in any way. We have really restrictive IT policies at my current employer which dictates that no client/server communication can happen in the clear. ![]()
0 Comments
Leave a Reply. |