Netscape the Big Win
Here is my experience with the last month of heavily using Netscape (1.1N), after several years of using a mix of Unix-based tools on a Unix shell account at Netcom (and several years of using Portal before that, beginning in 1988). (And intermittent Net use from 1973, when I had a very primitive account in college at UC Santa Barbara, on the "Arpanet," to the mid-80s, when I had various accounts while still at Intel.) * I use Netscape to read News. * I use Netscape to access the Web. * I still use Eudora to send and receive Mail. (Netscape can currently send mail, but not receive it. This is likely to change soon.) Why is this important? I believe, quite strongly, that we are headed toward a situation where the large majority of Net/Web users are using some variant of Netscape, or Mosaic/MacWeb/etc. (but probably Netscape, for various reasons). Integration of crypto into Netscape is thus the Big Win. I felt this was the case as far back as last fall, but my recent experiences tell me this is more important than ever. Integration of PGP and other crypto routines into Tin, Pine, Elm, Joe, Emacs, etc., is just not as important. IBM just paid nearly $3 billion for Lotus, largely for the "common platform" of Lotus Notes. I believe Netscape is an even more important common platform, and will displace Notes. I have been asked many times by various of you about investments, as I've been making my living the past decade through investments. The message here is my strongest statement about what to invest in. (I'm not saying one has to stand in line for the August IPO of Netscape Communications, but the overall market will favor the Web browsers, especially Netscape.) The relevance for Cypherpunks interested in writing code is that, in my carefully considered opinion, writing for Netscape and other Web browsers is the Big Win. Even over Windows (except Windows browsers, of course). --Tim May .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@sensemedia.net | anonymous networks, digital pseudonyms, zero 408-728-0152 | knowledge, reputations, information markets, Corralitos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway."
Timothy C. May writes:
Integration of crypto into Netscape is thus the Big Win.
Crypto *is* integrated into Netscape. Unfortunately, the crypto is SSL -- a complete waste of time. Among other things, SSL only lets you authenticate to X.509 certificate roots that have been issued straight from the hands of Jim Bidzos -- which effectively means that you can secure only connections with Netscape commerce servers, and that you cannot authenticate both ends of the communications link. Its also just plain bad -- there are ugly holes in the security from what I can see. Netscape is, of course, pushing it as a standard. Vomit. Luckily, Netscape recently hired Tahir El Gammal (did I put too many m's there?) and he's a smart guy. Unfortunately, he seems to be in a position where he has to defend the fairly bad work they did already. Other web security systems are also on their way out, of course. Our own Eric Rescorla (who lurks most of the time) is the author of the SHTTP specification.
The relevance for Cypherpunks interested in writing code is that, in my carefully considered opinion, writing for Netscape and other Web browsers is the Big Win. Even over Windows (except Windows browsers, of course).
Netscape is a closed system. You can't write code for it unless you work for Netscape. Perry
Crypto *is* integrated into Netscape. Unfortunately, the crypto is SSL -- a complete waste of time.
Among other things, SSL only lets you authenticate to X.509 certificate roots that have been issued straight from the hands of Jim Bidzos -- which effectively means that you can secure only connections with Netscape commerce servers, and that you cannot authenticate both ends of the communications link. Its also just plain bad -- there are ugly holes in the security from what I can see. Netscape is, of course, pushing it as a standard. Vomit.
Luckily, Netscape recently hired Tahir El Gammal (did I put too many m's there?) and he's a smart guy. Unfortunately, he seems to be in a position where he has to defend the fairly bad work they did already.
Still in catch-up mode. . . . As the person who evaluated Courier for Intuit, I feel compelled to point out that Intuit does *not* endorse SSL. I agree with all of Perry's criticisms, and offer a couple of my own: 1) since SSL is a sub-application-level protocol trying to solve an application-level security problem, it leaves communicating nodes vulnerable to early-termination attacks. SSL MACs authenticate individual SSL records, not application messages. 2) since only fools run http servers on secure network segments, network admins are faced with the problem of clearing sensitive data (presumably "protected" on the line by SSL) out of the DMZ in real time. This is a pain. Fortunately, Courier suffers from neither of these infirmities. - Mark - -- Mark Chen chen@intuit.com 415/329-6913 finger for PGP public key D4 99 54 2A 98 B1 48 0C CF 95 A5 B0 6E E0 1E 1D
"Perry E. Metzger" <perry@imsi.com> writes:
Crypto *is* integrated into Netscape. Unfortunately, the crypto is SSL -- a complete waste of time.
Among other things, SSL only lets you authenticate to X.509 certificate roots that have been issued straight from the hands of Jim Bidzos -- which effectively means that you can secure only connections with Netscape commerce servers, and that you cannot authenticate both ends of the communications link. Its also just plain bad -- there are ugly holes in the security from what I can see. Netscape is, of course, pushing it as a standard. Vomit.
Unfortunately the main alternative to SSL being pushed now, SHTTP, also suffers from RSA-itis. It will support either PEM or PKCS-7 key certificates, so I think ends up being pretty much the same as SSL in this regard. 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. The current version of SSL supports client authentication (via X.500 certificates of course). rsalz@osf.org writes re SSL:
I think it was Perry, for example, that pointed out that using one RC4 stream for each comm half was more-or-less obvious and standard practice.
I'm not sure what this is getting at. SSL does use a separate RC4 stream for each comm half. Is this a suggestion that a single key should be used for both directions? There are two ways that could be done: keep separate state info for each direction, in which case you are encrypting data twice with the same pseudo-random string, a definite no-no; or try to keep a single global state for the cipher, but this is impossible due to the (potentially) asynchronous nature of the communications. 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. Hal
Hal writes: | >Among other things, SSL only lets you authenticate to X.509 | >certificate roots that have been issued straight from the hands of Jim | Unfortunately the main alternative to SSL being pushed now, SHTTP, also | suffers from RSA-itis. It will support either PEM or PKCS-7 key | certificates, so I think ends up being pretty much the same as SSL in | this regard. Actually, it also supports Kerberos (not relevant to most of us), and PGP messaging. Although a KCA would be needed before anything useful came of the PGP support, at least its there. However, right now, there are few real alternatives to RSA based schemes. Has anyone looked deeply at SLED's procedures for key authentication? Adam
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?
Perry writes:
The relevance for Cypherpunks interested in writing code is that, in my carefully considered opinion, writing for Netscape and other Web browsers is the Big Win. Even over Windows (except Windows browsers, of course).
Netscape is a closed system. You can't write code for it unless you work for Netscape.
Perry
I concur with everything you said Perry. However, it may be possible to write code "for netscape". If their NSAPI (control the browser remotely via message/event passing) allows full control, you could probably hook into the crypto functions. If not, you could always generate forms and html pages on the fly with the data you want to send, and force the browser to submit them. If the other end has an SHTTP/SSL enabled server, it will be sent encrypted. It's a yucky solution. If Netscape incorporates *full* hotjava capability (like defining new protocol handlers such as SECURE://), then that would be much better. I have some doubts that Netscape will implement all the Hotjava functionality when they incorporate Java because it would allow people to change the look-and-feel (and functionality) of the browser too much, and also because they would have to softcode (in java), a lot of the functionality they have hardcoded right now. Browsers are beginning to become like emacs. Virtual operating systems unto themselves. -Ray
participants (7)
-
Adam Shostack -
chen＠intuit.com -
Enzo Michelangeli -
Hal -
Perry E. Metzger -
Ray Cromwell -
tcmay＠sensemedia.net