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."

31 comments

  1. fp by Anonymous Coward · · Score: 0

    fp

    1. Re:fp by Anonymous Coward · · Score: 0

      at 9am on a saturday! you're an animal!

  2. Why SSL? by Anonymous Coward · · Score: 1, Informative

    Do the right thing and use IPSec. It encrypts all traffic, not just selected ports, and it will be included in IPv6. SSL might be your only option for communication with external servers and especially POP3 over SSL is very common, but for using services on a friend's system (who I suppose is open to suggestions), IPSec is a better choice.

  3. Yes, you need something at both ends by Papineau · · Score: 5, Insightful

    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.

    1. Re:Yes, you need something at both ends by Anonymous Coward · · Score: 0

      IPSec and SSL tunnels should be used end to end. Both can be used in different configurations and IPSec often is because it's so convenient to have a "security gateway", but that doesn't mean you can't use it the properly.

  4. It's tricky, and time consuming by mfos.org · · Score: 2

    coming from some one who has done this, this can be a pain in the ass. Especially if you want to do it for multiple services. My suggestion would be, if you can't narrow it down to only 2 or 3 services, that you use a VPN.

  5. confusing your apples and oranges by coyote-san · · Score: 4, Insightful

    Your question, and the answers, have confused apples and oranges. They look similar (round, fruit), but there are some key differences.

    Specifically, you could use a tunnel (stunnel, ssh), or you can use applications that directly support SSL. Setting up the applications takes a bit of research since it hasn't been standardized yet, but it's not too hard once you figure out where the documentation has been hidden. (Sometimes in the source code. *grrr*.) Setting up a tunnel is probably a bit easier, but it requires that the server explicitly provide a tunnel.

    The benefits of a tunnel is that it provides a "one size fits all" solution - if you can do it for one application, you can do it for others. More importantly, you can use it with applications that don't yet support SSL directly.

    The benefits of direct SSL support is that the clients can almost always verify the identity of the server (it is possible to set up a server so it doesn't require an X.509 certificate, but it's much more common for the server to require one). Optionally, the server can require that clients provide a certificate to identify themselves.

    If you control the server, the choice may come down to authentication and identity. If you don't care who connects, or who they connect to, e.g., because you'll be using (username,password) to log in, you should probably go with a tunnel. If you need to establish identity, or want to use a "login-less" mechanism, you should probably go with direct SSL and possibly require client certs.

    --
    For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
    1. Re:confusing your apples and oranges by PacoTaco · · Score: 1
      The benefits of direct SSL support is that the clients can almost always verify the identity of the server (it is possible to set up a server so it doesn't require an X.509 certificate, but it's much more common for the server to require one). Optionally, the server can require that clients provide a certificate to identify themselves.

      Visit here or man openssl for more information on creating and managing certificates.

  6. better solution by larry+bagina · · Score: 0, Troll

    It would be easier and more secure if you just used Windows 2k's built-in VPN.

    --
    Do you even lift?

    These aren't the 'roids you're looking for.

  7. Yeah, here's an idea. by SuiteSisterMary · · Score: 3, Interesting

    Don't do it. Tunnelling is bad. Period. You want a secure network? Use IPSEC or something similar, and encrypt your traffic.

    --
    Vintage computer games and RPG books available. Email me if you're interested.
    1. Re:Yeah, here's an idea. by Anonymous Coward · · Score: 0

      Just out of curiousity, could you expand? Why do you consider tunnelling bad? Is it the bandwidth loss due to protocol overhead or something else?
      IPSEC is great, but consider the fact that unless the other end is taking similar measures, you are (AFAIK) not gaining anything. (Of ironic interest is that not having both ends in sync is a weakness of tunnelling as well. It takes two to tango...)

    2. Re:Yeah, here's an idea. by SuiteSisterMary · · Score: 3, Insightful
      Just out of curiousity, could you expand? Why do you consider tunnelling bad? Is it the bandwidth loss due to protocol overhead or something else? IPSEC is great, but consider the fact that unless the other end is taking similar measures, you are (AFAIK) not gaining anything. (Of ironic interest is that not having both ends in sync is a weakness of tunnelling as well. It takes two to tango...)
      Doing anything 'out of spec' is going to have the same problems. And most of the basic Internet protocols were built to be open text. If you're going from site to site, use a VPN. If you have no control over the other site, then you're going to wind up sending plain text, most likely. And tunnelling is bad from an admin perspective, as it adds unneeded overhead and what not, as well as making it more difficult to identify what's going on.
      --
      Vintage computer games and RPG books available. Email me if you're interested.
    3. Re:Yeah, here's an idea. by noahm · · Score: 3, Insightful
      Just out of curiousity, could you expand? Why do you consider tunnelling bad? Is it the bandwidth loss due to protocol overhead or something else?

      A talk was given at the USENIX conference last week in California in which the throughput performance of SSL/TLS was compared to that of IPsec. IPsec won easily in all cases.

      Personally, I prefer IPsec since it can be used to encrypt and authenticate all IP layer traffic. If you're tunneling services over SSL, you're still leaking information to an eavesdropper (i.e. "I know you transferred 200 kB of mail via your tunneled pop3 connection"). With IPsec, it becomes difficult to differentiate between higher level protocols. UDP over IPsec doesn't look any different than TCP.

      IPsec is also nice because it's starting to gain widespread industry acceptance. Setting it up on the free Unixes is very easy. Windows 2000 and XP come with it as a standard feature. I don't know if MacOS X 10.1 comes with it, but the forthcoming 10.2 release (Jaguar) includes it.

      noah

    4. Re:Yeah, here's an idea. by psychosis · · Score: 2

      Cool, thanks! I understand the aversion from an admin perspective (it's my day job...). After looking at your homepage and documents, I knew your original message wasn't a troll, but I was curious about why exactly you took such a strong viewpoint.
      I agree that a VPN is the right answer for site-to-site links, but I think that for small-time folks, tunnelling could be a useful tool, provided the implementation correctly re-assembles the packets on the other end. Wide scale usage? Hell no.
      Thanks for the clarification (and to the person below your post who replied as well...)

    5. Re:Yeah, here's an idea. by SuiteSisterMary · · Score: 2

      The problem with implementing a 'small scale' version is that it's often later turned into the 'wide scale' version. With the expected disasterous results.

      --
      Vintage computer games and RPG books available. Email me if you're interested.
    6. Re:Yeah, here's an idea. by einhverfr · · Score: 2

      Out of curiosity-- why is it that you would not tunnel your connections but you would use IPSec?

      Most networks which use IPSec as a VPN solution use dedicated IPSec/LLTP tunnels, and this technique is actually recommended by the National Security Agency (see their guide to implimenting a secure Windows 2000 network architecture).

      IPSec is implimented (as its name implies) at the IP level, so the machines on both sides of the tunnel need to support it. But beyond, that, it is transparent to the ends of the connection, so the applications need not be configured specially to support it. Again, usually, the way that this works is that a computer sends encrypted information to an IPSec gateway which then unencrypts it and sends it its destination. However, it should be noted that when IP v6 becomes more common, the strategy will probably shift away from tunnelling.

      --

      LedgerSMB: Open source Accounting/ERP
    7. Re:Yeah, here's an idea. by SuiteSisterMary · · Score: 2

      Mainly because, as you say, IPSEC is, at least, something of a standard, and is much more transparent. Less ad hoc, perhaps, is the phrase I'm looking for. But I prefer something that will encrypt the traffic in a 'blanket' fashion, and completely unbeknownest to the application itself. Perhaps we're using different terminology here, or perhaps I misunderstood the original post. There's a difference between 'creating an encrypted 'tunnel' across an unsecure network' and 'tunnelling a protocol through another.' SOAP is 'tunneled' through HTTP over port 80, and that sucks ass. Building a VPN 'tunnel' across the Internet, using IPSec, L2PP, or something else, is great, because it doesn't affect the original data, other than to encrypt it. The applications don't need to know what's happening, or why. Things aren't going out to nonstandard sockets/ports/whatever.

      --
      Vintage computer games and RPG books available. Email me if you're interested.
  8. Small doc on using stunnel to proxy your own http by ptudor · · Score: 3, Interesting

    This might help a bit if you're already looking toward stunnel but are unsure of how everything links together.

    http://www.ptudor.net/~ptudor/stun-proxy.html

  9. $ man ssh by pete-classic · · Score: 0, Redundant

    SSH(1) System General Commands Manual SSH(1)

    NAME
    ssh - OpenSSH SSH client (remote login program)

    SYNOPSIS
    ssh [-l login_name] hostname | user@hostname [command]

    [snip]

    -L port:host:hostport
    Specifies that the given port on the local (client) host is to be forwarded to the given host and port on the remote side. This works by allocating a socket to listen to port on the local side, and whenever a connection is made to this port, the connection is forwarded over the secure channel, and a connection is made to host port hostport from the remote machine. Port forwardings can also be specified in the configuration file. Only root can for ward privileged ports. IPv6 addresses can be specified with an alternative syntax: port/host/hostport

    -R port:host:hostport
    Specifies that the given port on the remote (server) host is to be forwarded to the given host and port on the local side. This works by allocating a socket to listen to port on the remote side, and whenever a connection is made to this port, the connection is forwarded over the secure channel, and a connection is made to host port hostport from the local machine. Port forwardings can also be specified in the configuration file. Privileged ports can be forwarded only when logging in as root on the remote machine. IPv6 addresses can be specified with an alternative syntax: port/host/hostport



    Holy crap, how did this question make it to Ask Slashdot?

    -Peter
  10. Building Linux VPNs book may help by Helevius · · Score: 3, Informative
    You will find a useful comparison of Linux-based options in Building Linux VPNs by Oleg Kolesnikov and Brian Hatch.

    They include SSH, SSL, IPSec, and other approaches, and don't waste time explaining TCP/IP.

    Helevius

  11. Sorry, no cigar, Ballmer by gd23ka · · Score: 1

    There's this saying that goes like "I would rather have a sister in the whorehouse than a brother on a Honda." I guess you catch my drift, Ballmer, especially when it's YOU talking about security.

  12. If you have shell access to the host, use ssh by scm · · Score: 1

    ssh -X will forward X11 connections. You can also forward ports over the ssh connection:

    ssh -L 143:server:143 -L 25:server:25 user@server

    Then you can set your mail client to use localhost as the server and everything goes through the tunnel (143 is IMAP, 25 is SMTP). Note you have to run the above example as root, since it forwards remote ports to local privleged ports (<1024). If you don't want to do it as root, forward to local ports &gt 1024. This isn't the perfect solution in most cases, but it offers one option.

  13. privacy by flok · · Score: 2, Interesting

    If you want privacy when surfing, take a look at Cloudish; it's a distributed anonymizer using SSL connections.

    Small detail; you need others to setup a cloud/crowd of cloudish-proxies.

    --

    www.vanheusden.com - home of Multitail, HTTPing, CoffeeSaint, EntropyBroker, rsstail, bsod, listener, nagcon, nagi
  14. Not the whole story... by /Idiot\ · · Score: 1

    IPSEC around the LAN is half the story, and a very valuable part at that, but what about when your traffic escapes to a public network?

    Thats when you need a tunnel. And yes, you can use IPSEC for this too (smoothwall linux does not come with local IPSEC out of the box, but creating an IPSEC tunnel using FreeSWAN in smoothie is like falling off a log)

    --
    /dev/Idiot/
    1. Re:Not the whole story... by SuiteSisterMary · · Score: 2

      As I said in a different post, if it needs to be encrypted, it cannot escape to a public network. You need VPNs and the like at that point. Or a WAN. The problem is that there's so many bloody ways to tunnel; some built into the protocol, some built into the server, some built into the firewall, some built into the routers, some added on by third party apps, it's a horrible horrible mess. Ideally, the various 'core' protocols of TCP/IP would include provisions for encryption. And using SSL-like technology for this is fine; TLS for example.

      --
      Vintage computer games and RPG books available. Email me if you're interested.
  15. PPP over SSL by TheLink · · Score: 3, Interesting

    You can do PPP over SSL too.

    The popular opinion would be that you might be better off using IPSEC.

    However to my unenlightened eyes IPSEC seems more complicated than SSL and so more likely to have security problems. E.g. like SSH- complex, and thus many security problems.

    That said, if you want encryption from every point to every point then go for IPSEC.

    IPSEC performance should be better than PPP over SSL.

    Unfortunately, whilst SSL just requires a TCP connection, IPSEC needs UDP.

    Cheerio,
    Link.

    --
  16. Depending on your requirements... by osolemirnix · · Score: 2

    While I agree completely that IPsec is the best way to go if you have admin access to both machines, consider an example where I just want to FTP some data to my server from a foreign machine (like from a clients site).
    I certainly don't have the option of using IPsec in this case, but downloading an sftp-capable client to connect to ftp via stunnel is possible.

    As always, ymmv, depends on what you want to do.

    --

    Idempotent operation: Like MS software, wether you run it once or often, that doesn't make it any better.
  17. Yes, use a VPN. Maybe not IPSEC by kwerle · · Score: 3, Funny

    I always found IPSEC to be FAR more trouble than it was worth. I use VTUN, with seems to be much easier.

    Also, I hear OpenVPN is good.

  18. Stunnel, SSH, etc... by percey · · Score: 2, Insightful

    I've done similar research and here's what I've discovered.
    IPSec is usually used for connect LAN's across the internet because it can encrypt all traffic. The one puzzling thing I've found about IPSec is that once its run, it takes over the the IP, that is you can't run regular IP and IPSec at the same time. This part confused me, as it seemed to indicate that I can't run an open HTTP server on port 80 with accessability to the outside world. Now, I'm sure there's a way around this, I just wasn't able to find it before I realized that stunnel would fit my needs.
    Stunnel (found here) is able to encrypt (using SSL) and network connection, so lets say you want to use it to secure POP email, you can use the POPS port(which escapes me now) and have STUNNEL sit there and redirect connections to the POP port, then you can turn off outside access to POP through your firewall, and low and behold you have POPS accessable to major e-mail clients without needing the functionality built into the e-mail server. You can do this with anything, and yes the same thing can be accomplished with SSH, but the one thing is that you need to log into SSH first, because it tunnels all traffic through port 22. Now this can be a good thing too, you can close all the ports except for port 22, and require everyone who wants access to your system to log in using a private key. The configuration is a pain because you'll have to configure each users Putty or other client to forward the connections. Its best use, I think is for tunneling windows clients like PCAnywhere throughout your enterprise and passed the firewall. As for News? I've never heard of NNTPS, but I wouldn't be surprised if its the the same. For web, that's simple, just go get yourself a certificate and follow the openssl instructions. You can even sign your own if you don't want to spend on a Verisign one.

    1. Re:Stunnel, SSH, etc... by clutch110 · · Score: 1

      I am an avid FreeSWAN user, and I can say that IPSec doesn't block regular IP traffic.

      When using IPSec you route target networks, which can be class As all the way down to a single host (x.x.x.x/32).

      All traffic between me and certain other LANs are encrypted via IPSec, but yet I still run a web, mail and imap server that are accessible to the general Internet population.