1 / 27

Previous lecture

Previous lecture. Certificates and key management Non-interactive protocols PGP SSL/TLS Introduction Phases Commands. This lecture. TLS details Phases Handshake Securing messages What the messages contain Authentication. TLS phases. Handshake Establish connection

bdobbins
Télécharger la présentation

Previous lecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Previous lecture • Certificates and key management • Non-interactive protocols • PGP • SSL/TLS • Introduction • Phases • Commands Mårten Trolin

  2. This lecture • TLS details • Phases • Handshake • Securing messages • What the messages contain • Authentication 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 Mårten Trolin

  4. ClientHello ClientHello ServerHello ServerKeyExchange Certificate ServerHelloDone ClientKeyExchange ChangeCipherSpec Finished ChangeCipherSpec Finished TLS Handshake Server Client 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. Mårten Trolin

  6. ClientHello ServerHello ServerHello ServerKeyExchange ServerKeyExchange Certificate Certificate ServerHelloDone ServerHelloDone ClientKeyExchange ChangeCipherSpec Finished ChangeCipherSpec Finished TLS Handshake Server Client 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 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. 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. 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. Mårten Trolin

  11. ClientHello ServerHello ServerKeyExchange Certificate ServerHelloDone ClientKeyExchange ClientKeyExchange ChangeCipherSpec ChangeCipherSpec Finished Finished ChangeCipherSpec Finished TLS Handshake Server Client 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. 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. Mårten Trolin

  14. ClientHello ServerHello ServerKeyExchange Certificate ServerHelloDone ClientKeyExchange ChangeCipherSpec Finished ChangeCipherSpec ChangeCipherSpec Finished Finished TLS Handshake Server Client Mårten Trolin

  15. ChangeCipherSpec and Finished • The server’s ChangeCipherSpec and Finished messages play the same role as the client’s message. 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. Mårten Trolin

  17. TLS Handshake with client authentication ClientHello ServerHello Certificate CertificateRequest ServerKeyExchange ServerHelloDone Certificate ClientKeyExchange CertificateVerify ChangeCipherSpec Finished ChangeCipherSpec Finished Client Server 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. 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. 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. 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. 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. 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. 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. 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) 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! 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. Mårten Trolin

More Related