Apr 2, 2002 Mårten Trolin 1

Previous lecture

• On the assignment

• Certificates and key management– Obtaining a certificate

– Verifying a certificate

– Certificate chains

• SSL/TLS– Layer between TCP and application protocol

– Phases

– Messages

Apr 2, 2002 Mårten Trolin 2

This lecture

• TLS details– Phases

• Handshake

• Securing messages

– What the messages contain

– Authentication

• The second assignment

Apr 2, 2002 Mårten Trolin 3

TLS phases

• Handshake– Establish connection

– Agree on encryption algorithm

– Exchange key

– Authentication

• Server only or both client and server

• Authentication with certificates

• Securing messages– Sending the actual messages

– Integrity checks with MACs

Apr 2, 2002 Mårten Trolin 4

TLS Handshake

Client Server

ClientHello

ServerHello

ServerKeyExchange

ClientKeyExchange

ChangeCipherSpec

Finished

ChangeCipherSpec

Finished

ServerHelloDone

ClientHello

Certificate

Apr 2, 2002 Mårten Trolin 5

ClientHello

• The client initiates the communication by sending the ClientHello message.

• The message contains– version number

– optional session ID

• used to resume a previous session

– list of cipher suites supported

• The cipher suite includes key exchange algorithm, symmetric algorithm (including chaining mode) and MAC algorithm.

Apr 2, 2002 Mårten Trolin 6

Certificate

TLS Handshake

Client Server

ClientHello

ServerHello

ServerKeyExchange

ClientKeyExchange

ChangeCipherSpec

Finished

ChangeCipherSpec

Finished

ServerHelloDone

ServerHello

ServerKeyExchange

ServerHelloDone

Certificate

Apr 2, 2002 Mårten Trolin 7

ServerHello

• In response to the ClientHello message, the server sends a ServerHello message.

• In this message, the server finally decides which cipher suite to use.

• The ServerHello message contains– version number

– optional session ID

• included if the server allows the client to resume a previous session

– the cipher suite to be used, picked from the list of proposals given by the client

Apr 2, 2002 Mårten Trolin 8

Certificate

• The Certificate message contains the server certificate, including the chain leading up to the CA root certificate.– Optional according to the TLS specifications, but most (all?)

implementations require a server certificate.

– If no certificate is sent, the ServerKeyExchange is required.

Apr 2, 2002 Mårten Trolin 9

ServerKeyExchange

• The ServerKeyExchange message is used for the key exchange.– Includes the server part of the key exchange.

– Exact meaning depends on the cipher suite chosen.

• For RSA, the server’s public key is sent.

• For Diffie-Hellman, the modulus p, the generator g and x = ga is sent.

– Necessary if no public key is sent in the certificate.

• If the information in the certificate can be used for signing, the key information is signed.

Apr 2, 2002 Mårten Trolin 10

ServerHelloDone

• The ServerHelloDone marks the end of the server’s part in the handshake. It does not contain any other information.

Apr 2, 2002 Mårten Trolin 11

TLS Handshake

Client Server

ClientHello

ServerHello

ServerKeyExchange

ClientKeyExchange

ChangeCipherSpec

Finished

ChangeCipherSpec

Finished

ServerHelloDone

ClientKeyExchange

Finished

ChangeCipherSpec

Certificate

Apr 2, 2002 Mårten Trolin 12

ClientKeyExchange

• The ClientKeyExchange message contains the client part in the key agreement.

• The exact format depends on the exchange algorithm agreed on previously– For RSA, the client generates random numbers from which the

symmetric key is derived.

– For Diffie-Hellman, the message contains y = gb, the client’s part in the agreement. From this the symmetric key is extracted.

Apr 2, 2002 Mårten Trolin 13

ChangeCipherSpec and Finished

• Formally a protocol of its own, the ChangeCipherSpec message indicates that from this point, communication is encrypted.

• The Finished message, itself encrypted, marks the end of the handshake. It consists of a hash of the handshake encrypted with the agreed cipher suite.

Apr 2, 2002 Mårten Trolin 14

TLS Handshake

Client Server

ClientHello

ServerHello

ServerKeyExchange

ClientKeyExchange

ChangeCipherSpec

Finished

ChangeCipherSpec

Finished

ServerHelloDone

ChangeCipherSpec

Finished

Certificate

Apr 2, 2002 Mårten Trolin 15

ChangeCipherSpec and Finished

• The server’s ChangeCipherSpec and Finished messages play the same role as the client’s message.

Apr 2, 2002 Mårten Trolin 16

Introducing client authentication

• The TLS specifications allows for client authentication.

• The client authenticates himself with a certificate, just as the server.

• Whether or not client authentication should be used (and what to if it is unsuccessful) is determined by the server.

Apr 2, 2002 Mårten Trolin 17

TLS Handshake with client authentication

Client Server

ClientHello

ServerHello

ServerKeyExchange

ClientKeyExchange

ChangeCipherSpec

ChangeCipherSpec

Finished

ServerHelloDone

Certificate

CertificateRequest

CertificateVerify

Certificate

Finished

Apr 2, 2002 Mårten Trolin 18

CertificateRequest

• If the server wants the client to provide a certificate, the server sends a CertificateRequest message in the handshake.

• The CertificateRequest contains information on which certificates the server accepts.– Types of certificates.

– CA certificates known to the server.

– Using this information, an interactive program can show a list of accepted certificates for the user to choose from.

Apr 2, 2002 Mårten Trolin 19

Certificate

• In response, the client sends his certificate to the server.

• This message has the same format as the corresponding message from the server.– The client certificate, and all certificates in the chain leading up

to the root certificate.

Apr 2, 2002 Mårten Trolin 20

CertificateVerify

• Unless the client can prove that he knows the private key, the certificate is useless. The CertificateVerify message gives this proof.

• CertificateVerify contains a signature with the client private key on the complete handshake.– The server can verify this signature with the public key in the

certificate.

– If this verification is successful, the server knows that the client knows the private key.

Apr 2, 2002 Mårten Trolin 21

Verifying the certificate

• All certificates in TLS are in the X.509 format.

• To verify that a certificate is valid, the verifier must– Check that the CA signature is valid.

– Check that the owner of the certificate knows the private key.

– Check that the identifying information is what it should be.

• The protocol specifies how to perform the first two parts, but the last part is up to the implementation.

Apr 2, 2002 Mårten Trolin 22

Verifying the certificate

• The certificates used in TLS, X.509 certificates, define certain fields.– Algorithm identifier

– Issuer

– Period of validity

– Subject

– Subject’s public key

– Extensions

– Signature by issuer’s private key

• The field named Subject contains information about the owner.

Apr 2, 2002 Mårten Trolin 23

Verifying the certificate – the subject field

• The subject field takes the form of a distinguished name and consists of several elements.– Country

– Province

– Organization

– Common Name

– etc.

• For server certificates, the Common Name field contains the host name of the server, e.g., www.verisign.com.

Apr 2, 2002 Mårten Trolin 24

Certificate contents

• This picture shows how Internet Explorer shows the contents of a certificate.

• Note that the CN field contains the host name of the server.

Apr 2, 2002 Mårten Trolin 25

The subject field, cont.

• The Common Name usually identifies the owner.

• For server certificates for web servers, the web browser checks that the host name the user sees in the address/location field matches the Common Name.

• For client certificates, each implementation must decide a scheme for how to use the identifying information.– Personal number

– User name

– Real name (risk for collisions)

Apr 2, 2002 Mårten Trolin 26

X.509 certificates, cont.

• Version 3 of X.509 certificates introduces certificate extensions.

• Extensions can be used for several purposes, among others to restrict the use of the certificate– Only as server certificate.

– Only as client certificate.

– To sign other certificates (i.e., as a CA certificate).

• When a certificate is verified, it should be verified that it is used for its intended purpose.

• When you create certificates, make sure to indicate the intended use!

Apr 2, 2002 Mårten Trolin 27

Next phase, secure messaging

• After the handshake is complete, the client and the server start exchanging encrypted messages.

• Each message is appended with a MAC before it is encrypted

• The key for encryption, the key for the MAC and the Initialization Vector (if used) is extracted from the key exchange messages.

Apr 2, 2002 Mårten Trolin 28

The assignment

• The task is to create a Certificate Authority– Create a CA certificate and private key

– Create a certificate request

• A private and a public key, with request information

– Sign the certificate request with the server private key

• Use command line openssl for the task. Documentation is available from http://www.openssl.org/docs/apps/openssl.html.

Apr 2, 2002 Mårten Trolin 29

The assignment

• Hand in the solution no later than April 16. For delays, one point per day is deducted from the result.

• Maximum score is four points.

• Hand in the certificates created, and the commands you used to create them, with a short description of each command.

• It is up to you to decide what kind of certificates to create.