Re: TWO WEEK LAST CALL: Regularizing Port Numbers for SSL.

David P. Kemp wrote:
> 
> > From: Tom Weinstein <tomw@netscape.com>
> >
> > I also object to trying to do SSL and non-SSL on the same port for
> > security reasons.  It adds another level of complexity to making sure
> > you don't get rolled back to an insecure state.
> 
> Will Netscape's browser process URLs of the forms https://foo.com:80
> (resulting in an SSL connection on port 80) and http://foo.com:443
> (resulting in an HTTP connection on port 443), and can Netscape's
> servers be configured to do an SSL listen on 80 and an HTTP listen on 443?
> 
> I believe the answers are all "yes".
> 
> Thus the port numbers have nothing to do with security, they are just
> a convention that facilitates interoperability without having to look at
> the bitstream to guess which protocol is being used.
> 
> If you configure a server/browser to only do SSL with only the SSL
> versions and ciphersuites that meet your security requirements, then
> you can't be rolled back into "an insecure state" (i.e. a connection
> using a protocol or ciphersuite that does not satisfy your security
> policy).  Port numbers have nothing to do with it.

I should let Tom defend his own statement, but ...

What Tom was referring to is trying to use a single port number and
determining through some lazy evaluation function whether or not the
association was secure. This is probably doable for new protocols, but
deserves some serious consideration that has not yet been performed. It
is not realistic for existing protocols.

The fact that a Netscape's product is capable of running a secure
service on port 80 and a non-secure service on port 443 (or any port
imaginable) is not relevant. Try sending SSL protocol to port 80 when
port 80 hasn't been configured to be secure. That will not work. The
assumption is that the port number used for rendezvous has been
negotiated using some alternate protocol to define a protocol stack that
possess compatible if not identical layers. The default values and
associated protocol stacks is what the original message in this thread
was about, and the result will satisfy the "some alternate protocol"
requirement.
-- 
Alan O. Freier               Corporate Cynic
<freier@netscape.com>        (415) 937-3638 (work)

Received on Wednesday, 5 February 1997 13:56:12 UTC