> Eric Murray wrote:
> >
> > On Sat, Dec 02, 2000 at 01:28:02AM +0800, Ng Pheng Siong wrote:
> > > On Thu, Nov 30, 2000 at 01:16:31PM -0800, Eric Murray wrote:
> > > > Either don't connect from a non-SSL client, or connect and negotiate
> > > > when to start SSL. The former is prefered.
> > >
> > > Eh? I'd imagine "the latter is preferred"?
> >
> > My reasoning is that an active attacker could change the bytes in
> > the insecure protocol to silently prevent it from negotiating to SSL.
> > If your protocol only works under SSL, then that's not possible.
>
> The IETF doesn't agree.
The reasoning from the IETF is twofold:
(1) we don't have enough port numbers to assign every protocol both
a non-SSL and a SSL port
(2) If the client or server are configured to require secure
connections it is easy to determine if the peer refuses to
negotiate SSL or if the SSL negotiation fails. In that case
the worst the attacker has done is create a denial of service
attack.
> Also, the way to address this is to configure the server to refuse to do
> stuff that should be secured over an insecure connection.
Several rules:
(1) do not assume that data sent over the wire prior to authentication
and encryption (ie, SSL) are trustworthy
(2) do not perform negotiations for features over the insecure link
that might provide data to an attacker as to the identity of the
user or what she wants to do; or to the services offered by the
server. For example, in Telnet do not send any subnegotiation
data for Character Sets, Environment variables, Window Size,
X Windows data, ... over the insecure link if security
negotiations are pending.
(3) when the secure link is established forget everything that was
learned prior to its establishment. Renegotiate all options.
The option list for the secure link may not match the option list
for the insecure list.
(4) if the SSL handshake fails, the client and server must drop
the connection immediately upon detection of the failure. If
the use of SSL is optional for the client, the client may
reconnect and retry, declining to negotiate the use of SSL.
(5) if security is required by either peer and negotiations to use
SSL are declined, the connection is to be dropped immediately.
Jeffrey Altman * Sr.Software Designer
The Kermit Project * Columbia University
612 West 115th St * New York, NY * 10025 * USA
http://www.kermit-project.org/ * [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
