IP: Re: US Majority Leader's Statement vs. GOP.COM

[Dave Farber <farber@cis.upenn.edu>]

>To: "John W. Lemons III" <jlemons@alpha1.net>
>cc: privacy@vortex.com, freematt@coil.com, lauren@pfir.org, jwarren@well.com,
>    farber@cis.upenn.edu, neumann@pfir.org, lauren@vortex.com
>Subject: Re: US Majority Leader's Statement vs. GOP.COM
>Date: Fri, 23 Jun 2000 12:29:38 PDT
>From: Lauren Weinstein <lauren@vortex.com>
>
>Today's update discusses the problems with that Web site page in
>more detail.  I've included it below.
>
>--Lauren--
>
>
>                         PRIVACY Forum Update
>                         --------------------
>                            June 23, 2000
>
>
>           More on GOP.COM and Complexity in Security Systems
>
>                     -----------------------------
>
>Greetings.  In yesterday's (22 Jun 2000) PRIVACY Forum Bulletin, I reported
>on a credit card submission Web page:
>
>    http://www.gopnet.com/MemberLogin.asp?Call=/mygop/mygop.asp
>
>whose security status showed "insecure" (no "lock" icon in Internet Explorer,
>an open "lock" icon from Netscape browsers).  Most Web users are now
>familiar with these icons, which provide the status information that can be
>used (in conjunction with the additional data available through the browsers
>at that point) to verify the identity of a site and to determine the
>security status of pages and the information that may be submitted via forms
>on those pages.  Due to a continuing series of security bugs in popular Web
>browsers, it has become a standard security recommendation for users to
>review that security information (which includes viewing the Secure Sockets
>Layer certificate for detailed security data and identity) *before*
>submitting information on such forms.
>
>The main point of yesterday's bulletin was that these systems are complex
>and easy to misconfigure, and that this demonstrates the risks inherent in
>rushing towards the implementation of broader electronic signature and
>document systems.
>
>Upon continuing investigation, it turns out that this case is an even better
>example of this complexity than I originally realized.  Analysis of the raw
>source code of the page referred to above reveals that the form in question
>was indeed apparently sent to a secure server (and so would presumably have
>its data protected with some level of security), but this fact would not be
>apparent without such source code analysis, and verification of site
>identity and security levels could not be conducted in any normal way
>by users *prior* to their submitting data via the form.
>
>This appears to be an unusual and confusing configuration, since the
>security status of the forms themselves as received by users are typically
>the only information users have to make these important security decisions
>*before* submitting their personal information.  In fact (as I mentioned
>yesterday) at the same site there are other pages which are secured in the
>typical manner which allows users to fully interrogate their security status
>prior to sending their personal data.  It's critical that sites handling
>such data not only be secure, but that they be configured in ways that
>clearly indicate to users their actual, verifiable security status, and that
>allow ordinary users to completely authenticate sites' identity and page
>security levels prior to submitting any personal information via those
>pages.  Anything less can foster poor security practices by users in
>general, which leaves them vulnerable to all manner of potential security
>and privacy problems as they travel around the Web.
>
>The complexity of these systems, and the various ways in which they can be
>misconfigured in incorrect or confusing manners, should act as a clear
>warning that we may be too rapidly moving to deploy mission-critical
>applications in what is still a very new environment!
>
>--Lauren--
>Lauren Weinstein
>lauren@pfir.org or lauren@vortex.com
>Co-Founder, PFIR: People for Internet Responsibility - http://www.pfir.org
>Moderator, PRIVACY Forum - http://www.vortex.com
>Member, ACM Committee on Computers and Public Policy