Other Directory Sites: SeekWonder | Directory Owners Forum
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:10:59
C Matthew Curtin (cmcurtin@interhack.net)
Fri, 21 Aug 1998 08:06:47 -0400 (EDT)
>>>>> "steven" == steven soroka <steven.soroka@mts.mb.ca> writes:
steven> correct me if I'm wrong,
You asked... :-)
[Experts please excuse a few oversimplifications I've made. I'm
focusing on the key to explaining what's going on, not details about
how different layers work with each other. Hence, I'm avoiding
tangents about technicalities...]
steven> but if the smtp server encrypts the body of the message, but
steven> not the routing information, the pop server receiving the mail
steven> on the other end would have to decipher it to make it
steven> transparent to the user.. if the routing information is
steven> encrypted, all the routers have to be able to decrypt it and
steven> encrypt it again, which is close to impossible to impliment.
Nope. You're confusing lots of things that live on different layers.
Let's use the ISO/OSI seven-layer model for networking. You've got:
o application SMTP lives here, as do other services, like POP3
o presentation
o session TCP is in this general...
o transport ...area
o network IP lives around in here
o data link Ethernet, FDDI, ATM...
o physical
Each layer depends on the services provided by the layers below it.
ARP glues the data link layer to the network layer. After that,
everything is riding on top of IP. Routing information, and all of
the stuff that routers deal with is handled in the network, transport,
and session layers, depending on the individual router's configuration
and such. IPsec and all of that sort of thing lives down there in the
group of layers that routers play with.
OK, so now we've got this network where hosts can get data back and
forth to each other. This actually happens at the application layer.
Specifically, if you send me mail, your Mail Transport Agent (MTA),
i.e., (sendmail|qmail|vmailer|upas) is going to look at the target
address which is in a header that you've sent me. (If you've
encrypted the mail to me, you haven't encrypted your headers, only the
body gets encrypted.) Your MTA is going to do some DNS lookups to
figure out where to send the message.
Your MTA will then make an SMTP connection (i.e., TCP connection to
port 25) of my machine, and my MTA (i.e., sendmail) will receive the
connection. They'll do a little handshake, the data will be sent, and
then the connection will be ended. My MTA will then deliver the mail,
either by forwarding it to a host closer to me (if it's something like
a corporate mail gateway), or to my mailbox if that's the machine from
which I get my mail.
If I'm using POP3 to pick up my mail, my Mail User Agent (MUA), i.e.,
(VM|Eudora|Netscape|telnet :-) will make a POP3 connection (TCP to
port 110) to the mail server, do a little handshake, and then download
my mail to my local machine, from which the message will be browsed.
Now, hacks to sendmail in order to make its SMTP conversation
encrypted would protect against third-party eavesdroppers in the
middle (i.e., a big government intelligence agency with a router at a
major network access point that logs everything). But it would do
nothing to prevent an eavesdropper between you and your MTA or between
my MTA and me.
One way this would be accomplished is as follows:
o Your MTA makes a connection on TCP/25 to my MTA.
o They handshake, and in the process, find out if they're both "PGP
session capable", where "PGP session" is how the hack we put in
identifies itself.
o If they both are, then your MTA will create a random session key
and send it to my MTA, encrypted with my MTA's public key.
o My MTA will decrypt the message with its private key, and retrieve
the session key.
o The conversation then switches to an encrypted session, using a
symmetric cipher, with the random session key generated by your
MTA.
o The subsequent sending of the data all takes place over the
now-encrypted channel.
o They end the conversation normally, but over the encrypted channel
instead of in the clear.
This leaves some room for deciding things like how to verify host keys
and that sort of thing, but should give you the general idea.
Hope that helps.
-- Matt Curtin cmcurtin@interhack.net http://www.interhack.net/people/cmcurtin/
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:10:59