Winsock & PGP Integration
-----BEGIN PGP SIGNED MESSAGE----- It has been a long discussed and desired feature for MS-Windows users to be able to integrate PGP functionality into the various Windows Sockets based mail and news readers. After a discussion with Raph and Pierre at the cypherpunks meeting this weekend, I took a look at the paradigm that premail uses and gave some thought to how this same concept could be applied in the Windows environment. On a Un*x machine, premail works by impersonating the mail transfer agent and intercepting the flow of mail in each direction, adding encryption, signing, and anonymous remail services in a rather elegant fashion. As the mail system under Un*x (indeed, the entire OS) is designed to be a "piped and glued together" batch of smaller utilities, premail's method works well and is very 'unix-like'. How to achieve the same under Windows with winsock based SLIP or PPP access? The various mail agents such as Eudora and Chameleon are integrated packages that do everything from using SMTP and POP for mail transfer to providing the user agent that reads and writes mail. There really is no simple way to wedge into the package and replace or supplement functionality. Except one. What all of these agents have in common is that they interface with the Windows Sockets API to establish TCP streams that are used in the POP and SMTP protocols. Since these are well known and standardized protocols, this gives us our toehold. Picture this. Using a replacement WINSOCK.DLL, we can intercept those specific API calls that an application would use to open the appropriate sockets and establish a TCP stream to a particular remote socket. For all other API calls, we hand these off to the "real" WINSOCK.DLL (that we have renamed and loaded after our DLL has loaded). Our replacement DLL now has the ability to make the mail application think it is talking to a remote SMTP or POP process, when in fact, it is talking to our agent on the local machine. Our local agent spoofs the SMTP protocol, accepts the mail, does all the neat crypto stuff, and stores the mail in an outbound queue. At whatever preprogrammed intervals, _our_ agent makes the _real_ SMTP call to the remote and delivers the mail. The reverse process would work as well. Our local agent periodically makes a POP call to the remote end, retrieves mail, and stores it in an inbound queue. Again, we do all the neat crypto stuff, and finally the next time Eudora or whatever mail agent is in use makes its POP run, we spoof POP and deliver the mail to the mail program. A little thought on this and I realized that this could be a generalized process. Want to implement an anonymous remailer under Windows? Use this mechanism and replace "neat crypto stuff" with "even neater anonymous remailing stuff." Majordomo for Windows? No problem, same method. By intercepting the flow of mail in each direction, there is no limit to the stuff you could come up with. Why bother fiddling with Windows anyway, when one has all the beauty and power of Un*x at one's disposal (such as Linux)? Well, think about where the personal computing sector is going to grow in about six months or so with the advent of Windows95. Okay, it's a great OS for what it is designed for, but it doesn't have pipes or perl or twenty or thirty command line parameters for every executable. So what. I garauntee that there will be more laptops and desktop PC's with Windows95 than with any flavor of Un*x. If we are to promote and encourage, as well as make the tools for, the use of strong crypto by the average Joe, then Windows is where it is at. I've just enough Windows programming experience to know that the scheme I worked out above is feasible and would work well. On the other hand, I have no experience with Windows Sockets at the api level, nor with any implementation of SMTP or POP (though I know the protocols themselves well.) Yep. It would be cool to write a message in Chameleon (such as this one), press the send button, and have a dialog box pop up asking me if I wanted to sign, encrypt, or remail this message. Or to have it done automatically for me. And this would work with existing mailers today. Sheesh, somebody burst my bubble. Comments, criticisms, suggestions, and especially financial donations, are quite welcome :) ======================================================================= Johnathan Corgan "Violence is the last refuge of the incompetent" jcorgan@netcom.com -Isaac Asimov PGP Public Key: http://www-swiss.ai.mit.edu/~bal/pks-toplev.html Or send email to: pgp-public-keys@pgp.ai.mit.edu Subj: GET jcorgan ======================================================================= -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLu0w2k1Diok8GKihAQGdnQP8DiqQt3820dhKHY3dbXAZnl/11eEce4z+ /oFZMKVBHlCJAxCSucnK31dcyRbvXiOkAt9x9EMinXC26VWh3sETd+YbaJNznkx6 VmM1UNID2bQ+Xpcc4ANJQx6CgPrRxspr3reVeuFv7QLtKGMy5Mucl5mXGp829f6i Gj7NMlhcu+s= =rgyq -----END PGP SIGNATURE-----
From: Johnathan Corgan <jcorgan@netcom.com> The proposal is to spoof protocols under windows. The idea seems perfectly sensible to me. Except one. What all of these agents have in common is that they interface with the Windows Sockets API to establish TCP streams that are used in the POP and SMTP protocols. Since these are well known and standardized protocols, this gives us our toehold. How might an interposed winsock DLL recognize what high level protocol it was going to spoof? Getting the port number will be a very good approximation, but I'm not convinced of its reliability. As to the general issue of MSWindows v. Unix, the Unix predominance for remailer software involves the fact that Unix is on the bulk of the machines connected to the Internet. It's more reliable for offering network services than MSWindows and it's got a cleaner architecture for reconfiguration. None of these explanations, however, means that there won't be more MSWindows that Unix boxes for a long time. Eric
Seems to me that the UNIX model of building one mail transport instead of 20 is a good one. If you seperate out the UA from the transport, you make it easy to fix or update the transport. So I would suggest, rather than hacking at Winsock and hoping to catch the right protocols, build a set of libraries that can be called by programs. smtp.dll, for example, would be a mailer that any mail program could call. nntp.dll would handle news, underneath all the various interfaces. If you want to pretend to be premail, you do it in smtp.dll. The advantage to other programmers is that they no longer have to do the low level stuff that they had to before. It allows programmers build whats interesting, namely, the interface & gizmos. Make the package do the user interface side of things, and make a seperate package to do the network protocols. Makes building, testing, and changing things a lot easier. And while you're at it, store all of your files as text. :) adam Johnathan Corgan wrote: | On a Un*x machine, premail works by impersonating the mail | transfer agent and intercepting the flow of mail in each | direction, adding encryption, signing, and anonymous remail | services in a rather elegant fashion. As the mail system under | Un*x (indeed, the entire OS) is designed to be a "piped and glued | together" batch of smaller utilities, premail's method works well | and is very 'unix-like'. | | How to achieve the same under Windows with winsock based SLIP or | PPP access? The various mail agents such as Eudora and Chameleon | are integrated packages that do everything from using SMTP and POP | for mail transfer to providing the user agent that reads and | writes mail. There really is no simple way to wedge into the | package and replace or supplement functionality. | | Except one. What all of these agents have in common is that they | interface with the Windows Sockets API to establish TCP streams | that are used in the POP and SMTP protocols. Since these are well | known and standardized protocols, this gives us our toehold. -- "It is seldom that liberty of any kind is lost all at once." -Hume
participants (3)
-
Adam Shostack -
eric@remailer.net -
Johnathan Corgan