Re: SSL - Different procedures to authenticate Server and Client

["Jason Coombs PivX Solutions" <jasoncoombs () tmo blackberry net>]

During session key generation and exchange it is proved that the public key offered by the server is the correct one 
that corresponds to the server's private key because the server is able to decrypt the ciphertext received from the 
client during (and after) session key exchange.

Successful key exchange and the commencement of symmetric encryption using that key thus has implicitly verified the 
server's digital signature.

The client, should it offer a public key of its own, does so only for authentication and not for the purpose of 
enhancing privacy or facilitating the start of shared secret key symmetric encryption. Thus there is a step similar to 
session key exchange whereby the server must verify that the client is in possession of the private key that 
corresponds to its proffered public key.

It looks more explicitly like digital signature verification because it is. However, the real point is just to 
establish proof that the private key is in the possession of the other party, and explicit client digital signature 
verification is no better than the proof we already have after key exchange completes that the server is in possession 
of its private key.

The cryptographic transformation required to do digital signature verification (private key used to encrypt a value 
such as a hash of a known value, public key used to decrypt the hash and the hash regenerated then compared) is also 
more burdensome than session key exchange, so adding it as another step rather than just verifying FQDN matches that 
which is expected based on the content of the server's certificate (whose digital signatures are also validated, 
remember) is unnecessary duplicate proof of possession of the private key we already know the server has in its 
possession.

The client should, however, do more sanity checking when it comes to remembering the public key it previously accepted 
and trusted so that a different key offered in the future by the same server, with a different certificate chain 
attached, can prompt careful examination of the server certificate by a cautious and properly-educated end user.

Most Secure Regards,

Jason Coombs
Director of Forensic Services
PivX Solutions, Inc.
http://www.PivX.com/forensics


-----Original Message-----
From: Paulo Wilbert <pwilbert () uninet com br>
Date: 10 Sep 2004 00:27:20 
To:security-basics () securityfocus com
Subject: SSL - Different procedures to authenticate Server and Client



Hi Folks,

Why in SSL the procedure to authenticate the Client (see 
below) is not the same to authenticate the Server (see 
below)? 

Client Authentication: "Does the user's public key 
validate the user's digital signature? The server checks 
whether the user's digital signature can be validated with 
the public key in the certificate. If so, the server has 
established that the public key asserted to belong to the 
user matches the private key that is used to create the 
signature and that the data has not been tampered with 
since it was signed"

Server Authentication: "Does the domain name in the 
server's certificate match the domain name of the server 
itself? This step confirms that the server is actually 
located at the same network address that is specified by 
the domain name in the server certificate. Although step 4 
is not technically part of the SSL protocol, it provides 
the only protection against a form of security attack 
known as a "Man-in-the-Middle Attack." Clients must 
perform this step and must refuse to authenticate the 
server or establish a connection if the domain names do 
not match. If the server's actual domain name matches the 
domain name in the server certificate, the client goes on 
to step 5."

Thanks,

Paulo.






---------------------------------------------------------------------------
Computer Forensics Training at the InfoSec Institute. All of our class sizes
are guaranteed to be 12 students or less to facilitate one-on-one
interaction with one of our expert instructors. Gain the in-demand skills of
a certified computer examiner, learn to recover trace data left behind by
fraud, theft, and cybercrime perpetrators. Discover the source of computer
crime and abuse so that it never happens again.

http://www.infosecinstitute.com/courses/computer_forensics_training.html
----------------------------------------------------------------------------


---------------------------------------------------------------------------
Computer Forensics Training at the InfoSec Institute. All of our class sizes
are guaranteed to be 12 students or less to facilitate one-on-one
interaction with one of our expert instructors. Gain the in-demand skills of
a certified computer examiner, learn to recover trace data left behind by
fraud, theft, and cybercrime perpetrators. Discover the source of computer
crime and abuse so that it never happens again.

http://www.infosecinstitute.com/courses/computer_forensics_training.html
----------------------------------------------------------------------------