[10662] in bugtraq
Re: ICSA - Certified Sites and Criteria Issues
daemon@ATHENA.MIT.EDU (Lucky Green)
Thu May 27 19:45:53 1999
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <001601bea895$883c4fc0$0200a8c0@cypherpunks.to>
Date: Thu, 27 May 1999 16:06:17 -0700
Reply-To: Lucky Green <shamrock@NETCOM.COM>
From: Lucky Green <shamrock@NETCOM.COM>
X-To: Jon McCown <jmccown@icsa.net>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <00e201bea87d$7fdb2800$330a1aac@straylight.icsa.net>
> From: Jon McCown [mailto:jmccown@icsa.net]
> In this context _is_ possible for a customer to mandate (via their
> own policy) use of whatever levels of cryptography they view as being
> appropriate to their business model and customer requirements. For
> example, if a customer policy specifies 128-bit TLS,
> client-certificates, and token-based auth-- they will be validated at
> that level. And if validating the server's identity to the end-user,
> or no-hassle compatibility with zillions of consumers' bargain-club-PC
> 40-bit browsers is a goal-- a different policy might well result.
Now I am really getting worried. From your post it is clear that you, a
representative of ICSA, are unaware that by enabling 128 bit TLS/SSL on a
server you by no means prevent users limited to 40 bit crypto from accessing
it.
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.
The site certified by ICSA did not support 128 bit crypto even to browsers
that support it. Which is, IMHO, unacceptable for a site that had their
security checked by an audit.
--Lucky
