Two common examples of needs for privacy and security on open transmissions via the public Internet are:
both of which being doable with today's available encryption technologies, with a reasonable amount of effort and cost, as well as degree of security. Reality is that most communication is handled in clear text, certainly and issue for companies working on sensitive developments, or other Internet users needing a certain degree of privacy for their transmissions, as well as some degree of certainty for data integrity of what had been sent and received.
There is nothing new or special in this writeup. The tools are readily available for quite some time, even tools not being very invasive regarding extra effort on the part of the user. The one used for this writeup is ssh (ftp://ftp.cs.hut.fi/pub/ssh or http://www.datafellows.com/f-secure). The issue is more being sensitive about exposures, and actually doing something about it.
As an example illustration, let's assume three Internet client networks, interconnected by broad, openly available, Internet infrastructure, consisting of interconnected Internet Service Providers (ISP):
In this diagram the numbered red circles as the ISPs that constitute the interconnection network for the infrastructure. Each of the networks (N1, N2, N3) has a router (R1, R2, R3), and a host (H1, H2, H3) on their network. In this case the routers connect to a single ISP each. In all the outlined scenarios, each of the (N1, N2, N3) network can accommodate many hosts.
The common conventional practice is global knowledge of and accessibility to all the component networks, keeping All the networks globally known, and reachable from other networks within the Internet community, typically either via direct knowledge of a route to the specific network, or by using a default route. In other words, each host can directly send traffic to any other host. The communication is typically done in clear text transmissions, as illustrated in the next graphic:
where, using H1 as the common source host, H1 can reach the other hosts in the system (H2, H3) directly via the overall infrastructure, with data being exchanged in clear text.
A scenario is a remote email server, available to a secured, likely firewalled, intranet, with clients at the outside the firewall on the open Internet. A specific application would create an encrypted tunnel:
in this case between hosts H1 and H2. In a Linux scenario this can be done by using an imap server, and ssh for the encrypted tunnel. The secured mail server on H2 (TARGET) can start an imap daemon after adding
imap2 stream tcp nowait root /usr/sbin/tcpd /usr/sbin/imapd
to it's /etc/inetd.conf file. The CLIENT machine (H1) can create a tunnel by issuing a
ssh -f -L 108:TARGET:143 -p 2345 -l USER TARGET Bin/ssh_pause
command from the H1 machine, while of course using the real IP addresses for CLIENT and TARGET for all these examples. Also a real userid for USER would be required, for an account that possibly is allowed to log in without a password (e.g., by adding the appropriate key into the .ssh/authorized_keys files on TARGET. ssh_pause is a simple C program:
main() { pause(); }
who's only purpose is to keep run on TARGET without consuming significant resources, while keeping the ssh connection alive. The 108:TARGET:143 part creates an encrypted tunnel from port 108 on CLIENT to port 143 (the imap port) on TARGET. In other words, if someone connects to port 108 on CLIENT, he really connects to port 143 on TARGET, via an encrypted ssh channel.
After the ssh connection is alive, a command such as
fetchmail -p IMAP -P 108 -u USER CLIENT
will connect the user to the imap server on TARGET, collect the email, and append to the local email file (often in /var/spool/mail/USER) on CLIENT.
This can be automated by a simple shell script such as getrmtmail:
#!/bin/zsh
ssh -f -L 108:TARGET:143 -p 2345 -l USER TARGET Bin/ssh_pause
fetchmail -p IMAP -P 108 -u USER CLIENT
and adding something like:
4,24,44 * * * * PATH/getrmtmail 2>> LOGFILE
to /usr/spool/cron/crontabs/root. PATH and LOGFILE need of course be reasonable settings. This requires that root has passwordless access to the remote USER account; the use of root is necessary if a privileged port (such as 108 in the above case) is being used. If a non-privileged port is used, there is no need to run this as root.
This still leaves the access port on CLIENT (108 in the above case) accessible, which, in a Linux environment, can be protected by firewall filtering, e.g.:
/sbin/ipfwadm -I -f
/sbin/ipfwadm -I -a accept -P tcp -S CLIENT/32 -D CLIENT 108
/sbin/ipfwadm -I -a deny -P tcp -S 0.0.0.0/0 -D CLIENT 108
Once everything is set up, the whole email collection from the secured N2 network is working transparently to the user, it just adds the collected email to his normal mailbox, without specific action required by the user. However, it does nothing about secure sending of email from CLIENT, nor does it help if CLIENT itself is insecure, e.g., with multiple untrusted user accounts.
This method also requires remote access to H2, hence the use of port 2345 in the above ssh line, which is above commonly used firewall filters that may filer port numbers up to 1023.
Since this method required miscellaneous things that are more easily available to environments such as Linux, the E2 host in the diagram above could be a major email server for N2, that forwards email for USER to H2, which is then picked up by H1 from H2.
Using the above graphic again:
it is possible to create an encrypted forwarding mechanism for other usages as well. An easy case for ssh is X11 forwarding.
If USER is connected via ssh from H1 to H2, H2 is in a position to send X-Window information back to H1 via the encrypted ssh channel. This requires no special action, besides enabling X11 forwarding, and, of course, for H1 to understand X11 information. For example, issuing the command "xterm" on H2 will send an X-Terminal window from H2 to H1 via the ssh channel.
If in this scenario remote access to a web server, for example on E2, is desired, the remote user would simply start a web browser on H2, accessing th web server on E2 (e.g., netscape E2).
The main point of these simple examples is that it is entirely possible with today's available technology to create secure communication, even on a per application base, that requires little or no specific action or knowledge by individual users.
This does not resolve many other privacy and security concerns, and is only focused on two simple scenarios. For example, another issue is all the information common web browsers freely make available about the user and his machine to accessed web sites (a local web cache in N2 that also has an anonymizer function in it could prevent information leakage such as referral directories and so).