Embed Size (px)
Citation preview
Apr 1, 2003 Mårten Trolin 1
Previous lecture
• Certificates and key management
• Non-interactive protocols– PGP
• SSL/TLS– Introduction
– Phases
– Commands
Apr 1, 2003 Mårten Trolin 2
This lecture
• TLS details– Phases
• Handshake
• Securing messages
– What the messages contain
– Authentication
Apr 1, 2003 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 1, 2003 Mårten Trolin 4
TLS Handshake
Client Server
ClientHello
ServerHello
ServerKeyExchange
ClientKeyExchange
ChangeCipherSpec
Finished
ChangeCipherSpec
Finished
ServerHelloDone
ClientHello
Certificate
Apr 1, 2003 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 1, 2003 Mårten Trolin 6
Certificate
TLS Handshake
Client Server
ClientHello
ServerHello
ServerKeyExchange
ClientKeyExchange
ChangeCipherSpec
Finished
ChangeCipherSpec
Finished
ServerHelloDone
ServerHello
ServerKeyExchange
ServerHelloDone
Certificate
Apr 1, 2003 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 1, 2003 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 1, 2003 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 1, 2003 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 1, 2003 Mårten Trolin 11
TLS Handshake
Client Server
ClientHello
ServerHello
ServerKeyExchange
ClientKeyExchange
ChangeCipherSpec
Finished
ChangeCipherSpec
Finished
ServerHelloDone
ClientKeyExchange
Finished
ChangeCipherSpec
Certificate
Apr 1, 2003 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 1, 2003 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 1, 2003 Mårten Trolin 14
TLS Handshake
Client Server
ClientHello
ServerHello
ServerKeyExchange
ClientKeyExchange
ChangeCipherSpec
Finished
ChangeCipherSpec
Finished
ServerHelloDone
ChangeCipherSpec
Finished
Certificate
Apr 1, 2003 Mårten Trolin 15
ChangeCipherSpec and Finished
• The server’s ChangeCipherSpec and Finished messages play the same role as the client’s message.
Apr 1, 2003 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 1, 2003 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 1, 2003 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 1, 2003 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 1, 2003 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 1, 2003 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 1, 2003 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 1, 2003 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 1, 2003 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 1, 2003 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 1, 2003 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 1, 2003 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.
