1997-01-20 - Server Authentication

Header Data

From: Jim Choate <ravage@EINSTEIN.ssz.com>
To: cypherpunks@toad.com
Message Hash: 293d54e254ccd1421764b2cff353806debfa8ad53ea3e82ebe3c9dcb69062516
Message ID: <199701202249.QAA03591@einstein>
Reply To: N/A
UTC Datetime: 1997-01-20 22:42:46 UTC
Raw Date: Mon, 20 Jan 1997 14:42:46 -0800 (PST)

Raw message

From: Jim Choate <ravage@EINSTEIN.ssz.com>
Date: Mon, 20 Jan 1997 14:42:46 -0800 (PST)
To: cypherpunks@toad.com
Subject: Server Authentication
Message-ID: <199701202249.QAA03591@einstein>
MIME-Version: 1.0
Content-Type: text



Forwarded message:

 Forwarded message:
 
> Date: Mon, 20 Jan 1997 09:26:05 -0800 (PST)
> From: Eric Murray <ericm@lne.com>
> Subject: Re: Server Authentication
> 
> I think that you can get access to the server's certificate.
> I know you can from the CGI interface.  Unfortunately it's the
> raw ASN.1 encoded certificate, so you would have to ASN.1 decode it.
> Bleah.
> 
> If the SSL handshake completes, then you can assume that the client
> has verified and authenticated the server certificate.   The only problem
> would be that the authentication might not be up to the plugin's standards-
> i.e.  a connection to www.foo.com is somehow intercepted by
> www.ripoff-plugins.com.  The server www.ripoff-plugins.com presents a cert
> who's name is www.foo.com.  The browser correctly presents a pop-up dialog
> noting the discrepancy, and the luser operating the client clicks
> on the 'OK' button, allowing the SSL handshake to finish.  Oops.
 
Isn't LDAP v3 supposed to answer some of these questions related to server
authentication as well anonymity of the users site (if desired)?
 
                                                 Jim Choate
                                                 CyberTects
                                                 ravage@ssz.com
 
 





Thread