Re: SMTP Encryption Extension
Ariel Glenn wrote:
So data kept on the filesystem has to be protected and it has to be encrypted when it is sent out to the browsing (legitimate) user.
But you can do that already with standard software. Just encrypt the disk with CFS and the web server with SSL. Nothing needs to be invented to solve your problem. All the popular browsers already have SSL running. Which leads to another idea, couldn't we encrypt SMTP by running it over SSL as a web server cgi? If 99% of Internet traffic is web browsing and we are trying to hide our email, then why not make the email look like web browsing? Just make your mailer try a "POST https" command before falling back to plain SMTP. The problem with including crypto in a popular Linux distribution is that all popular Linux distributions are from the USA. Maybe suse (www.suse.de) can change that... Mike.
Mike writes:
Ariel Glenn wrote:
So data kept on the filesystem has to be protected and it has to be encrypted when it is sent out to the browsing (legitimate) user.
But you can do that already with standard software. Just encrypt the disk with CFS and the web server with SSL. Nothing needs to be invented to solve your problem. All the popular browsers already have SSL running.
Which leads to another idea, couldn't we encrypt SMTP by running it over SSL as a web server cgi? If 99% of Internet traffic is web browsing and we are trying to hide our email, then why not make the email look like web browsing?
You don't need to run it through a CGI. There's a port defined for SMTP-over-SSL: ssmtp 465/tcp ssmtp (from the IANA assigned port numbers document of feb '97) The problem with SSL is that it only protects the pipe, not the mail that's being transported. Mail is a store-and-forward scheme. It's stored on the local disk and forwarded to the next hop. Often that's not the recipient, but is a mail exchange or a firewall gateway. Then the MX or firewall forwards the mail on to the next hop, etc. (note that a CFS partition, in order to be used by a mail transport, would need to be mounted at all times, and therefore would be available to an attacker who gained root on the mail transport host) If your mail goes to an intermediate MX site, it'll sit in the clear on the disk there until its sent to its final destination. Even if all mailers supported ssmtp, the mail would not be secure. Email really needs to be individually encrypted instead of using encrypted pipes. If you want to protect all email (an excellent idea), build a mail transport which automatically encrypts each outgoing mail in the key of the recipient (or recipients's mail transport). It's not that hard to do, I build a 'pgpsendmail' for a former employer. Most of the effort was in figuring out where in sendmail to put the hooks to pgp. -- Eric Murray Chief Security Scientist N*Able Technologies www.nabletech.com (email: ericm at lne.com or nabletech.com) PGP keyid:E03F65E5
Eric Murray wrote:
There's a port defined for SMTP-over-SSL: ssmtp 465/tcp ssmtp (from the IANA assigned port numbers document of feb '97)
No, there isn't. The port 465 has been revoked. See <http://www.imc.org/draft-hoffman-smtp-ssl> for the current SMTP encryption draft. It seems that port 25 will be reused with encryption. Now, everybody please start implementing this draft and we'll soon have secure mail. I'm already working on a DOS 8086 version for the HP 200LX. Mike.
Eric Murray wrote:
Mike writes:
Which leads to another idea, couldn't we encrypt SMTP by running it over SSL as a web server cgi? If 99% of Internet traffic is web browsing and we are trying to hide our email, then why not make the email look like web browsing? You don't need to run it through a CGI. There's a port defined for SMTP-over-SSL:
If you want to protect all email (an excellent idea), build a mail
Sure, but the idea here was hiding email to defeat traffic analysis. Ssmtp would raise alarms in any snopper but https would seem like business as usual, probably just another gif. And https is available through a lot of firewalls where you can't run ssmtp. transport which automatically encrypts each outgoing mail in the key of the recipient Eudora/PGP already does that, but you are still quite vulnerable to traffic analysis unless you add remailers to the pot, which makes it a lot more complicated and error prone. A significant threat to online privacy comes from passive attackers, because you can't do anything about them. If you have an active attacker, you can analyze his moves and fix the bugs he uses to break root, but a passive attack is difficult to even detect before it's too late and your romantic conversations are headline news. Mike.
On Wed, 22 Oct 1997, Mike wrote:
Which leads to another idea, couldn't we encrypt SMTP by running it over SSL as a web server cgi? If 99% of Internet traffic is web browsing and we You don't need to run it through a CGI. There's a port defined for SMTP-over-SSL:
Sure, but the idea here was hiding email to defeat traffic analysis. Ssmtp would raise alarms in any snopper but https would seem like business as
Well, that wasn't *my* idea. My idea was to hide the contents of mail from totally passive attackers, and to do it with NO participation or training from the end users, MINIMAL participation and effort from the sysadmin, and transparent compatibility (minus security, of course) with standard mail systems. I claim that this combination of goals is worth pursuing; I recognize that there are systems which provide better security, but it's at the cost of some of my other goals. You want to defeat traffic analysis, use remailers. You want security against active attacks, use PGP (or equivalent). If you want these things to be really easy, you'll be stuck with talking only to systems you know support whatever application you're using. A significant advantage of an encryption extension to SMTP is that it requires no prior coordination between the two ends of a link. I don't have to know whether the destination system supports encrypted SMTP, and I don't need to try connecting to the "secure mail" port and then fall back to regular mail every time I connect to a system I haven't been introduced to. I just have to watch for the encryption extension in the list of extensions that current SMTP mailers already exchange when they connect to each other. My threat model is that the NSA is tapping thousands of people's lines; what can we do to make that impractical?
A significant threat to online privacy comes from passive attackers, because you can't do anything about them. If you have an active attacker, you can analyze his moves and fix the bugs he uses to break root, but a passive attack is difficult to even detect before it's too late and your romantic conversations are headline news.
Solutions like PGP won't see much use beyond people who care about privacy, and at the moment there aren't enough of those. But if encrypted SMTP is installed on *systems*, then all mail between such systems becomes protected from purely passive wiretapping. Yes, it can still be traffic-analysed, but only on the level of "this system sent this much mail to that system", not "this user sent this much mail to that user". It can still be intercepted by an active attack - if the NSA can fool my TCP into thinking it's talking to mail.aol.com, then all my mail to mail.aol.com is readable by NSA (unless the protocol gets elaborated to do more sophisticated key management than just exchanging public keys at the start of the session, but that quickly requires user involvement and I want to avoid that). However, can the NSA afford to do DNS spoofing on a grand scale? They might do it for one system if they want to get that system's mail in particular, but if you've got the NSA singling you out, you had better be using PGP anyway. I'm sure they can't do an active attack on thousands of ordinary people at a time, just in case we might be doing something interesting. I'm also not sure that traffic analysis on ordinary people is really going to produce any particularly damaging information. They *can* afford simple passive wiretaps on a large scale. (Substitute your favorite scary organization for "NSA" if you prefer...)
participants (3)
-
Eric Murray -
Mike -
mskala＠burnaby.csc.UVic.CA