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".

Of course the answer is yes.  That's not the issue.  I can also run an
X server on port 25.  The question is: "should I?"  If I run an HTTP
server on port 80, it had better start out talking HTTP.  If I run an
FTP server on port 21, it should talk normal FTP at first.  I don't
think anyone disagrees with this.

The question, then, is do we reserve special ports for protocols that
sit over SSL, or do we try to negotiate up to SSL after connecting to
the normal port?  If we do the later, I get worried about security.

> 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.

-- 
You should only break rules of style if you can    | Tom Weinstein
coherently explain what you gain by so doing.      | tomw@netscape.com

Received on Wednesday, 5 February 1997 14:05:14 UTC