Enzo Michelangeli (em@who.net)
Thu, 20 Aug 1998 07:49:04 +0800
A while ago, someone anonymously posted C code for such kind of tunnel. The
program was called CTCP, and performed unauthenticated Diffie-Hellman
exchange of a triple-DES key. I remember I wasn't impressed by the random
key generator, but perhaps the code could be used as starting point. It's
still available on several ftp sites, e.g.
ftp://ftp.replay.com/pub/crypto/crypto/APPS/ctcp/ .
Also, there are already free mail clients (e.g., Outlook Express) able to
speak SMTP (and POP3 and IMAP) over SSL. Perhaps this would be the way to
go: the protection would be extended up to the user's machine with no
additional software to install there. And SSL authenticates the key exchange
as well.
Which, by the way, reminds me of another much needed piece of freeware: a
Java implementation of SSL (or, better, TLS). The basic crypto classes
already exist and are internationally available, as part of the Cryptix
library (http://www.systemics.com/software/cryptix-java/), but the network
code has not been written (yet).
And then, of course, there is the Holy Grail of user-transparent security:
IPSEC.
Cheers --
Enzo
-----Original Message-----
From: Adam Shostack <adam@weathership.homeport.org>
To: Trei, Peter <ptrei@securitydynamics.com>; CodherPlunks@toad.com
<CodherPlunks@toad.com>
Date: Thursday, August 20, 1998 12:41 AM
Subject: Re: Crypto-sendmail (was Crypto Coding Project)
>Would it be more useful to build a reasonably generic 'crypto tunnel'
>than a sendmail extention? Would it be substantially harder?
>
>I ask because most of my machines today run qmail, and I hope will
>soon run Vmailer.
>
>The first hurdle is to bind into the connect() in some useful way
>on the outbound connection. On the inbound, a wrapper program (think
>tcpd) can probably be used.
>
>Adam
>
>
>On Wed, Aug 19, 1998 at 03:18:09PM +0200, Trei, Peter wrote:
>| I'd like to second Perry's suggestion of
>| building a crypto-enabled version of sendmail.
>|
>| Such a sendmail would use a DH exchange to set
>| up a link with perfect forward secrecy. The
>| end users need not do *anything*: he or she
>| does not even need to know that encryption
>| is being used - the sendmail would detect
>| whether it's partner was also crypto enabled,
>| and act appropriately.
>|
>| In many cases, the sender would not even need
>| to install a crypto enabled client, since much
>| mail passes through gateways and firewall
>| proxies 'near' to the sender before entering the
>| public Internet. If the gateway or proxy encrypts,
>| the entire process is perfectly transparent to
>| the end user.
>|
>| While strong authentication of the end parties
>| would be nice, even an unauthenticated DH exchange
>| is much, much better than nothing. A man-in-the-middle
>| attack on the DH exhange is an active attack, and
>| the capacity even a well-heeled criminal organization
>| to mount real-time MITM attacks vs millions of
>| mail connections per day is limited. Access to the
>| unencrypted sections of the link would be much
>| more difficult than compromising a few
>| key backbone routers.
>|
>| Instead of having to persuade millions of ignorant
>| end users to use crypto email clients and obtain
>| keys and certificates, all it takes is a single
>| sysadmin installing the proper sendmail or mail
>| gateway to provide greatly improved security for
>| hundreds of users.
>|
>| We could protect millions people from espionage,
>| without even telling them.
>|
>| I realize that this is not the perfect end-to-end
>| crypto most of us would prefer, but it's far
>| better than what most people do today.
>|
>| Remember: "The best is the enemy of the good"
>|
>| Peter Trei
>
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:10:59