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:
>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:

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.

>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

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

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.