- From: Christian Kuhtz <chk@gnu.ai.mit.edu>
- Date: Thu, 6 Feb 97 13:34:59 -0700
- To: Adam Shostack <adam@homeport.org>
- Cc: Mark Shuttleworth <marks@thawte.com>, Christian Kuhtz <chk@gnu.ai.mit.edu>, Christopher Allen <ChristopherA@consensus.com>, Tim Hudson <tjh@mincom.com>, ietf-tls@w3.org, ssl-talk@netscape.com
Hell, no, not another portmapper ;-). What I had in mind is a generic interface which attempts to negotiate SSL at a given, existing port, in such a way that if it fails it will use non-SSL traditional style, if it succeeds (meaning: the other end is SSL aware), it will initiate an SSL style session. You don't need/want a portmapper to do that. You don't concentrate all SSL services through one multiplexer, but rather multiplex SSL and non-SSL on a per service level. SSL isn't really a new service, it is just a variety of an already existing service. Regards, -- Christian Kuhtz <chk@gnu.ai.mit.edu> ".com is a mistake." On Thu, 6 Feb 1997 07:42:37 -0500 (EST), Adam Shostack <adam@homeport.org> wrote: > A generic adapter piece like portmapper? The problem with > portmapper (and family) is that it makes packet filtering to exclude > protocols very difficult. That requires installing security > configuration tools on every machine on your network that offers any > service over TLS. I don't believe that there are, or will in the near > future be, tool to effectively manage such groupings of connections. > > On another part of the thread, standardizing on 'non-reserved' > ports allows daemon mode implementations to be run as a user without > being called from inetd. If http worked on 8000, then there would be > fewer web servers attempting to run as root, and that would be a > security win. > > Adam > > > -- > "It is seldom that liberty of any kind is lost all at once." > -Hume > > > >
Received on Thursday, 6 February 1997 15:40:51 UTC