Date: Wed, 17 Dec 1997 00:03:19 -0700 (MST) From: Marc Slemko <marcs@znep.com> To: Charles Mott <cmott@srv.net> Cc: chat@FreeBSD.ORG Subject: Re: Support for secure http protocols Message-ID: <Pine.BSF.3.95.971216234716.18840T-100000@alive.znep.com> In-Reply-To: <Pine.BSF.3.96.971216224301.6411C-100000@darkstar.home>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 16 Dec 1997, Charles Mott wrote: > > Using ssh doesn't avoid copyright issues, unless you are referring only to > > the protocol. > > > > Using ssh doesn't avoid export restrictions; just because it is available > > (or orginated) around the world doesn't mean it can be exported from the > > US. > > If it is readily available, why does it have to be exported? Software > which is sold can be separated from encryption. Overseas setup is a > secondary issue. Clients can be designed to invoke ssh without actually > having to be bundled with ssh. In general, that is not a good assumption to make. The Apache-SSL patches contain no encryption code (but just hooks to call SSLeay stuff) but still face export restrictions. At one point, PGP support (PEM hooks) was in NCSA (and Apache); no crypto code, just hooks for it. It had to be removed by order of the NSA due to export restrictions. If you can make the hooks general enough it can be done, however if you want to advertise them for the purpose of adding encryption, etc. that just doesn't work. In any case, few commercial applications find it acceptable to have to hunt down and install some other outside package just to work. You also need ssh licenses. > > Using ssh doesn't let you use any current browser without setup hassles. > > Any solution needs integration. > > Point the browser to http://localhost:port to start out with, but this is > a setup hassle to start out with as you point out. It would be nice to > have browsers which could point to an http_ssh://<remote_addr> or > ftp_ssh://<remote_addr>, though. But then browser standards have been > ceded to Microsoft and Netscape, so such a thing could never or happen (or > could it?). It could if it made sense. But it really doesn't. > > If one thinks of http as the greatest achievement of mankind and that no > other server protocols will come into existence, then I think that putting No, the correct thought is that HTTP is the worst achievement of mankind and therefore no other protocols will exist. > alot of effort into https (or is it shttp?) makes sense. But suppose one > wants to generate procedures for having automatic encryption of any non-IP > encoding protocol, then I think building ssh hooks into new applications > may actually make sense. IPsec is really the solution to a more generic solution. I don't see any room for a hack like this between the two, except in very specialized situations. [...] > Still, I see ssh as the best way to start separating applications from > crypotography. A lot of work is going into IPsec. Commercial and non-commercial implementations are available, although somewhat lacking in key management. That is a far better solution.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.971216234716.18840T-100000>