Request for Comments on a recent design choice... Problem ======= mongo doesn't support encryption of data natively. In addition it's replication configuration is fairly rigid with regard to requiring FQDNs and ports. These constraints present a challenge to ensure we continue to support encryption of data between servers. The issue with FQDNs makes a traditional stunnel configuration problematic. To give you an example, for two mongo servers on machines killdeer.hubler.us, and greebe.hubler.us both listening on port 27017 respectively, *each* of the servers have to be configured *identically* with server list 1: killdeer.hubler.us:27017 2: greebe.hubler.us:27017 So you *cannot* configure the server list on killdeer with 1: killdeer.hubler.us:27017 2: localhost:27019 where port 27019 is stunnel port to greebe. Using /etc/hosts with fake host names together with juxtapositioning the ports was considered but considered only as a Plan B if a simpler method could not be found.
Solution ======= So I am proceeding down the path of using stunnel AND iptables together to transparently encrypt traffic between hosts. This means iptables routes traffic out the specified external network interface destined for a particular ip address and port to the local interface and a different port. This local port goes to an stunnel service used to receive the traffic and deliver to another stunnel service on the remote machine that can deliver the traffic to it's final destination. Meanwhile the application does not know the difference (i.e. it's transparent). Benefits ======= * Encryption is optional if your network requires it. This in turn means - save CPU when it's not needed - simplify config when it's not needed - admin can enable/disable to debug issues * Local traffic is not encrypted to save performance/assist in debugging * Consolidation of authentication mechanisms - more secure from an security audit perspective - easier to development because services can rely on underlying encryption for data integrity and firewall for authorization support. Details ======== This does not affect APIs exposed outside the cluster. Those will continue to use certificates (or not) as they've always had. Having said this, there is a generic apache config setup now for services to proxy their service thru apache. This would leverage apache ssl config in addition to simplifying firewall setup. _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/
