" /> UrlBlogGrey: October 2007 Archives

« August 2007 | Main | January 2008 »

October 31, 2007

The State of Secure E-mail

I've long been a proponent of using public-key cryptography to secure e-mail communications with digital signatures and encryption. For many years there have been messaging standards to ensure compatibility among e-mail clients when sending and receiving messages secured with public-key cryptography. So, why is it that in 2007 we are still not securing e-mail communications? Do people have a lower expectation of privacy? Are the tools that facilitate public-key cryptography too difficult to use? All of these issues are real, and I think they can be overcome through the careful application of public-key cryptography in all messaging systems.

The S/MIME messaging format allows for a digital signature and public-key to be included along with a plain-text or encrypted e-mail message. The S/MIME protocol was established in 1995, over 12 years ago. At that time, the predominant method of sending and receiving e-mail was with stand-alone e-mail clients, such as Netscape Communicator, Eudora, and Microsoft Outlook Express. Fewer people had access to the Internet in comparison with today. Instant Messaging was also not as popular as it is today, so e-mail was more heavily utilized than today.

S/MIME messaging was available in many of the e-mail clients available in the late 1990's, and is available in most of the popular e-mail clients in use today (Thunderbird, Outlook, Mac Mail, etc). However, a large amount of personal e-mail is handled through hosted web-mail services, such as Google's GMail and Yahoo! Mail. The appeal of these services likely comes from the convenience and reliability they offer. While in years past people may have had Internet access only at home or work, they now have Internet access from their phones, at coffee shops, and on mass transit systems. It's desirable to be able to access one's e-mail wherever the Internet is accessible, and to have an e-mail account that remains the same despite changes in one's ISP at home or work (i.e. switch from AOL to Comcast). But one shouldn't have to compromise the security of their communications in the interest of accessibility; for example, I can securely access my online banking services from any location with Internet access, but I don't (usually) jeopardize the security of my accounts by doing so. Also, I could switch companies used to host this domain (urlgrey.net) without negatively impacting my e-mail service.

So, if S/MIME has been available through stand-alone e-mail clients since the mid-1990's, why isn't it available in web-mail systems today? In my opinion, it's due to the web-mail provider's interest in reducing their culpability in the event that their users conduct illegal business using their services. There is no technical barrier preventing the web-mail providers, such as Google or Yahoo!, from providing e-mail communiques to the U.S. government or to other businesses. What's more, it's possible for e-mail to be tampered with while in transit or archival since there isn't a digital signature to guarantee message integrity. It's also possible for the e-mail message to be tampered with between the web-mail system and the end-user since most web-mail services don't maintain an HTTPS connection throughout the session. Recent publicity of telecoms providing warrant-less wiretaps as part of the U.S. government's electronic surveillance program offers a frightening example of how businesses can be coerced into divulging information about their customer's activities while bypassing the legal system.

My recommendation is that people use standalone e-mail clients that support S/MIME. This will provide greater security for your messages, and will provide less opportunity for your messages to be misused or tampered with. It may not be as convenient as web-mail services, but preserving one's identity and right to confidentiality ought to trump convenience.

October 30, 2007

Access Linux Machines using Apple Filing Protocol

Simplified sharing of files between computers is a very compelling reason for installing a home computer network. There are many protocols that simplify file-sharing: FTP, Secure FTP, Samba/Windows File Sharing, NFS, and Apple Filing Protocol (AFP). The last three support mounting remote file-systems on the local machine, making the remote system semi-transparent.

I'm hoping to upgrade my Mac machines to Mac OS X Leopard soon, and would like to take advantage of the new Time Machine feature. Time Machine will periodically backup changes to your system to an external hard-drive or network file-system. This makes file backup and recovery automatic. I have a Linux box that I think would be well-suited for hosting a backup-drive, so I began researching what it might take. I've read that Time Machine will back-up to network file-systems only over AFP. My Fedora Core 6 Linux machine was not configured to use AFP by default. What follow are the steps I took to get AFP support working under Fedora Core 6 with Netatalk 2.x.

The tutorial I found most helpful was on the Gentoo Linux site. I took the steps of installing the 'netatalk' and 'atalk' RPMS using YUM (yum install atalk netatalk).

Next, I changed directories to '/etc/atalk' in order to edit the configuration files provided by atalk. As mentioning in the tutorial, I configured the following services to run:

# Set which daemons to run (papd is dependent upon atalkd):
ATALKD_RUN=no
PAPD_RUN=no
CNID_METAD_RUN=yes
AFPD_RUN=yes
TIMELORD_RUN=no
A2BOOT_RUN=no

Next, I edited the 'afpd.conf' file to contain the changes mentioned in the tutorial. I added the following line at the bottom of the file:

- -noddp -advertise_ssh

I then edited the 'AppleVolumes.default' file to ensure that only home-directories (~) are accessible by AFP. This, too, is described in the tutorial.

Lastly, I configured the AVAHI daemon to publish the service using mDNS (Rendezvous
) by creating the file '/etc/avahi/services/afpd.service' with the XML document provided in the tutorial.

Make sure that the following services are enabled in the Fedora Services tool (run 'setup', select 'System Services'): atalk, avahi-daemon. Also, make sure that AFP (port 548, protocol TCP) is allowed through the firewall, if you are running one. Consider rebooting the machine, and you should be done.

I'm now able to access my Linux machine using AFP, which yields higher transfer rates and is better supported by OS X than the Microsoft-designed SMB protocol. Maybe I'll be able to use Time Machine, too!

screen-shot-afp.png