Slashdot Mirror

Also you can use HTTPTunnel on any PHP enabled server (with almost no other requirements) and connect to it with the multiplatform Perl client to open a local SOCKS server (there are other projects named like this one, but this is the only one that really works). The client supports HTTP proxies and the request are normal HTTP GETs/PUTs (not CONNECTs). The project is not being updated since 2010, but it just works (even tho the SSL part has problems, but you can just configure the PHP folder on an HTTPS web server and use stunnel in front of the client).

Then under Windows many programs do not support the SOCKS protocol to connect to the client (I'm looking at you, Remote Desktop), but you can just run ProxyCap to transparently redirect single programs (or all of them) through any proxy. There are free (as in beer, mostly) alternatives to ProxyCap, but they are either not updated (i.e., they don't work on 64-bit systems) or they are likely to deeply mess up the windows network driver configuration when you remove them (or both).

I echo my sibling's comment in that I have no problem at all with the website's style - I'd far rather have a simplistic straightforward HTML-driven site than some stupid Javascript-redirect-driven graphic-design student project. This is really important for security-related software distribution sites where it's necessary to be absolutely sure where your downloads are coming from.

The site does however have some problems with organisation of content - e.g. it'd be nice if they followed some more de-facto site-structure conventions like having a "Downloads" link to a page which provides the source tarballs, and states explicitly that there are no binaries available ... and maybe even provides links to the more common Linux distro repositories where binaries may be found, even places where (gasp) Windows binaries can be found .... like http://www.stunnel.org/download/binaries.html (the place I always used to go to get my Windows OpenSSL binaries, but which seems a little unmaintained these days) .... or http://www.slproweb.com/products/Win32OpenSSL.html (which is a lot more up to date, and professionally organised).

There is an openssl.org page with info about Win32 binaries :
http://www.openssl.org/related/binaries.html
(which links to the www.slproweb.com site) but it's not easy to find (IMHO).

And then there's the awful documentation, as many others have mentioned. I'd offer to help out with that if I was half-way crypto-competent enough to do so.

But the site's retro style is fine ... the use of colours is restful on the eyes, and avoids use of the stupid 2-point flyspec fonts so beloved of those whose eyes are much younger than mine and who aren't worrying about damaging them :)

And stunnel which makes non-SSL apps into SSL capable apps.

Instead of re-writing every protocol to look like IPSEC, couldn't we add a layer to the network stack between the transport layer and the IP layer to encrypt the IP payload? Then we wouldn't have to re-write all our old apps, wouldn't need to implement encryption in every app, and wouldn't need to try to hide the port numbers. If only there were such an IP-layer SECurity service...

Oh, but you can. Or do you want to tell me that the firewall's blocking all authenticating websites? I documented the solution I am using, never stating it's the only one. As for teh pr0n surfing, well, seems like you have a problem that goes above and beyond network security and into human resources land. I mean seriously, who would have thought you can staff a company almost exclusively with wankers? Good luck in your chosen profession.

You might also look into stunnel. It acts more like a traditional daemon with conf file, and also has the neat feature of being able to turn any service into its standard ssl equivilent, if that exists, which is useful for things like imap/pop/http.

SSH everything, pgp any and all email. If you're looking to stop anyone from seeing what sites you're visiting, I suppose you could try using some kind of local / remote proxy tunneled through SSH. Set up a box at your home to tunnel all http / https requests to a remote box in a secure (non-monitored) location. There are plenty of ISP's in the USA that do not monitor anything.

If you wanted to disguise everything, simply set up an encrypted tunnel to one of the aforementioned friends, and pipe PPP through it, and use that as your gateway. Might be a good bit slow(er) than using local access, but if it saves you from political opression... Google for ssl tunnel, and the first link listed is http://www.stunnel.org/

Don't forget the obligatory tin foil hats.

If you are paranoid about security, run the ircd in a chroot jail.

Although the clients do not have built in support for encryption, according to the manual you can run the clients through stunnel to encrypt the traffic between the clients and the backup server. Future versions are supposed to support encryption built into the client.

Just use stunnel with the proxy patch. Faster and harder to detect.

Just use stunnel with the proxy patch. Faster and harder to detect.

• Loop-back encryption is kinda clunky. dm-crypt looks to be a cleaner way to do encrypted devices. And pam_mount can mount encrypted home directories on login.
• As for doing encryption in the filsystem, several people are at working at it.
• Your notion that OpenSSH only creates a tunnel while the "console" is open, is little more than FUD. Oh no! The console!. That's the whole point. SSH is largely interactive by its very nature.
• It's quite easy to setup OpenSSL in inetd mode for SSL'd services.
• Encrypted executables? Are you joking? WTF would that achieve? If someone has physical access to your machine, you're screwed anyway. And if someone has broken into your machine remotely then your executables are probably the last thing to worry about. On Unix/Linux systems you need root access to write to system executables. If an intruder has root access, they can do anything and don't need to modify your executable to screw around. This is a straw-man argument.
• Linux is very good as a VPN router. Not only do we have IPsec/IPV6 from the KAME project, there's also the (abandoned) FreeS/WAN project and the spin-off Openswan. But don't forget OpenVPN (available for quite a few platforms, not just Unix/Linux). If you're really desperate, you can always combine SSH and PPP to make a VPN.
• Tokens? You have heard of Kerberos haven't you?
  BTW, here's a good LDAPv3+SASL+KerberosV HowTo

My god you are a troll. Oh, and as others have pointed out, encryption does not instantly make something secure.

You can also use a wrapper program like Stunnel if you don't want to ditch your existing software. Stunnel allows you to use SSL with almost anything, including proprietary apps. I've used it with POP servers and it works reliably.

That's what stunnel is for.

Do you really need a VPN ?
My company sells >flame-proof-suit<an expensive Windows-only 5250 terminal emulator >/flame-proof-suit< with built-in support for SSL.
Install stunnel at the AS400 site.

...for the common man like STunnel, FreeSWAN, or OpenVPN, how long can it be before people are just using private networks between family and friends at home to do IM, P2P or even Windows File Sharing? I've moved in this direction already with my family and friends. All it took was a little of my time to set up SSH clients with Local and Remote forwards that my family and friends initiate connection to my server with. Then they just access the Jabber server I run or, the internal mail server using IMAP, or the recipe database I've created, etc... Since some of my friends and family are Windows bound, I've been able to get them to use the Exodus client for Jabber with cygwin SSH to communicate with me. We even share RDP and VNC sessions. So... what does this have to do with the article? I would argue that there are a good number of people out there doing more than just IM, P2P or web browsing and they are probably doing it via tunneling. It can't be long before this becomes a part of the OS (even for Windows) to allow people to share data in new and very secure/private ways. It's done wonders for the support I offer my friends and family too...

Try stunnel. This will let you access https sites without http by tunneling it to a local (non-encrypted) port.

You can do this for other services as well.

Pick up a copy of stunnel for both machines, set up an ssl tunnel for the control port (21), and let the data channel be unencrypted. Then you don't have to worry about entering a password twice (SSH tunnels require once for ssh and once for ftp).

I think it just works (in a similar fashion to the way ssh tunnels for ftp just work). But as I've not tried it, I don't know for certain.

Stunnel lets you do exactly this for almost any socket communications.

Sneaky is to have a wrapper script that invokes PPPD over stunnel, with x.509 PEM certs to mutually authenticate the 'left' and 'right' sides of the communication.

In the past, I have set this up to answer on port 443, via xinetd. You can guess just how useful that has proven at some times, in some locations! ;-)

Traffic analyzers and HTTP proxies see this as HTTPS traffic... Something you can't say for SSH listening on a funny port.

The story has a happy (open source) ending in that we were able to put stunnel in front of our application to provide SSL tunnelling. But it gave me a few panic attacks in the meantime.

Stunnel is quite cool for tunneling most types of traffic. Easy to implement and maintain

Rus

SSH will only carry TCP traffic. If you need to encrypt anything involving UDP or ICMP (or anything else for that matter), you cannot use SSH to get the job done, except by adding on more clunkiness in the form of things that will encapsulate connectionless protocols within TCP sessions. At that point, you're no longer reaping the benefits of simplicity that come from using something like stunnel, and it's better to bite the bullet and become adept with VPNs (check out FreeS/WAN). On the upside, once you have VPN expertise in hand, you open up a new world of options for other things as well.

Unfortunately some web development clients only understand FTP and can't use sftp.

I assume you're referring to applications such as Dreamweaver/Frontpage/Composer. True, these apps can't use FTP, but there's an easy workaround which we've suggested to our users. Check out stunnel. Works great, and it's GPL'd. Yay!

I've written up step-by-step instructions and scripts that will do the whole durned thing, no brain required, that are in Building Linux VPNs, but was unable to convince NewRiders that one of these chapters should be the one put online. (Instead they picked chapter 1 which, while fine, doesn't provide any instantly-usable information for someone trying to actually build a VPN.

There are a few examples on stunnel.org for setting one up with Stunnel (3.x). You may also want to learn how to correctly use and restrict passwordelss SSH ability here including using authprogs to restrict commands. (You do use command="",no-port-forwarding,no-x11-forwarding,no -agent-forwarding,from="" in all your .ssh/authorized_keys don't you? )

Eventually, the TCP over TCP factor will kick in, and your VPN will be slow. But with a simple ping timer, you can kill/restart connections pretty painlessly via cron.

Plus, no kernel recompilation is required.

Your idea of "white noise" is one that I've been using for a long time, under the presumption that if they're monitoring all my packets, the more packets I send the less capable they'll be of archiving and decoding each one. Here are some suggestions - and this is for anyone, not just you.

1. Run a Peer2Peer filesharing application at all times. I have a LAN sitting behind a cable modem. One of my machines, which doesn't normally do much, runs BearShare 24/7/365 unless there's a power outage. This means that at all times, there are packets containing god-knows-what streaming in and out of my connection from random hosts on random ports. I don't share any files, nor do I download them. Running P2P is simply a method of generating background noise on my connection.

2. Some time ago I wrote a little web spider in Perl. Basically it acts like a super-recursive wget. I point it at a starting URL, and it walks links - sleeping 1 second between fetches - until it can't find anymore. At present, it's been running since my last reboot (48 days ago) and hasn't run out of links yet. This creates a ton of backchannel traffic to remote hosts on port 80, so realistically anyone watching my connection can't tell whether I'm actually browsing a site or whether it's something the spider found. There are so many random webpages being fetched by the spider at all hours, it would be next to impossible to prove that I physically browsed to an "unapproved by the Bush Reich" site.

3. If you IRC, only IRC on servers which support SSL connections. irc.distributed.net, for example, lets you connect securely (through stunnel) to port 443. You're allowed to create your own channel there for your own use. Encourage your IRC buddies to dump undernet or whatever and meet up on irc.distributed.net. Their traffic might not be encrypted, but who cares. Yours is, and it's constantly generating whitenoise, useless, SSL-ized packets for the spooks to sniff at.

4. Regardless of whether you IRC or not, install an eggdrop (or 5) and point it/them towards a heavily-trafficked channel(s) on one of the major IRC nets. eggdrop runs nicely in the background, doing jack unless you tell it otherwise, but because it's connected, it will receive all the chatter that comes from the monitored channel. Yet more background traffic "the man" has to filter out if they want to find the good nugs.

5. It's easy to write a perl script to send packets containing random garbage to random hosts at random ports. Randomizing the ports, here, is key; as if the spooks are looking for something particular (or trying to filter out something particular) port numbers is where they'll start.

Have phun. Jam Echelon! :)

Yes, just like what Verisign would want: $100/year from anybody who wants to send or receive mail. Thanks, but I'll stick with unauthenticated mail and spam.

If that's the sort of thing you want, you can already run SMTP over SSL--you don't need a new protocol for that. Operating systems terminally incapable of building services out of modular building blocks can hard-code SSL into their mail servers. Reasonable operating systems can use something like stunnel for wrapping SMTP. Either way, you get authentication. There doesn't even need to be any complex interaction between the SSL authentication and the SMTP server because SSL can simply verify the identity of the connecting host, and SMTP can continue to use its regular host-based identification.

The other important requirement, according to Yu, is a system for tracking resource usage per sender. Basically this means that profiles should be established for normal amounts of mail sending from different types of users. If you limited normal users to 100 messages per second and major companies to 10,000 messages a second it would be hard for legitimate users to complain, but spamming would be much harder.

We don't need a new protocol for this. Per-user throttling of outgoing SMTP connections could be implemented by ISPs at the TCP level, and per-user throttling of incoming SMTP connections can be implemented by the SMTP server. The reason why this isn't done is because it's largely ineffective: many spammers are beyond such controls for outgoing connections anyway, and limits on incoming connections can be circumvented simply by posing as hundreds of different users.

Solutions to the spam problem are things like CAPTCHAs, intelligent text analysis, and communications pattern analysis. Restrictions on who can send what to whom at the ISP level, or the imposition of authentication fees by ISPs or companies like Verisign, however, are thinly disguised attempts at squeezing money out of users. In addition to being ineffective and increasing the cost of E-mail, they also just threaten the openness of the Internet that has made it so successful in the first place.

Is it to hard to embed "ssl tunnel" into a pice of software? www.stunnel.org is opensource, just needs YOU to embed it :)

and start encrypting the packets....

the ISP's can't block/filter packets they can't understand (descramble, decode... etc etc).


PS - And don't say your brand new snazy 1+ Ghz computer will not cope! :)

While the answer should be clear, it doesn't seem to be.

Kerberos would complement what we are doing here quite well and will likely be the next part to the puzzle that is our network. It wouldn't necessarily replace everything else.

One problem is the database on a Tru64 box. It is maintained by the software vendor that doesn't support deviations from the normal way they do things. They are more concerned about things that aren't security related and security isn't even close to what it should be. The clients connect to it using telnet protocol (real secure there) using a proprietary client. Perhaps we can use stunnel or some other method of tunneling, etc. to externally secure the traffic but that might take more time and money than they are willing to provide.

The MIS dept tries to work around these issues with management of switches, routers, etc. and access lists and other methods to try to limit the issues. Yes the MAC addresses could be worked around but it is a step in the right direction. I appreciate the input, keep it coming.

Clearly defining the goal of the project is important. Take cURL for example. It is made to snag URLs and shoot the results to STDOUT. It has all the options you could need to support authentication, posting, etc. In fact, the majority of the code is in the library, not the command line utility itself.

Now folks say "Hey, let's make it a GUI application!" but the current maintainers say no, it's a library and a command line tool. However they've been saying that from day one. They clearly define what it is and isn't. It is not a wget replacement, and they don't want it to be. Folks will understand when there is consistency in the answers.

I myself briefly maintained Stunnel (stunnel.org) because the author was offline for six months and there were security issues that needed to be addressed. I didn't want it to be a fork, because I wanted to hand ownership back to the original author once he returned, and that's exactly what happened. He'd done a great job incorporating things that most folks needed.

That said, many people had visions beyond what Mike was willing to incorporate into the official version. Instead of dropping those patches on the floor, I've made them available at the website, so folks can apply them if desired. Thus there is still one consistant main version, but no problems if folks want different versions - just apply the patches.

You must be willing to listen and decide when you're wrong, and when the suggestions go against 'the plan.'

Good luck, and may you enjoy walking that line.

--
www.buildinglinuxvpns.net

I personally use Stunnel on a few boxes, linux/windows/freebsd. It basically wraps your connection with ssl. You set it up on both servers, then connect to localhost:port and it forwards to the remote server ssl encrypted. Like ssh tunnels, but its a stand alone program. Also very transparent to the user.

TLSwrap is another ssl wrapper, used for ftp, but can be used for other ports.
Safetp seems to be a popular one with the college kids. Ive tested it out, and it does encrypt your session, and any ftp client will work since it encrypted the port.

Personally, I dont want command line on windows, I want a GUI for windows. Tight VNC isnt encrypted, but you can use stunnel to take care of that. But I find remote desktop, using rdp 5.1, is fast as hell(compared to tightvnc) and is designed for windows. Very usable over a modem too.

I Love computers and networking, 500 solutions to 1 problem.

set up an ssl tunnel between each client node and the print server(s). STunnel might help you out with this.

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.

OS X does not have DAV over SSL natively. See my article over on Mac OSX Hints for how to set this up with stunnel.

1. Run your own IRC server, or convince a friend to do so, and allow only SSL connections. Unreal, a popular ircd, supports SSL connections (port 994 by default). Unfortunately MIRC doesn't have built-in SSL capability, but it's very easy to get around this by running stunnel, a free (beer && speech), cross-platform SSL wrapper for any application. stunnel encrypts your text, sends it to the IRC server, receives the text and decrypts it for you. Essentially a multipurpose SSL proxy.

2. If you can't run your own IRC server, find one which a) supports SSL and b) is run by geeks. IIRC, irc.distributed.net allows you to create your own channels. I know it supports SSL and it's highly doubtful they're cooperating with law enforcement.

3. Avoid IRC and instead use an encrypted instant messaging program. I've found a few but I like Simp. It's free (beer && speech) and open source, too. It uses Blowfish to encrypt your messages, unfortunately you can only talk to one person at a time. But it can be convenient in a lot of situations.

I would really suggest options 1 and 3 if you're concerned with security. The only way to know for sure whether or not anyone else is listening, is if you control the environment.

So, the very people who should be using it, users out in the field won't because they have been burned before. So, I was recently setting up IMAP/SSL and OWA/SSL access to our email server using stunnel as a backup, in case the VPN client doesn't feel like resolving names.

They seem to like this, so I was also looking at using one of the many variants on smb2www over SSL to provide backup access to our NT file servers, but I wanted to limit what servers and shares they could see this way from the outside. If these products can do that, then I might just recommend them for our company!

Balam

You certainly can preach about 'feature-above-security mindset that needs to go' for as long as you want, but when it will come to the product not working at your biggest customer site due to the firewall setup and them not willing to mess it up just for trying out yet-another-beta proggy, you will consider SOAP, stunnel, httptunnel and anything else that will get you closer to the goal.

I agree that positioning SOAP as firewall-transparent protocol is .. err .. may get interpreted incorrectly by less experienced members of comp.sci society, but .. hey! .. you can misuse almost everything.

.. and (not re: your post, but a thread head) XML-based marshalling ? Give me a break ... Once you start tuning the performance, you realize that bottleneck is often exactly in the freaking SOAP layer with its bloated XML data encoding. You certianly can compress it, but what's the need in XML there for then ?

I've got my own ircd which I require the clients to use stunnel or an ssl-enabled client to connect. Soon, I can limit access purely by accepted certs, thereby keeping lusers out.

Of course the same can be done with OpenSSH. I use that at work to bypass my office firewall and use my home cable connection for a proxy to usenet, email, and other service. The best part of this is I can bypass my ofice proxy so they don't record where I netsurf. it looks a lot like a bunch of ftp and telnet to them.

You can download STunnel and do this on your own, it's definitely not a hard task to do.

Good to see more security books are coming out and I agree an intro into stunnel would have been well worth it. Currently I wrap just about everything under stunnel, X, LICQ, pppd, and I love it. However on the other hand many people who don't understand SSL and are prompted for certificates would likely be offended to see an SSL cert created by something other than Verisign so the author should have attempted to debunk the idea that only Verisign or other vendor cert is law.

Maybe referencing Bruce Schneier's doc either by snippets or including a link to the document could've given clarity to those who don't understand some of the overhype about PKI.

I'm assuming that you've already discussed this with the local überBOFH and decided that ssh is not acceptable, but a tunnel is. My personal opinion of your situation is that a tunnel is only acceptable if the remote endpoint is behind a firewall with a ruleset as least as restrictive as the home network's firewall and is subject to usage rules (who has access, what is each user allowed to do, etc) at least as restrictive as those of the home network. Remember that establishing a tunnel between two nets is equivalent to connecting the two networks behind their firewalls - if someone has access to one network, he won't be bothered by the firewall on the other.

That said...

At a client site I'm currently tunneling past a NAT router (because I want to run a protocol that the router can't masquerade) by having a machine behind the router establish a connection to a machine outside. I'm using a program called Tunnel Vision (http://www.worldvisions.ca/tunnelv/, or package tunnelv on Debian), but since your firewall probably won't allow it past you should use a protocol that your firewall does allow in ways that it dosen't expect.

If your firewall allows https through, you should be able to run anything you please through port 443 as long as it's SSL-wrapped (so the firewall dosen't think anything's amiss). You could use the stunnel package (http://www.stunnel.org/, or package stunnel on Debian) for this - set a server running on port 443 of a machine outside the firewall, and start the client running inside. This will establish a stream between the two endpoints, and you can run anything you please over it - I'd choose to run pppd.

If your firewall dosen't allow https but does allow http, you can use httptunnel (http://www.nocrew.org/software/httptunnel.html, or package httptunnel on Debian). I haven't used httptunnel, so I don't know if you need to run pppd inside it. If it dosen't do strong authentication and encryption, you'll need something inside it for that, too.

These solutions require that an IP be reserved inside the firewall for the machine on the outside end. The machine inside should proxy-ARP for the machine outside.

You could also tunnel traffic over DNS queries - see http://nstx.dereference.de/nstx/ for a program that will do that - but it's doubtful that you'll need to do that.

I have seen firewalls that are overly strict, but they allow HTTP or HTTPS through them. If you have a host on the outside and a client on the inside, you can setup a PPP connection using stunnel between the two machines. Then you can do anything you like (including display a browser from the outside host back, run icq, etc. The cool thing is, if you use stunnel you can encapsulate it over https. This gives you the ability to have a secure, non-monitored, encryted connection to the outside host.

Goto www.stunnel.org and you'll actually find examples of tunneling ppp (and thus tcp/ip) over HTTPS.

--
Twivel

This was submitted almost 3 weeks ago, anyways, its nice to see that people are still interested in the BSD's.

Recently I optioned on either buying two more Nokia 650 firewalls for my network and installed three new OpenBSD boxes using a combination of Trex, and IPF. While Checkpoint is a pretty cool firewall, I figured we (my company) didn't need to go out and spend more loot on firewalls. Sure IPF and Trex don't have true stateful inspections, and sure you can't do as much as you can with Checkpoint, but here are some of the neat things I managed to fiddle with. (posting this for this who do the fw things ya know)

On my Checkpoint FW I'm allowed the ability to mainpulate time based rules. (meaning I can allow in, out, block, on certain times of the day etc.) Being that at night (in case things go bonkers) servers go down, I made a simple shell script that is cron'd to open a connection at 8pm daily (when I'm home away from work) to my home subnet. This is pretty similar to Checkpoint's time based rules.

Not a major hack but it does me justice

Using a combination of FreeBSD, NetBSD, and OpenBSD at work (I'm senior admin so I get to use whatever I want) I also took the liberty of stunneling just about everything I could with OpenSSL so even if someone got unto out network, traffic is pretty secure for the most part.

Anyone else care to share some tweaks, tips and stuff on this boring Sunday?

The only real problem then would be getting people to employ it, and that could be done if it were made backwards compatible by accepting older smtp connections but adding a header that indicated it was at some point transmited in the clear, and accepting a security header that commanded it not to forward to in older servers.

It would seems like it would be a simple modification to SMTP. Though I suppose it would have to get through the IETF first.

Actually, there's a program out there called stunnel which allows you to create SSL functionality in any server. What it does is listen on a designated port and then tunnel any connections to it to a local (or even remote) port. We've actually started using it at where I work, by having stunnel listen on the pop3s port (995, I believe) and it tunnels connections to it to its local pop3 port. Outlook and Outlook Express at the very least have the capability for SSL-encrypted SMTP and POP3, and I believe Netscape 4.7x supports SSL-encrypted SMTP.

Just my $.02...

"For a dark man shall come unto the House of God, and the darkness shall be upon him, yea, even within him." -- from Noctropolis: Night Visions

Find it at http://www.stunnel.org/.

Stunnel is not too hard to setup for SPOP3 and SIMAP. Just tell your users to ignore the certificate warnings...

``...play with it a little and you'll never use telnet and FTP again''

Of course, people forget about their mail a lot. Here at UMN, our central mail servers run stunnel, so you can read your POP3 or IMAP mail over an SSL tunnel. Before I found out that they were doing this, I was really bothered by how many people could be sniffing my password. I had tried usin SSH tunnels, but that required you to stay logged in.

New versions of Netscape Communicator do support SSL, and I believe recent versions of mutt do too.
--
Ski-U-Mah!