On Thu, 20 Jul 1995, Hal wrote:
Note though that neither SSL or SHTTP requires that the certificates come from RSA. However the current versions of Netscape's browser do require this. This has been the source of much complaint and Netscape has promised that they will have some mechanism in the future to allow the user to choose his certificate signers. I am not sure how far RSA will let them off the leash, though.
We may bypass them altogether (see below).
Back to Perry:
Netscape is a closed system. You can't write code for it unless you work for Netscape.
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: 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. 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. The SOCKS en/decrypting relay could be written both as MS-Windows DLL and as UNIX daemon. 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. 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 :-) As the SSL stuff built in Netscape would be unused, we could also improve the protocol (plugging security holes) ignoring compatibility issues. 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. Comments?