Atonomy of-a-tls-handshake-mini-conferentie
•Télécharger en tant que PPTX, PDF•
0 j'aime•53 vues
What happens, exactly, when you connect to a server using https? In this session, we'll explore the SSL/TLS protocol at the byte level, look at non-mutual and mutual TLS, and where to look when you have a connection problem.
Recommandé
Recommandé
Contenu connexe
Similaire à Atonomy of-a-tls-handshake-mini-conferentie
Similaire à Atonomy of-a-tls-handshake-mini-conferentie (20)
Plus de Michel Schudel
Plus de Michel Schudel (16)
Dernier
Dernier (20)
Atonomy of-a-tls-handshake-mini-conferentie
- 2. Ever wondered what goes on when you type https://www.google.com/ Inside your browser’s adress bar?
- 3. HTTPS Is the application of TLS (Transport Layer Security) on the http protocol TLS is (a set) of procotol(s) that facilitate secure communication between computers https://datatracker.ietf.org/doc/html/rfc5246
- 4. SSL /TLS history • 1995: SSL (Secure Socket Layer) 1.0 • 1998: TLS (Transport Security Layer) 1.0 • 2006 TLS 1.1 • 2008: TLS 1.2 • Support for more secure hashes • 2018: TLS 1.3 A protcol to ensure secure communication over unsecure channels
- 5. …but people still talk about SSL, mutual SSL etc? It’s actually TLS now, but SSL is the name people are used to
- 6. Symmetric encryption Asymmetric encryption Hashing Types of encryption
- 7. Basic steps connecting with https • Client sends encryption (cipher) options and random data • Server sends chosen cipher, random data and its certificate • Both parties generate exchange asymmetric keys • Both parties calculate symmetric keys using the asymmetric keys • Data exchange happens using symmetric encryption! (why?)
- 8. https://www.cryptologie.net/article/340/tls-pre-master-secrets-and-master-secrets/ • Diffie-Hellman • RSA Send certificate Encrypt with Public key / DH Decrypt with Private key /DH Generate symmetric key Generate symmetric key AES Encryption AES Encryption HTTPS Validate certificate Check digital signature
- 10. Server Client “Client Hello” 16 03 03 00 a5 01 00 00 a1 03 03 03 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 00 00 20 cc a8 cc a9 c0 2f c0 30 c0 2b c0 2c c0 13 c0 09 c0 14 c0 0a 00 9c 00 9d 00 2f 00 35 c0 12 00 0a 01 00 00 58 00 00 00 18 00 16 00 00 13 65 78 61 6d 70 6c 65 2e 75 6c 66 68 65 69 6d 2e 6e 65 74 00 05 00 05 01 00 00 00 00 00 0a 00 0a 00 08 00 1d 00 17 00 18 00 19 00 0b 00 02 01 00 00 0d 00 12 00 10 04 01 04 03 05 01 05 03 06 01 06 03 02 01 02 03 ff 01 00 01 00 00 12 00 00 Record header • 16 - type is 0x16 (handshake record) • 03 03 - protocol version is 3.3 (also known as TLS 1.2) • 00 a5 - 0xA5 (165) bytes of handshake message follows Handshake header • 01 - handshake message type 0x01 ("client hello") • 00 00 a1 - 0xA1 (161) bytes of client hello follows Client version • 03 03 - protocol version is 3.3 (also known as TLS 1.2)
- 11. Server Client “Client Hello” 16 03 03 00 a5 01 00 00 a1 03 03 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 00 00 20 cc a8 cc a9 c0 2f c0 30 c0 2b c0 2c c0 13 c0 09 c0 14 c0 0a 00 9c 00 9d 00 2f 00 35 c0 12 00 0a 01 00 00 58 00 00 00 18 00 16 00 00 13 65 78 61 6d 70 6c 65 2e 75 6c 66 68 65 69 6d 2e 6e 65 74 00 05 00 05 01 00 00 00 00 00 0a 00 0a 00 08 00 1d 00 17 00 18 00 19 00 0b 00 02 01 00 00 0d 00 12 00 10 04 01 04 03 05 01 05 03 06 01 06 03 02 01 02 03 ff 01 00 01 00 00 12 00 00 Client Random 32 bytes of random data
- 12. Server Client “Client Hello” 16 03 03 00 a5 01 00 00 a1 03 03 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 00 00 20 cc a8 cc a9 c0 2f c0 30 c0 2b c0 2c c0 13 c0 09 c0 14 c0 0a 00 9c 00 9d 00 2f 00 35 c0 12 00 0a 01 00 00 58 00 00 00 18 00 16 00 00 13 65 78 61 6d 70 6c 65 2e 75 6c 66 68 65 69 6d 2e 6e 65 74 00 05 00 05 01 00 00 00 00 00 0a 00 0a 00 08 00 1d 00 17 00 18 00 19 00 0b 00 02 01 00 00 0d 00 12 00 10 04 01 04 03 05 01 05 03 06 01 06 03 02 01 02 03 ff 01 00 01 00 00 12 00 00 Cipher suites • 00 20 - 0x20 (32) bytes of cipher suite data • cc a8 - assigned value for TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 • cc a9 - assigned value for TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 • c0 2f - assigned value for TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 • c0 13 - assigned value for TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
- 13. C0 13 - Selected Cipher Suite (TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) Elliptic Curve, Diffie-Hellman Exhange Symmetric Cipher Asymmetric Cipher Hashing Algorithm
- 17. Server Client “Client Hello” 16 03 03 00 a5 01 00 00 a1 03 03 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 00 00 20 cc a8 cc a9 c0 2f c0 30 c0 2b c0 2c c0 13 c0 09 c0 14 c0 0a 00 9c 00 9d 00 2f 00 35 c0 12 00 0a 01 00 00 58 00 00 00 18 00 16 00 00 13 65 78 61 6d 70 6c 65 2e 75 6c 66 68 65 69 6d 2e 6e 65 74 00 05 00 05 01 00 00 00 00 00 0a 00 0a 00 08 00 1d 00 17 00 18 00 19 00 0b 00 02 01 00 00 0d 00 12 00 10 04 01 04 03 05 01 05 03 06 01 06 03 02 01 02 03 ff 01 00 01 00 00 12 00 00 DER extensions • Signature algorithms • Renegotiation info • EC Point formats • Supported Groups • Server name
- 18. Server Client “Server Hello” 16 03 03 00 31 02 00 00 2d 03 03 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f 00 c0 13 00 00 05 Server Random 32 bytes of random data Chosen cipher suite (TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256)
- 19. Server Client “Server Certificate” Client verifies this certificate using its truststore
- 21. Server Client “Server Key Exchange” • Record Header • Handshake Header (0c == server key exchange) • Curve info: curve x25519 • Public key: 32 bytes (NOT the certificates public key but an Ephemeral key) • Signature: signed data with certificate’s private key consisting of: • client_hello_random • server_hello_random • curve_info (curve x25519) • public_key (above) Generate private / public key pair Private key: 490AF345983BC405989052850984324 Public key: 655894509864096t5860985230958093
- 22. Server Client “Server Hello done” • Record Header • Handshake Header (0e == server hello done)
- 23. Now, it’s the client’s turn
- 24. Server Client “Client Key Exchange” • Record Header • Handshake Header (10 == client key exchange) • Public key: 32 bytes (NOT the certificates’ public key but an Ephemeral (or volatile) key) Generate private / public key pair
- 25. Server Client Encryption keys calculation Using: • server random (from Server Hello) • client random (from Client Hello) • server public key (from Server Key Exchange) • client private key (from Client Key Generation) PreMasterSecret = (server public key * client private key) MasterSecret = x Client will generate the following values: •client MAC key: 1b7d117c7d5f690bc263cae8ef60af0f1878acc2 •server MAC key: 2ad8bdd8c601a617126f63540eb20906f781fad2 •client write key: f656d037b173ef3e11169f27231a84b6 •server write key: 752a18e7a9fcb7cbcdd8f98dd8f769eb •client write IV: a0d2550c9238eebfef5c32251abb67d6 •server write IV: 434528db4937d540d393135e06a11b
- 26. Server Client Using: • server random (from Server Hello) • client random (from Client Hello) • client public key (from Client Key Exchange) • server private key (from Server Key Generation) (Pre)MasterSecret = (client public key * server private key) Client will generate the following values: •client MAC key: 1b7d117c7d5f690bc263cae8ef60af0f1878acc2 •server MAC key: 2ad8bdd8c601a617126f63540eb20906f781fad2 •client write key: f656d037b173ef3e11169f27231a84b6 •server write key: 752a18e7a9fcb7cbcdd8f98dd8f769eb •client write IV: a0d2550c9238eebfef5c32251abb67d6 •server write IV: 434528db4937d540d393135e06a11b •client MAC key: 1b7d117c7d5f690bc263cae8ef60af0f1878acc2 •server MAC key: 2ad8bdd8c601a617126f63540eb20906f781fad2 •client write key: f656d037b173ef3e11169f27231a84b6 •server write key: 752a18e7a9fcb7cbcdd8f98dd8f769eb •client write IV: a0d2550c9238eebfef5c32251abb67d6 •server write IV: 434528db4937d540d393135e06a11b Encryption keys calculation
- 27. Server Client “Change Cipher Spec” 14 03 03 00 01 01 Change Cipher Spec, all subsequent messages will be encrypted
- 28. Server Client “Handshake finished” • Record header (16) • Client write IV • Encrypted Data • Hash of all handshake messages • Encrypted by symmetric client write key (AES128-CBC) Server can use this to verify if the generated keys are actually correct
- 29. Electronic CopyBook Encryption (ECB) MiniConf MiniConf MiniConf 12345678 12345678 12345678
- 31. Server Client “Change Cipher Spec” 14 03 03 00 01 01 Change Cipher Spec, all subsequent messages will be encrypted
- 32. Server Client “Handshake finished” Client can use this to verify if the generated keys are actually correct • Record header (16) • client write IV • Encrypted Data • Hash of all handshake messages • Encrypted by symmetric server write key (AES128-CBC)
- 34. Server Client “Application Data” • Record header (17 – application data) • Client write IV • Encrypted Data (CBC) “Ping” “0034F527AF085A” “Ping” Encrypt using client write key Decrypt using client write key
- 35. Server Client “Application Data” • Record header (17 – application data) • Server write IV • Encrypted Data “Pong” “1243FBC38F4E2A” “Pong” Decrypt using Server write key Encrypt using Server write key
- 37. Server Client “Server Certificate” Client verifies this certificate using its truststore So what happens when using mutual SSL?
- 38. Server Client “Client Certificate” Server verifies this certificate using its truststore So what happens when using mutual SSL?
- 39. Common errors and solutions
- 41. Exception in thread "main" javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure Common problems Either the client did not receive a certifcate, or the server did not receive the client’s certificate Make sure both sides have a configured keystore and a configured certificate alias
- 42. Exception in thread "main" javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target Common problems The certificate is self signed, or the certificate’s CA is not in the truststore Have a trust store that contains the certifcate’s CA
- 43. Exception in thread "main" java.net.SocketException: Software caused connection abort: recv failed Common problems In mutal SSL / TLS, the client certificate is not set up Configure a keystore on the client containing the correct certificate
- 44. Exception in thread "main" javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No name matching (localhost) found Common problems The client received a certificate with a CN that does not match the server’s domain The server should a certificate with installed that matches the domain.
- 45. Exception in thread "main" javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate) Common problems The client and server do not support at least one single protocol version or share at least one cipher suite The client and server should have common protocols and cipher suites configured.
- 47. @MichelSchudel
Notes de l'éditeur
- Modern cryptograph y can be split into two kinds: symmetric encryption, which we will see in a bit, en asymmetric encryption, also know as public-key cryptography. Both have different properties, advantages and disadvantages, and applications.
- So here it all comes together! The server sends its certificate to the client, which will check the authentiity of it by verifying the digital signature using the public key of the CA certificate in it’s root store. The client now generates a random secret number (the pre master secret) and encrypts it using the servers’public key. The secret number is decrypted by the server, and both client and server use the selected cipher to generate a key
- One thing we haven’t talked about: how to exchange secret keys? You could try to exhange them in bags, diplomatic posts… but maybe there’s a better way!
- So, in 1976, these two Cryptographers, Martin Hellman and Whitfield Diffie, found a way to get a secret key to both parties over an unsecure channel while both parties are completely safe from eavesdroppers. They won the Turing award in 2015, almost 40 years too late if you ask me. Their solution is briljant in its simplicity.
- This is called the Diffie-Hellman key exchange, and is an example of asymmetric encryption. (explain) so this is briljant, and is still begin used in the https handshake today, as an option to generate secret keys, as we will see.