Re: Netscape the Big Win

From: Enzo Michelangeli <enzo@ima.net>
> On Thu, 20 Jul 1995, Hal wrote:
> > That is why I am working on the proxy approach.  Any browser should be
> > able to use enhancements supplied in this way.  Netscape is the big name
> > this year, who knows who it will be next year.  As long as IP
> > connectivity is available a proxy can get into the stream and apply
> > enhancements.
> 
> I still maintain that an approach based on SOCKS would be more flexible, 
> adaptable to any TCP-based application. Here's what I'm thinking about:

I agree with this general approach, but I looked into it in some detail,
and SOCKS has a fatal flaw for my purposes: the address to connect to is
passed as an IP 32-bit address.  That means the software on the PC
has to do the DNS lookup.  And *that* means that the ultimate site being
connected to is revealed.

One of my goals is to protect the secrecy of the sites that a person is
browsing.  If an in-the-clear DNS lookup is done for each site that will
hardly be effective, even if the actual connection request is encrypted.
An eavesdropper on the internet will be able to observe the DNS lookup
traffic.

Now SOCKS V5 is going to change this; it allows the proxy to receive the
request as a hostname rather than an IP address.  So no DNS lookup is
necessary by the client.  Conceivably a modified winsock such as Enzo is
suggesting could use that protocol, although it is not really stable
yet.

Also, I don't know how easy it is to intercept winsock calls and modify
them in this way.  So the proxy I have written works using the HTML proxy
hook rather than the SOCKS hook.

> 1. Windows apps: a general purpose socksifier, intercepting Winsock API
> calls by *unmodified* applications and opening a single TCP connection to 
> the port 1080 of a sockd server. The good news is: some good folks at NEC 
> are already working at this project, and are looking for beta-testers.

This sounds very good if it already is almost working.  The TCP
connection which is opened would have to be to a server on the local
machine, so it would be important that the software support that.  Also,
the local SOCKS relay would of course not want its winsock calls to be
intercepted and translated in this way, so there would need to be some
alternative way to access "vanilla" winsock.  Can you give any
more information on the NEC work?

> 2. A "SOCKS en/decrypting relay": a sockd server that, on a 
> per-site/per-port basis depending on a configuration file, may either 
>  a) open TCP connections on behalf of its clients; 
>  b) relay a plain SOCKS connection to a remote peer;
>  c) open a SSL connection to a remote peer on, say, a port 1180 reserved
>     for "SSL-ized SOCKS" connections)
> Of course, that beast should also listen at the ports 1080 and 1180 and 
> take the same actions a) b) or c) as appropriate.

For chaining purposes you would connect to the relay on the net on the
secure port and request a TCP connection (not a SOCKS connection) to
the second relay in the chain at its secure port.  Then you negotiate a
secure connection from your home PC to that second relay so that the
traffic you send to it won't be visible to the first relay.  Once that
is done you send a SOCKS request to that second relay to connect to the
next machine in the chain.  So really only function (a) is needed for
the relays on the net.

The relay on the PC needs to be able to do (c), but more importantly it
needs to be able to set up encryption chains, where every outgoing packet
is nestedly encrypted, with the outermost encryption for the first relay
in the chain, the next layer for the next relay, and so on.  Each relay
decrypts and strips off one layer, then passes the remaining raw data
through.  This way no one relay knows who is talking to whom or what they
are saying.  The reverse happens for return packets.

> The SOCKS en/decrypting relay could be written both as MS-Windows DLL and as 
> UNIX daemon.

I have written a simple dummy relay for winsock and it requires a pretty
different programming style than for Unix.  Netscape has a habit of
firing off a bunch of requests at once, so it has to be extremely
asynchronous.  For Windows this means you get a windows message every
time a packet arrives and use non-blocking I/O.  In Unix this is usually
handled by forking a new process to handle each independent connection.
Non-blocking I/O can be used in Unix but I don't think there is a
non-blocking connect as there is in Windows.  Maybe Windows 95 will allow
a more Unix-style communication model, though.  Should the proxy require
Windows 95, or will Windows 3 still be in widespread use for another
year or two?

Also IMO the requirements for the Internet relay are pretty different
than for the Windows relay.  The Internet relay needs only to be able to
decrypt/encrypt on the port where the request comes from while sending
plain data the other way.  It needs a config file so the owner can
control what kinds of outgoing TCP connections can be done.  The Windows
one needs to be able to do nested encryption (if chains will be allowed
eventually), to set up chains, etc.  So for these reasons I am inclined
to think that the two relays would be separate programs.

> The chain would be:
> 
> - From a Windows client machine:
> 
>  Standard app -> Socksifier DLL by NEC -> encrypting relay -----> 
>   ---> Internet -----> decrypting relay -> server
> 
> - From a Unix client machine:
> 
>  Socksified (recompiled) app -> encrypting relay ------>
>   ---> Internet -----> decrypting relay -> server
> 
> I'm assuming here that the encrypting relay should live close to machine
> (the same, or, at least on the same network) as the client app, and the
> decrypting relay close to the server. A single daemon could do both jobs, 
> allowing chaining "a` la remailer", but I'm using here two different 
> names for sake of clarity. Besides, the Windows version probably wouldn't 
> need decrypting ability.

The Windows version would need to decrypt incoming data; you don't want
that coming in the clear.

> Great advantage over Netscape: we could use EAY's free SSL implementation,
> and all the server administrators could generate and sign their own
> certificates. The present trouble with Netscape is that NS-Navigator
> refuses to accept certificates not signed as "Netscape compatible". Our
> en/decrypting relay could be more forgiving :-)

The other problem with Netscape SSL is that it will only open secure
connections to URL's marked "https://".  Similarly SHTTP has a special
URL "shttp://".  There is no provision in either one to open a secure
connection to "http://".  A relay proxy would allow all connections to be
encrypted between the PC and one or more relays.

I am a little unclear on the certificate situation.  As we saw with the
PGP key servers before RSAREF PGP existed, RSA put pressure on these
public sites which they saw as contributing to the use of infringing
software.  Similarly having a certificate created by infringing software
might be seen as illegal, even if RSAREF was actually used for the
handshaking in the protocol.  Server operators are quite vulnerable to
threatening letters from RSA.

Another problem with RSAREF is that it does not allow you to exchange a
session key using RSA encryption in a straightforward manner.  The entry
points you have legal access to choose a random session key, PK encrypt
it, send it, and then encrypt the message using that session key with DES
or 3DES.  However I notice that SSLREF calls undocumented entry points
like RSAPrivateDecrypt and RSAPublicEncrypt.  I am not sure how they are
able to do this.  Maybe they got special permission from RSA.  I don't
know whether the SSLEAY library would be able to do this without such
special arrangements.

> As the SSL stuff built in
> Netscape would be unused, we could also improve the protocol (plugging
> security holes) ignoring compatibility issues.

Yes, really there is no need to make it be SSL specifically except for
the fact that it is an explicit protocol for which libraries exist.

> The administrators of
> secure servers should just advise the users to configure their local
> encrypting relays to pass through their decrypting relay (that would boil
> down to a line added to the encrypting relay configuration). 

> It would all be beautifully modular, relatively simple to code (as someone
> else has done, or is doing, most of the hard work) and independent from
> big-brother certifying authorities. 

Yes, I think the overall approach is very promising.  Perhaps my desire
for chaining is too ambitious for a first attempt.  The transparent
intervention of SOCKS that you describe would be very nice if that is
available soon.

One other problem is the risk taken by people running the relay servers
on the net.  These could be used to launder connections by hacker /
cracker types.  So probably only a limited set of outgoing ports would be
permitted, say, 80 and 1080 which are the most common http ports.  This
would restrict the utility of the SOCKS approach for other uses like
secure telnet, unfortunately.

Hal

On Fri, 21 Jul 1995, Hal wrote:

> This sounds very good if it already is almost working.  The TCP
> connection which is opened would have to be to a server on the local
> machine, so it would be important that the software support that.  Also,
> the local SOCKS relay would of course not want its winsock calls to be
> intercepted and translated in this way, so there would need to be some
> alternative way to access "vanilla" winsock.  Can you give any
> more information on the NEC work?

I can only quote the original posting to the SOCKS mailing list - I answered 
their call for beta-testers, but I haven't heard back from them, yet:

-------------------------------- 8< ---------------------------------------
>From cornell@syl.dl.nec.comSat Jul 22 18:50:10 1995
Date: Thu, 20 Jul 1995 10:05:47 -0500 (CDT)
From: Cornell Kinderknecht <cornell@syl.dl.nec.com>
To: socks@syl.dl.nec.com
Cc: Cornell Kinderknecht <cornell@syl.dl.nec.com>
Subject: Good news for Windows/Winsock users

New SOCKS application for PC/Windows/Winsock.  Looking for beta
volunteers...

We've developed an MSWindows .DLL (Windows version 3.1) that allows
unmodified TCP-based Winsock applications and TCP/IP stacks to
communicate through a SOCKS4.2 server.  This will hopefully be
available for general release sometime soon.  Currently, I'm looking
for volunteers to do some beta testing.

If interested, willing to provide feedback, and don't mind rebooting
your PC when when it locks up :-), email the following information
about your environment to scbeta-apply@syl.dl.nec.com:

1. Winsock stack type and version (Trumpet, NetManage, etc.).
2. Other network OS/drivers (Netware, IPX, packet drivers, SLIP, etc.).
3. Winsock applications (trumptel, wsftp, netscape, etc.).
4. Your email address.
5. Anything else relevant...

I'll keep the number of beta testers limited and so unfortunately I
might not be able to include everyone who requests.

Oh, BTW, here are some requirements:
1. MS Windows3.1.
2. Installed and operating Winsock TCP/IP stack.
3. Installed and operating SOCKS server (v.4.2).
4. PC running Winsock stack must be able to use DNS to resolve
   names and IP addresses (including its own).

--- Cornell
| Cornell Kinderknecht          Email: cornell@syl.dl.nec.com |
| CSTC                            			      |
| NEC Systems Lab.              Phone: 214-518-3509           |
| Irving, TX (Dallas)             			      |
-------------------------------- 8< ---------------------------------------


[...]
> non-blocking connect as there is in Windows.  Maybe Windows 95 will allow
> a more Unix-style communication model, though.  Should the proxy require
> Windows 95, or will Windows 3 still be in widespread use for another
> year or two?

I'm afraid we'll have to live with async socket calls for a while...

> 
> Also IMO the requirements for the Internet relay are pretty different
> than for the Windows relay.  The Internet relay needs only to be able to
> decrypt/encrypt on the port where the request comes from while sending
> plain data the other way.  It needs a config file so the owner can
> control what kinds of outgoing TCP connections can be done.  The Windows
> one needs to be able to do nested encryption (if chains will be allowed
> eventually), to set up chains, etc.  So for these reasons I am inclined
> to think that the two relays would be separate programs.

Well, a config file would be necessary for the windows one too. For 
example, we could want to socksify only connections to some sites/ports, 
socksify+encrypt some others, and open direct TCP connections to others 
yet, such as servers on the same net (I presume that NEC's DLL will 
attempt to socksify all the connections, so we should de-sockisfy some of 
them intoducing sockd functionality.

> The Windows version would need to decrypt incoming data; you don't want
> that coming in the clear.

Oh yes, I actually meant that it should only be able to issue, and not also
accept, "client hello" requests (as per SSL model).

> 
> I am a little unclear on the certificate situation.  As we saw with the
> PGP key servers before RSAREF PGP existed, RSA put pressure on these
> public sites which they saw as contributing to the use of infringing
> software.  Similarly having a certificate created by infringing software
> might be seen as illegal, even if RSAREF was actually used for the
> handshaking in the protocol.  Server operators are quite vulnerable to
> threatening letters from RSA.

RSA patents (I mean RSA, not RSADSI's) are only valid in USA. If I set up 
a certifying authority, say, here in Hong Kong, using EAY's code written in 
Australia, how could RSADSI complain? Server operators would import 
data created under perfectly legal conditions.

> Another problem with RSAREF is that it does not allow you to exchange a
> session key using RSA encryption in a straightforward manner.  The entry
> points you have legal access to choose a random session key, PK encrypt
> it, send it, and then encrypt the message using that session key with DES
> or 3DES.  However I notice that SSLREF calls undocumented entry points
> like RSAPrivateDecrypt and RSAPublicEncrypt.  I am not sure how they are
> able to do this.  Maybe they got special permission from RSA.  I don't
> know whether the SSLEAY library would be able to do this without such
> special arrangements.

That should be investigated. Is RSAREF's licence only valid for some 
entry points? In any case, I suppose that SSLREF may be used with any 
certificate, unlike Netscape (am I wrong?).

> One other problem is the risk taken by people running the relay servers
> on the net.  These could be used to launder connections by hacker /
> cracker types.  So probably only a limited set of outgoing ports would be
> permitted, say, 80 and 1080 which are the most common http ports.  This
> would restrict the utility of the SOCKS approach for other uses like
> secure telnet, unfortunately.

Well, the same problem exists for illegal uses of the present remailers, 
but hasn't stopped their operators.

Enzo

-----BEGIN PGP SIGNED MESSAGE-----

Hal said:
> This sounds very good if it already is almost working.  The TCP
> connection which is opened would have to be to a server on the local
> machine, so it would be important that the software support that.  Also,
> the local SOCKS relay would of course not want its winsock calls to be
> intercepted and translated in this way, so there would need to be some
> alternative way to access "vanilla" winsock.  Can you give any
> more information on the NEC work?

This should be fairly straightforward: take the existing winsock.dll
or winsock32.dll and rename it. Install the NEC DLL with the old
winsock's name, then have the NEC DLL do a LoadLibrary() to attach the
original version.

> I have written a simple dummy relay for winsock and it requires a pretty
> different programming style than for Unix.  Netscape has a habit of
> firing off a bunch of requests at once, so it has to be extremely
> asynchronous.  For Windows this means you get a windows message every
> time a packet arrives and use non-blocking I/O.  In Unix this is usually
> handled by forking a new process to handle each independent connection.
> Non-blocking I/O can be used in Unix but I don't think there is a
> non-blocking connect as there is in Windows.  Maybe Windows 95 will allow
> a more Unix-style communication model, though.  Should the proxy require
> Windows 95, or will Windows 3 still be in widespread use for another
> year or two?

Asynchronous requests are the best way to implement I/O under Windows
(3.1, '95, and NT.) Any app that's threaded (Free Agent and Netscape
come to mind) will benefit, as will any user who's using a
multiprocessor machine.

If you're willing to assume the existence of Win95 or WinNT, you can
always spawn a new thread for each connection.

- -Paul

- -- 
Paul Robichaux, KD4JZG       | Do you support free speech? Even when
perobich@ingr.com            | you don't like what's being said?
		 Be a cryptography user. Ask me how.


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMBZVcafb4pLe9tolAQHrHwQAhBAtIAZnaL2gh1BhZeE6WWQ1UQK7ffB2
XRZReUNzAVpCyvllKPDiN5TgUSuit8XeB4BzHOStXkNMJGlLE0vqTr5j5y2S0Fzo
nisi5Ve5+8XWJ8wFrshldfFcLyFuOK3LeL9cAKXQQrQ2GdxluusqBzqYHFM8koPP
zWI2YiF0VHM=
=yzFt
-----END PGP SIGNATURE-----

On Wed, 26 Jul 1995, Paul Robichaux wrote:

> Hal said:
> > This sounds very good if it already is almost working.  The TCP
> > connection which is opened would have to be to a server on the local
> > machine, so it would be important that the software support that.  Also,
> > the local SOCKS relay would of course not want its winsock calls to be
> > intercepted and translated in this way, so there would need to be some
> > alternative way to access "vanilla" winsock.  Can you give any
> > more information on the NEC work?
> 
> This should be fairly straightforward: take the existing winsock.dll
> or winsock32.dll and rename it. Install the NEC DLL with the old
> winsock's name, then have the NEC DLL do a LoadLibrary() to attach the
> original version.

In any case, Trumpet Winsock has got a buit-in socksifier, even in the 
non-time-limited version 2.0b. It's activated by the "Firewall setup" 
dialogue box, and seems to work: I've just tested it with a sockd 4.2b 
running on a Linux box. NEC's DLL will add the same functionality to 
other stacks, but experimental encrypting relays could be tested right 
now with Trumpet Winsock.

Think about it, this could be the ultimate encryption hook: I don't think 
that NSA could arrive to ban firewall support...

Now for a catchy name for SOCKS-based encrypting relays: what about 
"SafeSox"? :-)