[10670] in bugtraq

home help back first fref pref prev next nref lref last post

Re: ICSA - Certified Sites and Criteria Issues

daemon@ATHENA.MIT.EDU (Jeremey Barrett)
Fri May 28 16:35:43 1999

Mail-Followup-To: BUGTRAQ@netspace.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-Id: <19990528134830.I555@jfm.net>
Date: 	Fri, 28 May 1999 13:48:30 -0500
Reply-To: Jeremey Barrett <jeremey@TERISA.COM>
From: Jeremey Barrett <jeremey@TERISA.COM>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To:  <m27lptecaj.fsf@hartley.ecs.soton.ac.uk>; from Simon Liddington
              on Fri, May 28, 1999 at 11:09:08AM +0100

On Fri, May 28, 1999 at 11:09:08AM +0100, Simon Liddington wrote:
> Lucky Green <shamrock@NETCOM.COM> writes:
>
> > Sure, a server can be specifically configured to not allow access by 40 bit
> > browsers, but the overwhelming majority of 128 bit capable websites support
> > both 128 and 40 bit crypto and will automatically use the highest strength
> > supported by the browser. No incompatibility issues are introduced by
> > enabling full-strength crypto.
>
> In my experience with Netscape and apache-SSL the lowest strength
> cipher (apart from no cipher at all) is used. Unless you disable the
> weaker ciphers in Netscape, netscape tries them first and will connect
> if the server allows them.

A client in SSL sends all its supported ciphers at once, it doesn't "try"
some, then "try" others. The server chooses which cipher to use from amongst
those the client supports. If you have 128-bit capable Netscape, and 128-bit
capable Apache SSL, or a Netscape server, or Stronghold, or whatever, you get
full strength crypto, unless there's a bug in the server.

Obviously if one or the other doesn't support it, you don't.

Regards,
Jeremey.
--
Jeremey Barrett <jeremey@terisa.com>
GPG fingerprint = 7BB2 E1F1 5559 3718 CE25 565A 8455 D60B 8FE8 B38F

home help back first fref pref prev next nref lref last post