wolfSSL and TLS 1.3

The wolfSSL lightweight SSL/TLS library now includes TLS 1.3 support. This slide deck, from a seminar given in Tokyo, Japan, covers the differences in TLS 1.3 and what wolfSSL currently supports.

Transcript

1. Talking about TLS 1.3 Tokyo, Japan September 15, 2017
2. Chris Conlon Engineering Manager, wolfSSL Inc. About Me: - Montana State University (Bozeman, MT, USA) - Software Engineer @ wolfSSL (7 years) Contact Info: - Email: chris@wolfssl.com - Twitter: @c_conlon
3. We Secure the Internet by Securing Data
4. VoIP Smart Grid Cloud Services Automotive / Smart Cars Battlefield Communication Smart Energy Appliances Games Sensors Internet of Things Databases Mobile Phones Printers Applications Connected Home Industrial Automation M2M Routers We Secure the Internet by Securing Data
5. Three Main Areas of Focus Data in Transit Data at Rest Firmware Updates - Secured with SSL/TLS, SSH - Possible Transfer Mediums: TCP/UDP/Bluetooth/Serial/etc - Secured with Cryptography - Secured with SSL/TLS, crypto, MQTT - Prevent malicious firmware flashing and updates
6. Origin of wolfSSL
7. Exciting Company Growth
8. wolfSSL Products
9. wolfSSL Product Licensing Dual Licensed! • Clean room SSL/TLS and Cryptography • wolfSSL owns the Copyright
10. Broad Partner Program
11. • One Week ◦ Port to environment (OS/stack/hardware) ◦ Validation ◦ Unburden your engineers from the details of cryptography ◦ Get your cryptography done right! • Possible uses ◦ Get brought up on a board! ◦ Port to hardware-based cryptography wolfSSL Kickstart Power Program!
12. wolfSSL Library Overview
13. wolfSSL SSL / TLS Library LIGHTWEIGHT. PORTABLE. C-BASED. • Up to TLS 1.3 and DTLS 1.2 • 20-100 kB footprint • 1-36 kB RAM per session • Up to 20X Smaller than OpenSSL • Long list of supported operating systems Windows, Linux, Mac OS X, Solaris, ThreadX, VxWorks, FreeBSD, NetBSD, OpenBSD, embedded Linux, WinCE Haiku, OpenWRT, iPhone (iOS), Android, Nintendo Wii and Gamecube through DevKitPro, QNX, MontaVista, NonStop TRON/ITRON/uITRON, Micrium uC/OS, FreeRTOS, SafeRTOS, Freescale MQX, Nucleus, TinyOS, HP/UX, ARC MQX
14. wolfSSL SSL / TLS Library ADDITIONAL FEATURES • OpenSSL Compatibility Layer • Web Server Integration • Hardware Cryptography Support • NSA Suite-B Compatible • FIPS 140-2 Level 1 Validated Intel (AES-NI, AVX1, AVX2, RDRAND, RDSEED), ARMv8, STM32, NXP mmCAU/CAU/SEC/LTC, Microchip PIC32MZ, Intel QuickAssist, Cavium NITROX
15. wolfCrypt Cryptography Library • Used by wolfSSL for cryptographic operations • Supported Algorithms Include Hash Functions MD2, MD4, MD5, SHA-1, SHA-2, SHA-3, RIPEMD, BLAKE2b Block Ciphers AES, DES, 3DES, Camellia, IDEA Stream Ciphers ARC4, RABBIT, HC-128, ChaCha20 Authenticated Ciphers AES-GCM, AES-CCM, Poly1305 Public Key Options RSA, ECC, DSS, DH, EDH, (Curve25519, Ed25519) Password-based Key Derivation HMAC, PBKDF, PBKDF2
16. • Built for Portability, Modularity, and Performance ◦ 20 times smaller than OpenSSL • Strong Dedication to Testing - Blog Post Link ◦ Internal testing includes: API Unit, Cipher Suite, Algorithm, Benchmark, Static Analysis, Detecting Memory Errors, Interop, Real World Builds, Compiler, Peer Review, Third Party, Fuzz, Continuous Integration, Nightly • Mature & Widely Used: Securing 2 Billion Connections Why wolfSSL?
17. • Commitment to Security and Features: ◦ Progressive Ciphers (Ed/Curve25519, NTRU, etc.) ◦ Hardware crypto integration ◦ Avoiding security threats: ▪ NVD DB: 3yrs - https://web.nvd.nist.gov ▪ wolfSSL (CyaSSL) = 3 issues ▪ OpenSSL = 94 issues • Well Supported: ◦ Core developers, wolfSSL, customers/community Why wolfSSL?
18. • From Our Website ◦ www.wolfssl.com • On GitHub: ◦ github.com/wolfssl/wolfssl Downloading wolfSSL
19. SSL/TLS History and Protocol A little background before we talk TLS 1.3
20. Authentication • Server is typically authenticated by default • Client authentication is optional • Can happen via asymmetric cryptography (RSA, ECSDA) or a pre-shared key (PSK) Confidentiality • Data is only visible to endpoints (client/server) Integrity • Data cannot be modified by attackers Primary Goals of TLS
21. • Taher Elgamal ◦ “Father of SSL” ◦ Netscape (Feb. 1995) SSL : Secure Sockets Layer
22. • Current SSL / TLS / DTLS versions Notes: • SSL 2.0 is insecure • SSL 3.0 is insecure • SSL = “Secure Sockets Layer” • TLS = “Transport Layer Security” • DTLS = “Datagram TLS” What is SSL / TLS?
23. • Protocol Specifications ◦ RFC 6101: SSL 3.0 ◦ RFC 2246: TLS 1.0 ◦ RFC 4346: TLS 1.1 ◦ RFC 5246: TLS 1.2 ◦ “Draft”: TLS 1.3 SSL / TLS History and Protocols
24. • Uses variety of crypto algorithms • A common CIPHER SUITE is negotiated during the SSL Handshake Protocol_keyexchange_WITH_bulkencryption_mode_messageauth TLS_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA Hash Functions SHA, SHA-256, ... Block and Stream Ciphers 3DES, AES, Camellia, ... Public Key Algorithms RSA, ECC, NTRU, ... What is SSL / TLS?
25. • Layered between Transport and Application layers What is SSL / TLS?
26. • TLS (up to 1.2) includes four sub-protocols: 1. Handshake Protocol 2. Change Cipher Spec Protocol 3. Alert Protocol 4. Record Protocol What is SSL / TLS?
27. • Handshake Protocol • Responsible for negotiating a session, includes: ▪ Session identifier ▪ Peer certificate ▪ Compression method ▪ Cipher spec ▪ Master secret ▪ “is resumable” TLS Sub-Protocols
28. • Change Cipher Spec Protocol • Signals transitions in ciphering strategies • Sent by client and server • Notifies receiving party that subsequent records will be protected under newly negotiated CipherSpec and keys TLS Sub-Protocols
29. • Alert Protocol • Convey severity and description of alert • Either “warning” or “fatal” • Fatal results in immediate termination of connection • Encrypted and compressed as per CipherSpec TLS Sub-Protocols
30. • Record Protocol • Layered protocol (Sending Side) ▪ Fragments input data into blocks ▪ (optionally) compresses data ▪ Applies MAC ▪ Encrypts ▪ Transmits the result TLS Sub-Protocols
31. • Record Protocol TLS Sub-Protocols
32. • Record Protocol • Layered protocol (Receiving Side) ▪ Strips TLS record header ▪ Decrypts received data ▪ Verifies data (using MAC) ▪ Decompresses ▪ Reassembles ▪ Delivers result to higher level TLS Sub-Protocols
33. • TLS Record Header Format TLS Sub-Protocols
34. TLS Handshake (up to TLS 1.2)
35. SSL/TLS Handshake • Client Hello ◦ Sent when client first connects to server ◦ Includes: ▪ Protocol version ▪ Client random ▪ Session ID (if resuming) ▪ Cipher suites ▪ Compression method ▪ Extensions Client Hello Server Hello Certificate Server Key Exchange Certificate Request Certificate Client Key Exchange Certificate Verify Change Cipher Spec Finished Change Cipher Spec Finished Server Hello Done Hello Verify Request
36. SSL/TLS Handshake • Client Hello Client Hello Server Hello Certificate Server Key Exchange Certificate Request Certificate Client Key Exchange Certificate Verify Change Cipher Spec Finished Change Cipher Spec Finished Server Hello Done Hello Verify Request
37. SSL/TLS Handshake Client Hello Server Hello Certificate Server Key Exchange Certificate Request Certificate Client Key Exchange Certificate Verify Change Cipher Spec Finished Change Cipher Spec Finished Server Hello Done Hello Verify Request • Hello Verify Request ◦ Sent in response to Client Hello ◦ Sends the stateless cookie to prevent against DDoS attacks ◦ Client should sends another ClientHello back with the same cookie in it
38. SSL/TLS Handshake Client Hello Server Hello Certificate Server Key Exchange Certificate Request Certificate Client Key Exchange Certificate Verify Change Cipher Spec Finished Change Cipher Spec Finished Server Hello Done Hello Verify Request • Server Hello ◦ Sent in response to Client Hello ◦ Only when it can find acceptable set of algorithms ◦ Includes: ▪ Protocol version ▪ Random ▪ Session ID ▪ Cipher Suite ▪ Compression Method ▪ Extensions
39. SSL/TLS Handshake Client Hello Server Hello Certificate Server Key Exchange Certificate Request Certificate Client Key Exchange Certificate Verify Change Cipher Spec Finished Change Cipher Spec Finished Server Hello Done Hello Verify Request • Server Hello
40. SSL/TLS Handshake • Hello Extensions ◦ Signature Algorithms ▪ Which signature/hash pairs may be used ◦ Maximum Fragment Length ▪ Set maximum TLS record fragment size ◦ Several more...
41. SSL/TLS Handshake Client Hello Server Hello Certificate Server Key Exchange Certificate Request Certificate Client Key Exchange Certificate Verify Change Cipher Spec Finished Change Cipher Spec Finished Server Hello Done Hello Verify Request • Server Certificate ◦ Server’s certificate chain ◦ X.509 v3 Certificates ◦ Must be compatible with selected key exchange algorithm ◦ Not sent when using PSK cipher suites ◦ On receiving this message, client validates the certificate chain
42. SSL/TLS Handshake Client Hello Server Hello Certificate Server Key Exchange Certificate Request Certificate Client Key Exchange Certificate Verify Change Cipher Spec Finished Change Cipher Spec Finished Server Hello Done Hello Verify Request • Server Certificate
43. SSL/TLS Handshake Client Hello Server Hello Certificate Server Key Exchange Certificate Request Certificate Client Key Exchange Certificate Verify Change Cipher Spec Finished Change Cipher Spec Finished Server Hello Done Hello Verify Request • Server Key Exchange ◦ Sent when the Certificate message doesn’t contain enough data for client to exchange pre-master secret ◦ For DHE and ECDHE cipher suites ▪ Contains the server’s half of the key agreement ▪ Must be signed with server’s private key ◦ For PSK, just contains the server key name
44. SSL/TLS Handshake Client Hello Server Hello Certificate Server Key Exchange Certificate Request Certificate Client Key Exchange Certificate Verify Change Cipher Spec Finished Change Cipher Spec Finished Server Hello Done Hello Verify Request • Server Key Exchange
45. SSL/TLS Handshake Client Hello Server Hello Certificate Server Key Exchange Certificate Request Certificate Client Key Exchange Certificate Verify Change Cipher Spec Finished Change Cipher Spec Finished Server Hello Done Hello Verify Request • (Certificate Request) ◦ Server requests client certificate ◦ Used to accomplish “mutual authentication” ◦ Only sent if session configured for client authentication
46. SSL/TLS Handshake Client Hello Server Hello Certificate Server Key Exchange Certificate Request Certificate Client Key Exchange Certificate Verify Change Cipher Spec Finished Change Cipher Spec Finished Server Hello Done Hello Verify Request • (Certificate Request)
47. SSL/TLS Handshake Client Hello Server Hello Certificate Server Key Exchange Certificate Request Certificate Client Key Exchange Certificate Verify Change Cipher Spec Finished Change Cipher Spec Finished Server Hello Done Hello Verify Request • Server Hello Done ◦ Indicates end of Server Hello ◦ After sending, server will wait for client response
48. SSL/TLS Handshake Client Hello Server Hello Certificate Server Key Exchange Certificate Request Certificate Client Key Exchange Certificate Verify Change Cipher Spec Finished Change Cipher Spec Finished Server Hello Done Hello Verify Request • Server Hello Done
49. SSL/TLS Handshake Client Hello Server Hello Certificate Server Key Exchange Certificate Request Certificate Client Key Exchange Certificate Verify Change Cipher Spec Finished Change Cipher Spec Finished Server Hello Done Hello Verify Request • (Client Certificate) ◦ Client’s certificate chain, may be empty ◦ X.509 v3 Certificates ◦ Must be compatible with selected key exchange algorithm ◦ Not sent when using PSK cipher suites or not requested ◦ On receiving this message, server validates the certificate chain
50. SSL/TLS Handshake Client Hello Server Hello Certificate Server Key Exchange Certificate Request Certificate Client Key Exchange Certificate Verify Change Cipher Spec Finished Change Cipher Spec Finished Server Hello Done Hello Verify Request • (Client Certificate)
51. SSL/TLS Handshake Client Hello Server Hello Certificate Server Key Exchange Certificate Request Certificate Client Key Exchange Certificate Verify Change Cipher Spec Finished Change Cipher Spec Finished Server Hello Done Hello Verify Request • Client Key Exchange ◦ For RSA cipher suites, contains the pre-master secret encrypted with the server’s public key ◦ For DHE or ECDHE cipher suites, contains the client’s half of the key agreement ◦ On receipt of this message, both sides now have enough information to generate the master secret and the session keys using the PRF, Pseudo Random Function
52. SSL/TLS Handshake Client Hello Server Hello Certificate Server Key Exchange Certificate Request Certificate Client Key Exchange Certificate Verify Change Cipher Spec Finished Change Cipher Spec Finished Server Hello Done Hello Verify Request • Client Key Exchange
53. SSL/TLS Handshake Client Hello Server Hello Certificate Server Key Exchange Certificate Request Certificate Client Key Exchange Certificate Verify Change Cipher Spec Finished Change Cipher Spec Finished Server Hello Done Hello Verify Request • Certificate Verify ◦ Client sends the Certificate Verify message when sending a certificate ◦ Hash of handshake messages to this point ◦ Signed with the client’s private key ◦ Server verifies with client’s public key
54. SSL/TLS Handshake Client Hello Server Hello Certificate Server Key Exchange Certificate Request Certificate Client Key Exchange Certificate Verify Change Cipher Spec Finished Change Cipher Spec Finished Server Hello Done Hello Verify Request • Certificate Verify
55. SSL/TLS Handshake Client Hello Server Hello Certificate Server Key Exchange Certificate Request Certificate Client Key Exchange Certificate Verify Change Cipher Spec Finished Change Cipher Spec Finished Server Hello Done Hello Verify Request • Change Cipher Spec ◦ Sent by both client and server ◦ This is not part of the handshake protocol, but part of the handshake. ◦ Indicates to the peer that this endpoint is now using the negotiated cipher suite and keys
56. SSL/TLS Handshake Client Hello Server Hello Certificate Server Key Exchange Certificate Request Certificate Client Key Exchange Certificate Verify Change Cipher Spec Finished Change Cipher Spec Finished Server Hello Done Hello Verify Request • Change Cipher Spec
57. SSL/TLS Handshake Client Hello Server Hello Certificate Server Key Exchange Certificate Request Certificate Client Key Exchange Certificate Verify Change Cipher Spec Finished Change Cipher Spec Finished Server Hello Done Hello Verify Request • Finished ◦ First message encrypted with the negotiated cipher suite and session keys ◦ Contains hash of all handshake messages exchanged to this point ◦ Verifies that the authentication and key generation was successful
58. • Handshake Protocol Format TLS Handshake
59. TLS Vulnerabilities Found in earlier versions of SSL / TLS
60. • There have been several vulnerabilities discovered in TLS since it was invented in 1995 • It is recommended to: ◦ Use the most current TLS protocol and secure algorithms ◦ Have a software/firmware update system to stay updated with new TLS library versions TLS Vulnerabilities
61. Browser Exploit Against SSL/TLS • Affects SSL 3.0 and TLS 1.0 that use a CBC-mode block cipher • Fix: Use > TLS 1.0, or a stream cipher BEAST
62. Compression Ratio Info-leak Made Easy • Affects connections using compression • Fix: Don’t use compression with SSL/TLS CRIME
63. MAC calculation includes 13 bytes of header information • Affects CBC-mode for TLS (1.1 and 1.2) and DTLS (1.0 and 1.2) • Based on a delicate timing analysis of the decryption processing needed in block mode • Fix: Don’t use CBC mode with TLS 1.1 or 1.2, OR use a patched implementation (wolfSSL has been patched!) Lucky 13
64. • Affects OpenSSL users only (doesn’t apply to wolfSSL) • Bug in OpenSSL’s implementation of the “Heartbeat Extension” • Fix: Don’t use vulnerable OpenSSL versions Heartbleed
65. Padding Oracle On Downgraded Legacy Encryption • Affects SSL 3.0 connections • Fix: Don’t use SSL 3.0 POODLE
66. • Affects implementations that do incomplete ASN.1 decoding • Fix: Use an implementation that does correct ASN.1 decoding BERserk
67. Factoring RSA Export Keys • Exploits legacy SSL cipher suites from the 1990s that use RSA export keys • Fix: Don’t use EXPORT grade RSA keys (512 bits or less). wolfSSL never supported them. FREAK
68. • Leverages weak keys that the outdated stream cipher RC4 can sometimes generate • Fix: Stop using RC4 Bar Mitzvah Attack
69. • Exploits legacy SSL cipher suites from the 1990s that use DH and DHE EXPORT keys (512 bits or less) • wolfSSL has never supported EXPORT DH/DHE cipher suites • Fix: Don’t use EXPORT grade DH and DHE cipher suites Logjam
70. • Requires: ◦ A static (EC)DH cipher suite ◦ Client authentication with a static (EC)DH private key ◦ The injection of a known certificate/key pair into the client • wolfSSL ◦ Does support static ECDH cipher suites, but does not support static DH cipher suites ◦ Client authentication is supported in wolfSSL ◦ But, ecdsa_fixed_ecdh is not supported, meaning yaSSL / CyaSSL / wolfSSL are not vulnerable to the attack Pandora’s Box Attack
71. Security Losses from Obsolete and Truncated Transcript Hashes • Affects: RSA-MD5 signatures with TLS 1.2 • Fix: Don’t use them. wolfSSL has never supported them. SLOTH
72. Decrypting RSA with Obsolete and Weakened eNcryption • Affects: SSLv2 and EXPORT cipher suites (512 bits or less) • Fix: Don’t use SSLv2 with EXPORT ciphers DROWN
73. Birthday attacks on 64-bit block ciphers in TLS and OpenVPN (Birthday attacks can be used to find collisions in a cryptographic hash function) • An attack on block cipher algorithms that use a block size of 64 bits (ex: 3DES) • Fix: Don’t use 3DES (wolfSSL has it disabled by default) SWEET32
74. TLS 1.3 The future of TLS!
75. August 2013 - Work on TLS 1.3 begins April 17, 2014 - Draft 00, 01 July 7, 2014 - Draft 02 October 27, 2014 - Draft 03 January 3, 2015 - Draft 04 March 9, 2015 - Draft 05 June 29, 2015 - Draft 06 July 8, 2015 - Draft 07 August 28, 2015 - Draft 08 October 5, 2015 - Draft 09 October 19, 2015 - Draft 10 December 28, 2015 - Draft 11 February 2016 - TLS Working Group Workshop to analyze TLS 1.3 designs March 21, 2016 - Draft 12 May 22, 2016 - Draft 13 July 11, 2016 - Draft 14 August 17, 2016 - Draft 15 September 22, 2016 - Draft 16 October 20, 2016 - Draft 17 October 26, 2016 - Draft 18 March 10, 2017 - Draft 19 April 28, 2017 - Draft 20 July 3, 2017 - Draft 21 • In development for over 4 years now • 21 drafts so far History of TLS 1.3
76. August 2013 - Work on TLS 1.3 begins April 17, 2014 - Draft 00, 01 July 7, 2014 - Draft 02 October 27, 2014 - Draft 03 January 3, 2015 - Draft 04 March 9, 2015 - Draft 05 June 29, 2015 - Draft 06 July 8, 2015 - Draft 07 August 28, 2015 - Draft 08 October 5, 2015 - Draft 09 October 19, 2015 - Draft 10 December 28, 2015 - Draft 11 February 2016 - TLS Working Group Workshop to analyze TLS 1.3 designs March 21, 2016 - Draft 12 May 22, 2016 - Draft 13 July 11, 2016 - Draft 14 August 17, 2016 - Draft 15 September 22, 2016 - Draft 16 October 20, 2016 - Draft 17 October 26, 2016 - Draft 18 March 10, 2017 - Draft 19 April 28, 2017 - Draft 20 July 3, 2017 - Draft 21 wolfSSL has implemented Draft 18 and 20! History of TLS 1.3
77. Algorithm Changes • Symmetric algorithm list has been pruned of all “legacy” algorithms • Remaining algorithms all use Authenticated Encryption with Associated Data (AEAD) • Ciphersuite concept has changed to separate authentication and key exchange mechanisms from the record protection algorithm and a hash to be used with key derivation function and HMAC TLS 1.3 - Major Differences from TLS 1.2
78. Zero-RTT Mode • Performance enhancement • Saves a round-trip at connection setup for some application data • At the cost of some security properties TLS 1.3 - Major Differences from TLS 1.2
79. More Encrypted Handshake Messages • All handshake messages after the ServerHello are now encrypted • New EncryptedExtension allows extensions previously sent in the clear in ServerHello to also be encrypted TLS 1.3 - Major Differences from TLS 1.2
80. Redesigned Key Derivation Functions • Allows for easier analysis by cryptographers due to improved key separation properties • HMAC-based Extract-and-Expand Key Derivation Function (HKDF) used TLS 1.3 - Major Differences from TLS 1.2
81. ECC is Included • Now included in the base spec • Includes new signature algorithms (ex: ed25519, ed448) • Point format negotiation removed in favor of single point format per curve TLS 1.3 - Major Differences from TLS 1.2
82. Other Crypto Improvements • Removed ◦ Compression ◦ Custom DHE groups ◦ DSA • RSA padding changed to use PSS TLS 1.3 - Major Differences from TLS 1.2
83. Version Negotiation Removed • TLS 1.2 included version negotiation mechanism • TLS 1.3 removes this in favor of a version list in an extension • Increases compatibility with servers which incorrectly implemented version negotiation TLS 1.3 - Major Differences from TLS 1.2
84. Session Resumption • Session resumption with and without server-side state removed • PSK-based ciphersuites of earlier TLS versions removed • Replaced by a single new PSK exchange TLS 1.3 - Major Differences from TLS 1.2
85. • Supports 3 basic key exchange modes: a. (EC)DHE (both finite field and elliptic curve varieties) b. PSK-only c. PSK with (EC)DHE TLS 1.3 - Key Exchange Modes
86. • Three phases: a. Key Exchange ▪ Establish shared keying material and select the cryptographic parameters. Everything after this is encrypted. b. Server Parameters ▪ Establish other handshake parameters (ex: client authentication, ALPN, etc) c. Authentication ▪ Authenticate the server (optionally the client), provide key confirmation and handshake integrity TLS 1.3 - FULL Handshake
87. Client Server Key ^ ClientHello Exch | + key_share* | + signature_algorithms* | + psk_key_exchange_modes* v + pre_shared_key* --------> ServerHello ^ Key + key_share* | Exch + pre_shared_key* v {EncryptedExtensions} ^ Server {CertificateRequest*} v Params {Certificate*} ^ {CertificateVerify*} | Auth {Finished} v <-------- [Application Data*] ^ {Certificate*} Auth | {CertificateVerify*} v {Finished} --------> [Application Data] <-------> [Application Data] TLS 1.3 - FULL Handshake
88. • Client sends ClientHello containing: ClientHello + key_share* + signature_algorithms* + psk_key_exchange_modes* + pre_shared_key* ◦ Random nonce (ClientHello.random) ◦ Protocol version (TLS 1.3) ◦ List of symmetric cipher/HKDF hash pairs ◦ Set of Diffie-Hellman key shares (in “key_share” extension) AND/OR ◦ Set of pre-shared key labels (in “pre_shared_key” extension) ◦ Optionally, other extensions TLS 1.3 - Key Exchange
89. • Server processes ClientHello • Server responds with ServerHello - indicating negotiated connection parameters ◦ If EC(DHE) used, contains “key_share” extension with server’s ephemeral DH share (in same group as one of client’s shares) ◦ If PSK, contains “pre_shared_key” extension indicating which of client’s PSKs was selected ◦ If EC(DHE) and PSK are used together, both extensions are present ServerHello + key_share* + pre_shared_key* TLS 1.3 - Key Exchange
90. • Server sends EncryptedExtensions ◦ Responses to ClientHello extensions which are not required to determine cryptographic parameters • Server sends CertificateRequest ◦ If client authentication is desired (otherwise omitted) {EncryptedExtensions} {CertificateRequest*} TLS 1.3 - Server Parameters
91. • Certificate message ◦ Can be sent by both client and server ◦ Certificate of endpoint and any per-certificate extensions • CertificateVerify message ◦ Signature over entire handshake, using private key corresponding to public key in Certificate message • Finished message ◦ MAC over entire handshake ◦ Provides key confirmation, binds endpoint identity to exchanged keys ◦ Authenticates handshake in PSK mode {Certificate*} {CertificateVerify*} {Finished} TLS 1.3 - Authentication
92. • If client has not provided sufficient “key_share” extension ◦ Server corrects mismatch with a HelloRetryRequest and client needs to restart handshake ▪ Example: Client includes only DHE or ECDHE groups unsupported by server ◦ If no common cryptographic parameters can be negotiated, server aborts handshake TLS 1.3 - Incorrect DHE Share
93. Client Server ClientHello + key_share --------> <-------- HelloRetryRequest + key_share ClientHello + key_share --------> ServerHello + key_share {EncryptedExtensions} {CertificateRequest*} {Certificate*} {CertificateVerify*} {Finished} <-------- [Application Data*] {Certificate*} {CertificateVerify*} {Finished} --------> [Application Data] <-------> [Application Data] TLS 1.3 - Incorrect DHE Share
94. • Two purposes 1. Allows server to force client to demonstrate reachability at their network address 2. Allows server to offload state to client, allowing it to send HelloRetryRequest without storing any state TLS 1.3 - Cookie Extension
95. TLS 1.3 Handshake Complete! • Handshake is now complete between client and server • May continue to exchange application-layer data
96. TLS 1.3 Optimized Handshake Variants! 1. Resumption and Pre-Shared Key (PSK) 2. Zero-RTT Data (0-RTT)
97. TLS 1.3 Optimized Handshake Variants 1. Resumption and Pre-Shared Key
98. • Resumption and Pre-Shared Key (PSK) ◦ PSKs can be established in a previous connection and then reused ◦ “Session resumption” ◦ Once handshake has completed, server can send client a PSK identity that corresponds to a key derived from the initial handshake ◦ Client can then use that PSK identity in future handshakes to negotiate use of the PSK TLS 1.3 - Optimized Handshake Variants
99. • Resumption and Pre-Shared Key (PSK) ◦ If server accepts client’s PSK, security context of new connection is tied to the original handshake ◦ The key derived from the initial handshake is used to bootstrap the state of a full handshake ◦ TLS 1.2 (and below) used “session IDs” and “session tickets” ▪ Both now obsolete in TLS 1.3 TLS 1.3 - Optimized Handshake Variants
100. • Resumption and Pre-Shared Key (PSK) ◦ PSKs can be used with (EC)DHE key exchange ▪ Provides forward secrecy in combination with shared keys ◦ PSKs can be used alone ▪ Loses forward secrecy TLS 1.3 - Optimized Handshake Variants
101. Client Server Initial Handshake: ClientHello + key_share --------> ServerHello + key_share {EncryptedExtensions} {CertificateRequest*} {Certificate*} {CertificateVerify*} {Finished} <-------- [Application Data*] {Certificate*} {CertificateVerify*} {Finished} --------> <-------- [NewSessionTicket] [Application Data] <-------> [Application Data] TLS 1.3 - PSK Initial Handshake
102. Client Server Subsequent (Resumed) Handshake: ClientHello + key_share* + psk_key_exchange_modes + pre_shared_key --------> ServerHello + pre_shared_key + key_share* {EncryptedExtensions} {Finished} <-------- [Application Data*] {Finished} --------> [Application Data] <-------> [Application Data] TLS 1.3 - PSK Resumed Handshake
103. • Resumption and Pre-Shared Key (PSK) ◦ Since server is authenticating via PSK, it does not send a Certificate or CertificateVerify message ◦ Client should supply “key_share” extension when resuming with PSK ▪ Allows server to decline resumption and fall back to full handshake ◦ Server responds with “pre_shared_key” extension to negotiate use of PSK ▪ Can also send “key_share” extension to do (EC)DHE TLS 1.3 - Optimized Handshake Variants
104. TLS 1.3 Optimized Handshake Variants 2. Zero-RTT Data (0-RTT)
105. • Zero-RTT Data ◦ When client/server share PSK, clients can send data on the 1st flight ▪ AKA: “early data” ◦ Client uses the PSK to authenticate server and to encrypt early data ◦ PSK can be obtained externally or via previous handshake TLS 1.3 - Optimized Handshake Variants
106. • Zero-RTT Data ◦ If PSK is obtained externally, the following must be provisioned to both client and server: ▪ Cipher suite for use with the PSK ▪ Application-Layer Protocol Negotiation (ALPN) protocol, if any ▪ Server Name Indication (SNI), if any is to be used TLS 1.3 - Optimized Handshake Variants
107. • Zero-RTT Data ◦ With 0-RTT, data is just added to the 1-RTT handshake in the first flight ◦ Rest of the handshake uses the same messages as 1-RTT with PSK resumption TLS 1.3 - Optimized Handshake Variants
108. Client Server ClientHello + early_data + key_share* + psk_key_exchange_modes + pre_shared_key (Application Data*) --------> ServerHello + pre_shared_key + key_share* {EncryptedExtensions} + early_data* {Finished} <-------- [Application Data*] (EndOfEarlyData) {Finished} --------> [Application Data] <-------> [Application Data] TLS 1.3 - Optimized Handshake Variants
109. • Zero-RTT Data ◦ WARNING: ▪ Security properties of 0-RTT data are weaker than those for other kinds of TLS data TLS 1.3 - Optimized Handshake Variants
110. • Zero-RTT Data (Warnings) ◦ Data is not forward secret (encrypted only under keys derived using offered PSK) ◦ No guarantees of non-replay between connections ▪ Server has no guarantee that the same 0-RTT data was not transmitted on multiple 0-RTT connections ▪ Relevant if data is authenticated either with TLS client authentication or inside the application layer protocol. TLS 1.3 - Optimized Handshake Variants
111. • Zero-RTT Data (Warnings) ◦ Protocols that use TLS MUST NOT use 0-RTT data without a profile that defines its use ▪ Profile needs to identify which messages or interactions are safe to use with 0-RTT TLS 1.3 - Optimized Handshake Variants
112. So, what does TLS 1.3 mean for you?
113. • Faster performance! ◦ Quicker handshake establishment ▪ TLS 1.2 - 2 complete round trips ▪ TLS 1.3 - 1 complete round trip ◦ Network latency has less impact on required time to establish a secure connection ◦ Optionally, 0-RTT with data in the first flight! TLS 1.3 Advantages
114. TLS 1.3 Advantages
115. • More secure! ◦ Removal of legacy and insecure algorithms, including: ▪ RSA key transport - lacks forward secrecy ▪ RC4 stream cipher - No longer considered secure ▪ CBC mode ciphers - Attacks: BEAST, Lucky13 ▪ SHA-1 hash function - Deprecated, SHA-2 recommended ▪ Arbitrary Diffie-Hellman groups - CVE-2016-0701 ▪ Export ciphers - Attacks: FREAK, Logjam TLS 1.3 Advantages
116. TLS 1.3 in wolfSSL • Update on wolfSSL TLS 1.3 support • How to use TLS 1.3 today!
117. • Draft 18 Support • Draft 20 Support $ unzip wolfssl-X.X.X.zip $ cd wolfssl-X.X.X $ ./configure --enable-tls13-draft18 $ make $ unzip wolfssl-X.X.X.zip $ cd wolfssl-X.X.X $ ./configure --enable-tls13 $ make Compiling wolfSSL with TLS 1.3
118. • wolfSSL example client and server can be used to easily test TLS 1.3 functionality with wolfSSL • Example: ◦ TLS 1.3 with TLS13-AES128-GCM-SHA256 cipher suite $ ./examples/server/server -v 4 -l TLS13-AES128-GCM-SHA256 $ ./examples/client/client -v 4 -l TLS13-AES128-GCM-SHA256 wolfSSL Examples with TLS 1.3
119. • wolfSSL example client can also be used to connect to external TLS 1.3 servers • Example: ◦ Connecting to www.wolfssl.com with TLS13-AES128-GCM-SHA256 $ ./examples/client/client -v 4 -l TLS13-AES128-GCM-SHA2 \ -h www.wolfssl.com -p 443 -g \ -A ./certs/wolfssl-website-ca.pem wolfSSL Examples with TLS 1.3
120. • wolfSSL currently supports the following TLS 1.3 cipher suites: TLS13-AES128-GCM-SHA256 TLS13-AES256-GCM-SHA384 TLS13-CHACHA20-POLY1305-SHA256 TLS13-AES128-CCM-SHA256 TLS13-AES128-CCM-8-SHA256 wolfSSL Examples with TLS 1.3
121. • Two new client/server methods to use TLS 1.3 • During creation of a WOLFSSL_CTX: • Or, extended versions that allow application to provide a heap pointer: WOLFSSL_METHOD* wolfTLSv1_3_server_method(void); WOLFSSL_METHOD* wolfTLSv1_3_client_method(void); WOLFSSL_METHOD* wolfTLSv1_3_server_method_ex(void* heap); WOLFSSL_METHOD* wolfTLSv1_3_client_method_ex(void* heap); wolfSSL TLS 1.3 API Usage
122. • Cookie Extension ◦ Sends a cookie with the HelloRetryRequest to avoid storing state ◦ Must define WOLFSSL_SEND_HRR_COOKIE or ◦ ./configure --enable-hrrcookie int wolfSSL_send_hrr_cookie(WOLFSSL* ssl, unsigned char* secret, unsigned int secretSz); secret - Secret to use when generating integrity check for cookie. A value of NULL indicates to generate a new random secret. secretSz - Size of secret data in bytes. Use a value of 0 to indicate use of default size. wolfSSL TLS 1.3 API Usage
123. • Do not send a ticket after TLS v1.3 handshake for resumption. int wolfSSL_CTX_no_ticket_TLSv13(WOLFSSL_CTX* ctx); int wolfSSL_no_ticket_TLSv13(WOLFSSL* ssl); ctx - Initialized wolfSSL context structure ssl - Initialized wolfSSL session structure wolfSSL TLS 1.3 API Usage
124. • Disallow (EC)DHE key exchange when using pre-shared keys int wolfSSL_CTX_no_dhe_psk(WOLFSSL_CTX* ctx); int wolfSSL_no_dhe_psk(WOLFSSL* ssl); ctx - Initialized wolfSSL context structure ssl - Initialized wolfSSL session structure wolfSSL TLS 1.3 API Usage
125. • Update the keys for encryption and decryption ◦ Sends KeyUpdate handshake message to indicate sender is updating its sending cryptographic keys ◦ Can be sent by either peer after it has sent a Finished message int wolfSSL_update_keys(WOLFSSL* ssl); ssl - Initialized wolfSSL session structure wolfSSL TLS 1.3 API Usage
126. • Allow post-handshake authentication in TLS v1.3 connections • When client has sent “post_handshake_auth” extension, server may request client authentication at any time after handshake has completed by sending CertificateRequest message ◦ Must define WOLFSSL_POST_HANDSHAKE_AUTH or ◦ ./configure --enable-postauth int wolfSSL_CTX_allow_post_handshake_auth(WOLFSSL_CTX* ctx); int wolfSSL_allow_post_handshake_auth(WOLFSSL* ssl); ctx - Initialized wolfSSL context structure ssl - Initialized wolfSSL session structure wolfSSL TLS 1.3 API Usage
127. • Request a certificate of the client ◦ Can be called any time after handshake completion. ◦ A maximum of 256 requests can be sent on a connection. int wolfSSL_request_certificate(WOLFSSL* ssl); ssl - Initialized wolfSSL session structure wolfSSL TLS 1.3 API Usage
128. • The client connecting to the server ◦ The protocol version is expecting to be TLS v1.3. ◦ If the server downgrades, and older versions of the protocol are compiled in, the client will fallback to wolfSSL_connect(). int wolfSSL_connect_TLSv13(WOLFSSL* ssl); ssl - Initialized wolfSSL session structure wolfSSL TLS 1.3 API Usage
129. • The server accepting a connection from a client ◦ The protocol version is expecting to be TLS v1.3 ◦ If the client downgrades, and older versions of the protocol are compiled in, the server will fallback to wolfSSL_accept() int wolfSSL_accept_TLSv13(WOLFSSL* ssl); ssl - Initialized wolfSSL session structure wolfSSL TLS 1.3 API Usage
130. • Sets the maximum amount of early data that can be seen by server when using session tickets for resumption. ◦ A value of zero indicates no early data is to be sent by client using session tickets ◦ WOLFSSL_EARLY_DATA needs to be defined or ◦ ./configure --enable-earlydata int wolfSSL_CTX_set_max_early_data(WOLFSSL_CTX* ctx, unsigned int sz); int wolfSSL_set_max_early_data(WOLFSSL* ssl, unsigned int sz); wolfSSL TLS 1.3 API Usage
131. • Write early data to the server int wolfSSL_write_early_data(WOLFSSL*, const void*, int, int*); wolfSSL TLS 1.3 API Usage
132. • Read any early data from the client int wolfSSL_read_early_data(WOLFSSL* ssl, void* data, int sz, int* outSz); wolfSSL TLS 1.3 API Usage
133. TLS 1.3 Available Now! • Available in current stable GPLv2 release • Free pre-sales support (support@wolfssl.com) • Free Open Source support • Feedback welcomed!
134. TLS 1.3 Advances the Protocol World class testing helps keep it bug free
135. Importance of Testing Security Software • Critical Position: ◦ Applications depend on security software ◦ Providing data integrity, confidentiality, and authentication • Expectation of Security ◦ Lack of testing can allow vulnerabilities and crashes • Maturity and Trust ◦ Users must be able to trust secure software ◦ Increases confidence of code quality
136. Types of Testing A. Unit Testing B. Cipher Suite Testing C. Algorithm Testing D. Static Analysis E. Detecting Memory Errors F. Interoperability Testing G. Peer Review H. Third Party Testing I. Fuzz Testing (edge cases) J. Continuous Integration K. Nightly Test Cycle
137. A. Unit Testing What it does: - Test API functions for correct behavior - Test success and failure cases - Verify functions behave as expected - Test library consistency wolfSSL Uses: - Unit tests for exposed API - No external dependencies - Run with each “make check” - Manually with: $ cd wolfssl-3.12.0 $ ./configure $ make $ ./tests/unit.test starting unit tests... Begin API Tests ... End API Tests
138. B. Cipher Suite Testing What it does: - Test client/server connection with provided cipher suite - Verify suite works as expected wolfSSL Uses: - Tests all cipher suites against ourselves - Run with each “make check” - Manually as part of unit test - 196 cipher suite tests in default build - 300 cipher suite tests w/ DTLS on - (49 / 75 suites) Cipher Suite Examples: TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_PSK_WITH_AES_256_CCM_8 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_NTRU_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 [...]
139. B. Cipher Suite Testing $ ./tests/unit.test Begin Cipher Suite Tests starting default cipher suite tests notice: using default file tests/test.conf trying server command line[25]: SuiteTest -v 3 -l DHE-RSA-CHACHA20-POLY1305 trying client command line[25]: SuiteTest -v 3 -l DHE-RSA-CHACHA20-POLY1305 SSL version is TLSv1.2 SSL cipher suite is TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 ... repeating test with non blocking on ... repeating test with client cert request off ... repeating test with client cert request off repeating test with non blocking on
140. C. Algorithm Testing What it does: - Test algorithms work correctly - Test NIST algorithm vectors - Test FIPS 140-2 test vectors - Algorithm should match expected input/output wolfSSL Uses: - Test crypto works as expected - Two separate tests: 1. wolfCrypt test suite (test.c) 2. FIPS 140-2 test harness Algorithm Examples: Hash Functions: MD5, SHA1, SHA-2, SHA-3 Block Ciphers: AES, 3DES, Camellia Stream Ciphers: RC4, ChaCha, RABBIT, HC-128 Public Key: RSA, DSA, ECC, NTRU
141. C. Algorithm Testing $ ./wolfcrypt/test/testwolfcrypt MD5 test passed! SHA test passed! SHA-256 test passed! [...] GMAC test passed! Chacha test passed! POLY1305 test passed! DES test passed! DES3 test passed! AES test passed! AES-GCM test passed! RANDOM test passed! RSA test passed! DH test passed! ECC test passed! wolfCrypt CAVP Test Vector Harness (version 1.0) INFO: Testing wolfCrypt version: 3.8.0 Parsing configuration file: cavp.conf INFO: Running algorithm test vectors: ------------------------------------------ [1/18] ./vectors/AES/req/CBCGFSbox128.req OUT = ./vectors/AES/rsp/CBCGFSbox128.rsp Expected: PASSED! [2/18] ./vectors/AES/req/CBCGFSbox192.req OUT = ./vectors/AES/rsp/CBCGFSbox192.rsp Expected: PASSED! [...]
142. D. Static Analysis What it does: - Analyze code in order to automatically find bugs - Follow different code paths - May catch issues in low traffic code paths wolfSSL Uses: - Several different static analysis tools: 1. Coverity Scan 2. Clang Static Analyzer (scan-build) 3. Facebook infer
143. E. Detecting Memory Errors What it does: - Detect memory errors including: - Accessing memory that shouldn’t be - Using undefined values - Incorrect freeing of dynamic memory - Memory leaks - and more... wolfSSL Uses: - Valgrind (memcheck)
144. F. Interoperability Testing What it does: - Test interop with other implementations - Helps verify protocol and feature implementations - Real world apps may run against other libraries wolfSSL Uses: - Interop testing with other SSL/TLS implementations, including: • OpenSSL • BoringSSL • GnuTLS • mbed TLS (PolarSSL)
145. G. Peer Review What it does: - Code review by second set of eyes (not the developer him/herself) wolfSSL Uses: - Fork + Pull Request system using GitHub - Done on ALL commits to master branch
146. H. Third Party Testing What it does: - Code reviewed by external researchers, labs, and security teams wolfSSL Uses: - Reviews done on a regular basis by: • University researchers • Customer/user security teams • FIPS/certificate labs • Open Source user base - Being Open Source makes this easy!
147. I. Fuzz Testing What it does: - Helps test edge cases that developers may not think about testing - Tests corrupt TLS records, X.509 certs, and keys - Helps find bugs early that could have been a vulnerability - Guided probability based mutation of public facing buffers, in an attempt to make the library crash wolfSSL Uses: - Two main fuzzers: • wolfFuzz - Operates over memory buffers instead of TCP/IP • wolfSSL Network Fuzzer - Runs over TCP/IP - (-) much slower - (+) flexible with other client/servers or protocols
148. I. Fuzz Testing Also added this year: - Libfuzzer - Tlsfuzzer - OSS-Fuzz - AFL
149. J. Continuous Integration What it does: - Runs tests on each pull request submitted - Integrates into development workflow - Finds bugs that developers may have missed, before code gets into master wolfSSL Uses: - Jenkins for CI on each pull request: • Tests FIPS build • Known Configurations (customer/user/common) • Valgrind • Static analysis (scan-build)
150. K. Nightly Test Cycle What it does: - Runs longer tests (multiple hours) - More in depth testing than CI - Results in devs inboxes each AM wolfSSL Uses: - Jenkins for Nightly Testing: • ./configure build option tests (multi-platform, multi-compiler) • Known Configurations • Extended Fuzz Testing
151. A. Unit Testing B. Cipher Suite Testing C. Algorithm Testing D. Static Analysis E. Detecting Memory Errors F. Interoperability Testing G. Peer Review H. Third Party Testing I. Fuzz Testing (edge cases) J. Continuous Integration K. Nightly Test Cycle In Recap
152. Thanks! Questions? info@wolfssl.com www.wolfssl.com Bozeman, MT : Seattle, WA : Portland, OR : Rescue, CA : Tokyo, JP : Brisbane, AU : João Pessoa, BR