Using engine_pkcs11 with openssl and a hardware token like the
Aladdin eToken (using Aladdin's pkcs11 driver), I want to make sure I'm
describing the data flow correctly. In my scenario, the etoken contains
a client certificate. The SSL connection is being opened by a m2crypto
client.
My question is, does the token's PKI engine just do step 5, or does it do the
crypto parts of both 4 and 5? any additional parts of this sequence .?
I cribbed this description of the SSL handshake from Sun's SSL docs as it
was easier for me to follow than the RFC stuff.
1. The client sends the server the client’s SSL version number,
cipher settings, randomly generated data, and other information
the server needs to communicate with the client using SSL.
2. The server sends the client the server’s SSL version number,
cipher settings, randomly generated data, and other information
the client needs to communicate with the server over SSL. The
server also sends its own certificate and, if the client is
requesting a server resource that requires client authentication,
requests the client’s certificate.
3. The client uses some of the information sent by the server to
authenticate the server. If the server cannot be authenticated,
the user is warned of the problem and informed that an encrypted
and authenticated connection cannot be established. If the server
can be successfully authenticated, the client goes on to Step 4.
4. Using all data generated in the handshake so far, the client, with
the cooperation of the server, depending on the cipher being used,
creates the pre-master secret for the session, encrypts it with
the server’s public key, obtained from the server’s certificate,
sent in Step 2.
5. If the server has requested client authentication (an optional
step in the handshake), the client also signs another piece of
data that is unique to this handshake and known by both the client
and server. The client sends both the signed data and the client’s
own certificate to the server along with the encrypted pre-master
secret.
6. If the server has requested client authentication, the server
attempts to authenticate the client. If the client cannot be
authenticated, the session is terminated. If the client can be
successfully authenticated, the server uses its private key to
decrypt the pre-master secret, then performs a series of steps
(which the client also performs, starting from the same
pre-master secret) to generate the master secret.
7. Both the client and the server use the master secret to generate
the session keys, which are symmetric keys used to encrypt and
decrypt information exchanged during the SSL session and to verify
its integrity—that is, to detect changes in the data between the
time it was sent and the time it is received over the SSL connection.
8. The client sends a message to the server informing it that future
messages from the client are encrypted with the session key. It
then sends a separate (encrypted) message indicating that the
client portion of the handshake is finished.
9. The server sends a message to the client informing it that future
messages from the server are encrypted with the session key. It
then sends a separate (encrypted) message indicating that the
server portion of the handshake is finished.
10. The SSL handshake is now complete, and the SSL session has begun.
The client and the server use the session keys to encrypt and
decrypt the data they send to each other and to validate its
integrity.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
