Slashdot Mirror
Implementing an SSL-Based Network?
A Nominal Coward asks: "I've been doing some research into making my communications more secure, everything from email to news, from IRC to www. Most of the information I've found repeats one suggestion, 'tunnel your connections over SSL.' Yet while everyone claims this is the best thing to do, no one seems to explain how. I haven't been able to find a faq, howto, or demonstration of how to set this up properly; just lots of people saying 'SSL is good.' What am I missing? I've downloaded and installed stunnel, a free (speech & beer) SSL tunneling proxy, but - don't laugh - now what? All I've managed to do is make an SSL connection to an IRC server a friend set up specifically for that purpose. Where do I go from here in order to secure my other connections, like mail, news, and web? Do I have to subscribe with providers who explicitly provide SSL access, if so, which are recommended? I would appreciate advice from others who have managed to get this working."
Yes, as with every other protocol/combination of protocols (HTTP over TCP overIP), both ends of your many communications will need to speak the same way.
For mail, some providers offer pops (that is, secure POP3), but you'll have to ask around to know which ones do. Another way to go is Web mail: those packages usually allow https connections. But don't forget that with both these tools, your mail is only secure between you and your ISP: the SMTP protocol your provider's server use to deliver it to other servers is not encrypted. If you really want one end to the other secure mail (as in: nobody will be able to read it unless they are the intended receiver or they're the NSA or CIA), then use PGP, GPG or any other good mail encryption package. Then it'll reach your recipient in a unreadable format. But all your recipients must have a public key, else you won't be able to encrypt it in the first place (so for helpdesks, mailing-lists, etc. it won't work).
For news, www, etc., do you intend to encrypt what you receive (content)? What you receive (URL)? What you send (even if it ends up on a public nntp server)? For some of those, it won't work because you'd want every connection to be encrypted, period. Normal web servers essentially serving "free" info don't need that, and there's some overhead if you encrypt everything. So it won't be put in practice.
Usually people use stunnel for, eg, remote X sessions, where you don't want other people to spy what you're doing. A couple apps also use ssh to do the same (cvs). But in each case, both ends of the communication must be properly set up to communicate through an encrypted layer.
IPsec (as mentionned in another post) is also good, but as soon as your packets leave the other IPsec end (as in, leave the corporate firewall), your communication will again be very plain to read.