wolfSSL, profile picture
Uploaded bywolfSSL
PDF, PPTX4,451 views

wolfSSL and TLS 1.3

This document summarizes a talk given by Chris Conlon from wolfSSL on September 15, 2017 in Tokyo, Japan about TLS 1.3. It provides background on Chris Conlon and his role at wolfSSL, an overview of wolfSSL's products and services including their lightweight SSL/TLS library. It also discusses the history and components of the SSL/TLS protocol, common vulnerabilities, and the goals of the new TLS 1.3 specification.

Embed presentation

Download as PDF, PPTX
1 / 152
2 / 152
Most read
3 / 152
4 / 152
5 / 152
6 / 152
7 / 152
8 / 152
9 / 152
10 / 152
11 / 152
12 / 152
13 / 152
14 / 152
15 / 152
16 / 152
17 / 152
18 / 152
19 / 152
20 / 152
21 / 152
22 / 152
23 / 152
24 / 152
25 / 152
26 / 152
27 / 152
28 / 152
29 / 152
30 / 152
31 / 152
32 / 152
33 / 152
34 / 152
35 / 152
36 / 152
37 / 152
38 / 152
39 / 152
40 / 152
41 / 152
42 / 152
43 / 152
44 / 152
45 / 152
46 / 152
47 / 152
48 / 152
49 / 152
50 / 152
51 / 152
52 / 152
53 / 152
54 / 152
55 / 152
56 / 152
57 / 152
58 / 152
59 / 152
60 / 152
61 / 152
62 / 152
63 / 152
64 / 152
65 / 152
66 / 152
67 / 152
68 / 152
69 / 152
70 / 152
71 / 152
72 / 152
73 / 152
74 / 152
75 / 152
76 / 152
77 / 152
78 / 152
79 / 152
80 / 152
81 / 152
82 / 152
83 / 152
84 / 152
85 / 152
86 / 152
87 / 152
88 / 152
89 / 152
90 / 152
91 / 152
92 / 152
93 / 152
94 / 152
95 / 152
96 / 152
97 / 152
98 / 152
99 / 152
100 / 152
101 / 152
102 / 152
103 / 152
104 / 152
105 / 152
106 / 152
107 / 152
108 / 152
109 / 152
110 / 152
111 / 152
112 / 152
113 / 152
114 / 152
115 / 152
116 / 152
117 / 152
118 / 152
119 / 152
120 / 152
121 / 152
122 / 152
123 / 152
124 / 152
125 / 152
126 / 152
127 / 152
128 / 152
129 / 152
130 / 152
131 / 152
132 / 152
133 / 152
134 / 152
135 / 152
136 / 152
137 / 152
138 / 152
139 / 152
140 / 152
141 / 152
142 / 152
143 / 152
144 / 152
145 / 152
146 / 152
147 / 152
148 / 152
149 / 152
150 / 152
151 / 152
152 / 152
Talking about TLS 1.3 Tokyo, Japan September 15, 2017
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
We Secure the Internet by Securing Data
VoIP Smart Grid Cloud Services Automotive / Smart Cars Battlefield Communication Smart Energy Appliances Games Sensors Internet of Things Databases Mobile Phones PrintersApplications Connected Home Industrial Automation M2M Routers We Secure the Internet by Securing Data
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
Origin of wolfSSL
Exciting Company Growth
wolfSSL Products
wolfSSL Product Licensing Dual Licensed! ● Clean room SSL/TLS and Cryptography ● wolfSSL owns the Copyright
Broad Partner Program
● 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!
wolfSSL Library Overview
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
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
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
● 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?
● 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?
● From Our Website ○ www.wolfssl.com ● On GitHub: ○ github.com/wolfssl/wolfssl Downloading wolfSSL
SSL/TLS History and Protocol A little background before we talk TLS 1.3
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
● Taher Elgamal ○ “Father of SSL” ○ Netscape (Feb. 1995) SSL : Secure Sockets Layer
● 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?
● 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
● 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?
● Layered between Transport and Application layers What is SSL / TLS?
● 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?
● Handshake Protocol ● Responsible for negotiating a session, includes: ■ Session identifier ■ Peer certificate ■ Compression method ■ Cipher spec ■ Master secret ■ “is resumable” TLS Sub-Protocols
● 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
● 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
● Record Protocol ● Layered protocol (Sending Side) ■ Fragments input data into blocks ■ (optionally) compresses data ■ Applies MAC ■ Encrypts ■ Transmits the result TLS Sub-Protocols
● Record Protocol TLS Sub-Protocols
● 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
● TLS Record Header Format TLS Sub-Protocols
TLS Handshake (up to TLS 1.2)
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
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
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
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
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
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...
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
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
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
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
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
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)
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
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
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
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)
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
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
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
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
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
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
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
● Handshake Protocol Format TLS Handshake
TLS Vulnerabilities Found in earlier versions of SSL / TLS
● 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
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
Compression Ratio Info-leak Made Easy ● Affects connections using compression ● Fix: Don’t use compression with SSL/TLS CRIME
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
● 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
Padding Oracle On Downgraded Legacy Encryption ● Affects SSL 3.0 connections ● Fix: Don’t use SSL 3.0 POODLE
● Affects implementations that do incomplete ASN.1 decoding ● Fix: Use an implementation that does correct ASN.1 decoding BERserk
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
● Leverages weak keys that the outdated stream cipher RC4 can sometimes generate ● Fix: Stop using RC4 Bar Mitzvah Attack
● 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
● 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
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
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
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
TLS 1.3 The future of TLS!
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
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
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
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
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
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
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
Other Crypto Improvements ● Removed ○ Compression ○ Custom DHE groups ○ DSA ● RSA padding changed to use PSS TLS 1.3 - Major Differences from TLS 1.2
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
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
● 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
● 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
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*} vParams {Certificate*} ^ {CertificateVerify*} |Auth {Finished} v <-------- [Application Data*] ^ {Certificate*} Auth | {CertificateVerify*} v {Finished} --------> [Application Data] <-------> [Application Data] TLS 1.3 - FULL Handshake
● 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
● 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
● 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
● 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
● 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
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
● 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
TLS 1.3 Handshake Complete! ● Handshake is now complete between client and server ● May continue to exchange application-layer data
TLS 1.3 Optimized Handshake Variants! 1. Resumption and Pre-Shared Key (PSK) 2. Zero-RTT Data (0-RTT)
TLS 1.3 Optimized Handshake Variants 1. Resumption and Pre-Shared Key
● 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
● 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
● 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
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
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
● 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
TLS 1.3 Optimized Handshake Variants 2. Zero-RTT Data (0-RTT)
● 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
● 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
● 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
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
● 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
● 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
● 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
So, what does TLS 1.3 mean for you?
● 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
TLS 1.3 Advantages
● 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
TLS 1.3 in wolfSSL ● Update on wolfSSL TLS 1.3 support ● How to use TLS 1.3 today!
● 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
● 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
● 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
● 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
● 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
● 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
● 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
● 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
● 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
● 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
● 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
● 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
● 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
● 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
● Write early data to the server int wolfSSL_write_early_data(WOLFSSL*, const void*, int, int*); wolfSSL TLS 1.3 API Usage
● 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
TLS 1.3 Available Now! ● Available in current stable GPLv2 release ● Free pre-sales support (support@wolfssl.com) ● Free Open Source support ● Feedback welcomed!
TLS 1.3 Advances the Protocol World class testing helps keep it bug free
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
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
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
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 [...]
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
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
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! [...]
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
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)
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)
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
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!
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
I. Fuzz Testing Also added this year: - Libfuzzer - Tlsfuzzer - OSS-Fuzz - AFL
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)
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
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
Thanks! Questions? info@wolfssl.com www.wolfssl.com Bozeman, MT : Seattle, WA : Portland, OR : Rescue, CA : Tokyo, JP : Brisbane, AU : João Pessoa, BR

More Related Content

PPTX
Public Key Cryptography
byGopal Sakarkar
 
PPT
Fundamentals of cryptography
byHossain Md Shakhawat
 
PDF
Asymmetric Cryptography
byUTD Computer Security Group
 
PPTX
Classical Encryption Techniques
bySou Jana
 
PPTX
5. message authentication and hash function
byChirag Patel
 
PPTX
Diffie Hellman.pptx
bySou Jana
 
PPT
SSL/TLS
byDr Anjan Krishnamurthy
 
PPTX
3 public key cryptography
byRutvik Mehta
 
Public Key Cryptography
byGopal Sakarkar
 
Fundamentals of cryptography
byHossain Md Shakhawat
 
Asymmetric Cryptography
byUTD Computer Security Group
 
Classical Encryption Techniques
bySou Jana
 
5. message authentication and hash function
byChirag Patel
 
Diffie Hellman.pptx
bySou Jana
 
SSL/TLS
byDr Anjan Krishnamurthy
 
3 public key cryptography
byRutvik Mehta
 

What's hot

PPTX
Hash function
bySalman Memon
 
PPTX
Hash Functions from Information Security
byAdeelAsghar36
 
PPTX
Key Management and Distribution
bySyed Bahadur Shah
 
PDF
Secure Your Encryption with HSM
byNarudom Roongsiriwong, CISSP
 
PPT
Message Authentication Code & HMAC
byKrishna Gehlot
 
PPTX
Hashing vs Encryption vs Encoding
byCheapSSLsecurity
 
PPTX
Rc4
byAmjad Rehman
 
PPTX
Secure Socket Layer (SSL)
bySamip jain
 
PPTX
Encryption ppt
byAnil Neupane
 
PPTX
Diffie hellman key exchange algorithm
bySunita Kharayat
 
PPTX
Hash function
byHarry Potter
 
PPTX
Cryptography
byjayashri kolekar
 
PPTX
RSA ALGORITHM
bySathish Kumar
 
PPTX
SSL And TLS
byGhanshyam Patel
 
PPTX
Hash Function
bySiddharth Srivastava
 
PPTX
SSL
byBadrul Alam bulon
 
PDF
2. public key cryptography and RSA
byDr.Florence Dayana
 
PPTX
Web Security
byDipika Bambhaniya
 
PDF
RSA ALGORITHM
byDr. Shashank Shetty
 
PPTX
TLS v1.3
bySiddhartha Rao
 
Hash function
bySalman Memon
 
Hash Functions from Information Security
byAdeelAsghar36
 
Key Management and Distribution
bySyed Bahadur Shah
 
Secure Your Encryption with HSM
byNarudom Roongsiriwong, CISSP
 
Message Authentication Code & HMAC
byKrishna Gehlot
 
Hashing vs Encryption vs Encoding
byCheapSSLsecurity
 
Rc4
byAmjad Rehman
 
Secure Socket Layer (SSL)
bySamip jain
 
Encryption ppt
byAnil Neupane
 
Diffie hellman key exchange algorithm
bySunita Kharayat
 
Hash function
byHarry Potter
 
Cryptography
byjayashri kolekar
 
RSA ALGORITHM
bySathish Kumar
 
SSL And TLS
byGhanshyam Patel
 
Hash Function
bySiddharth Srivastava
 
SSL
byBadrul Alam bulon
 
2. public key cryptography and RSA
byDr.Florence Dayana
 
Web Security
byDipika Bambhaniya
 
RSA ALGORITHM
byDr. Shashank Shetty
 
TLS v1.3
bySiddhartha Rao
 

Similar to wolfSSL and TLS 1.3

PDF
Securing Data in Transit -
bywolfSSL
 
PPT
Transport layer security.ppt
byImXaib
 
PDF
CNIT 141: 13. TLS
bySam Bowne
 
PDF
CNIT 141 13. TLS
bySam Bowne
 
DOCX
Transport Layer Security
bySanjeev Kumar Jaiswal
 
PPTX
Module2 PPrwgerbetytbteynyunyunythyhtyT.pptx
byThanushB1
 
PDF
CNIT 141: 13. TLS
bySam Bowne
 
PPTX
ssl-tls-ipsec-vpn.pptx
byjithu26327
 
PPT
tls security fda fkj k kjkfjsdkl jkjfsdk.ppt
bysandhyadevit
 
PPTX
chp2 IS.pptx information security and data
bygallanandhini
 
PPTX
secure socket layer
byAmar Shah
 
PDF
CRYPTOGRAPHY AND NETWORK SECURITY- Transport-level Security
byJyothishmathi Institute of Technology and Science Karimnagar
 
PDF
SSL and TLS Theory and Practice 3rd Edition Rolf Oppliger
byaribonkathy
 
PPTX
Cours4.pptx
byBellaj Badr
 
PPTX
Transport Layer Security
byHuda Seyam
 
PDF
Transport Layer Security
byIbrahiem Mohammed
 
PPTX
SSL_and_TLS_Overview concept the nice .pptx
byyvenkateswaracse
 
PPT
Introduction to Secure Sockets Layer
byNascenia IT
 
PPTX
669671684-Ch17-Crypto6e.pptx669671684-Ch17-Crypto6e.pptx
bytahircs1
 
PPT
SecureSocketLayer.ppt
byPranavUndre1
 
Securing Data in Transit -
bywolfSSL
 
Transport layer security.ppt
byImXaib
 
CNIT 141: 13. TLS
bySam Bowne
 
CNIT 141 13. TLS
bySam Bowne
 
Transport Layer Security
bySanjeev Kumar Jaiswal
 
Module2 PPrwgerbetytbteynyunyunythyhtyT.pptx
byThanushB1
 
CNIT 141: 13. TLS
bySam Bowne
 
ssl-tls-ipsec-vpn.pptx
byjithu26327
 
tls security fda fkj k kjkfjsdkl jkjfsdk.ppt
bysandhyadevit
 
chp2 IS.pptx information security and data
bygallanandhini
 
secure socket layer
byAmar Shah
 
CRYPTOGRAPHY AND NETWORK SECURITY- Transport-level Security
byJyothishmathi Institute of Technology and Science Karimnagar
 
SSL and TLS Theory and Practice 3rd Edition Rolf Oppliger
byaribonkathy
 
Cours4.pptx
byBellaj Badr
 
Transport Layer Security
byHuda Seyam
 
Transport Layer Security
byIbrahiem Mohammed
 
SSL_and_TLS_Overview concept the nice .pptx
byyvenkateswaracse
 
Introduction to Secure Sockets Layer
byNascenia IT
 
669671684-Ch17-Crypto6e.pptx669671684-Ch17-Crypto6e.pptx
bytahircs1
 
SecureSocketLayer.ppt
byPranavUndre1
 

More from wolfSSL

PDF
FIPS 140-2 Validations in a Secure Enclave
bywolfSSL
 
PDF
wolfSSL TLS 1.3 Support in 2018
bywolfSSL
 
PDF
wolfSSL Performance Improvements 2018
bywolfSSL
 
PDF
wolfSSL Year In Review, 2013
bywolfSSL
 
PDF
Secure Communication: Usability and Necessity of SSL/TLS
bywolfSSL
 
PDF
Kerberos + Android: A Tale of Opportunity
bywolfSSL
 
PDF
yaSSL 2010-2011 Technical and Community Update
bywolfSSL
 
PDF
Securing MySQL with a Focus on SSL
bywolfSSL
 
PDF
Securing memcache
bywolfSSL
 
FIPS 140-2 Validations in a Secure Enclave
bywolfSSL
 
wolfSSL TLS 1.3 Support in 2018
bywolfSSL
 
wolfSSL Performance Improvements 2018
bywolfSSL
 
wolfSSL Year In Review, 2013
bywolfSSL
 
Secure Communication: Usability and Necessity of SSL/TLS
bywolfSSL
 
Kerberos + Android: A Tale of Opportunity
bywolfSSL
 
yaSSL 2010-2011 Technical and Community Update
bywolfSSL
 
Securing MySQL with a Focus on SSL
bywolfSSL
 
Securing memcache
bywolfSSL
 

Recently uploaded

PDF
Taxi App UIUX Design for Seamless Ride Booking
byV3CUBE TECHNOLABS
 
PDF
20260201 [FOSDEM] gomodjail - library sandboxing for Go modules.pdf
byAkihiro Suda
 
PDF
AI-native development: from Prompt to Platform
byMaxim Salnikov
 
PDF
Image and video processing: From Mars to Hollywood with a stop at the hospita...
byHarinath Palavalli
 
PDF
apidays Amsterdam 2025 | APIs with a Purpose
byapidays
 
PDF
Massage Booking App Development Company
byV3CUBE TECHNOLABS
 
PDF
Track Phone Location on iPhone (2026)_ What Actually Works, What’s a Scam, an...
byOlive Dimitrescu
 
PDF
谷歌留痕技术教程[ 𝙩𝙤𝙥 𝟮𝟯𝟯. 𝙘 𝙤𝙢 ]
by6stynggfo
 
PPTX
Best Digital Marketing Company in Lucknow
bydigitallearning9277
 
PDF
Physiotherapist App Development for Modern Rehabilitation
byV3CUBE TECHNOLABS
 
PDF
Monitoring your MySQL Server's Health Trends
byIgor Donchovski
 
PPTX
BUSY Software Business Management Solution.pptx
byMoving Cloud
 
PDF
Project Tracking in Software Project Management
bySahanaBarveen1
 
PDF
The Growing Impact of Blockchain and Web3 on Digital Ownership With Paul Inou...
byPaul Inouye
 
PPTX
GraphQL Day Paris 2025 | Bringing DevOps to GraphQL with the Apollo GraphOS O...
byapidays
 
PDF
apidays Australia 2025 | Orchestrator vs. Choreography
byapidays
 
PPTX
Recent Data Breaches in Cyber World.pptx
byyoshuaImmanuel1
 
PDF
Artificial Intelligence Planning (Harinath Palavalli)
byHarinath Palavalli
 
PDF
Why I Volunteer at FOSDEM and You Should Too
byImma Valls Bernaus
 
PDF
Animated Safety Induction: A Smarter Way to Onboard for Workplace Safety
byTECH EHS Solution
 
Taxi App UIUX Design for Seamless Ride Booking
byV3CUBE TECHNOLABS
 
20260201 [FOSDEM] gomodjail - library sandboxing for Go modules.pdf
byAkihiro Suda
 
AI-native development: from Prompt to Platform
byMaxim Salnikov
 
Image and video processing: From Mars to Hollywood with a stop at the hospita...
byHarinath Palavalli
 
apidays Amsterdam 2025 | APIs with a Purpose
byapidays
 
Massage Booking App Development Company
byV3CUBE TECHNOLABS
 
Track Phone Location on iPhone (2026)_ What Actually Works, What’s a Scam, an...
byOlive Dimitrescu
 
谷歌留痕技术教程[ 𝙩𝙤𝙥 𝟮𝟯𝟯. 𝙘 𝙤𝙢 ]
by6stynggfo
 
Best Digital Marketing Company in Lucknow
bydigitallearning9277
 
Physiotherapist App Development for Modern Rehabilitation
byV3CUBE TECHNOLABS
 
Monitoring your MySQL Server's Health Trends
byIgor Donchovski
 
BUSY Software Business Management Solution.pptx
byMoving Cloud
 
Project Tracking in Software Project Management
bySahanaBarveen1
 
The Growing Impact of Blockchain and Web3 on Digital Ownership With Paul Inou...
byPaul Inouye
 
GraphQL Day Paris 2025 | Bringing DevOps to GraphQL with the Apollo GraphOS O...
byapidays
 
apidays Australia 2025 | Orchestrator vs. Choreography
byapidays
 
Recent Data Breaches in Cyber World.pptx
byyoshuaImmanuel1
 
Artificial Intelligence Planning (Harinath Palavalli)
byHarinath Palavalli
 
Why I Volunteer at FOSDEM and You Should Too
byImma Valls Bernaus
 
Animated Safety Induction: A Smarter Way to Onboard for Workplace Safety
byTECH EHS Solution
 

wolfSSL and TLS 1.3

  • 1.
    Talking about TLS1.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 theInternet 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 PrintersApplications Connected Home Industrial Automation M2M Routers We Secure the Internet by Securing Data
  • 5.
    Three Main Areasof 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.
  • 7.
  • 8.
  • 9.
    wolfSSL Product Licensing DualLicensed! ● Clean room SSL/TLS and Cryptography ● wolfSSL owns the Copyright
  • 10.
  • 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.
  • 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 forPortability, 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 toSecurity 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 OurWebsite ○ www.wolfssl.com ● On GitHub: ○ github.com/wolfssl/wolfssl Downloading wolfSSL
  • 19.
    SSL/TLS History andProtocol A little background before we talk TLS 1.3
  • 20.
    Authentication ● Server istypically 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 varietyof 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 betweenTransport and Application layers What is SSL / TLS?
  • 26.
    ● TLS (upto 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 CipherSpec 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.
  • 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 RecordHeader Format TLS Sub-Protocols
  • 34.
    TLS Handshake (upto TLS 1.2)
  • 35.
    SSL/TLS Handshake ● ClientHello ○ 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 ● ClientHello 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 ServerHello 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 ServerHello 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 ServerHello 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 ● HelloExtensions ○ 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 ServerHello 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 ServerHello 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 ServerHello 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 ServerHello 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 ServerHello 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 ServerHello 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 ServerHello 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 ServerHello 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 ServerHello 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 ServerHello 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 ServerHello 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 ServerHello 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 ServerHello 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 ServerHello 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 ServerHello 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 ServerHello 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 ServerHello 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 ProtocolFormat TLS Handshake
  • 59.
    TLS Vulnerabilities Found inearlier versions of SSL / TLS
  • 60.
    ● There havebeen 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 AgainstSSL/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-leakMade Easy ● Affects connections using compression ● Fix: Don’t use compression with SSL/TLS CRIME
  • 63.
    MAC calculation includes13 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 OpenSSLusers 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 OnDowngraded Legacy Encryption ● Affects SSL 3.0 connections ● Fix: Don’t use SSL 3.0 POODLE
  • 66.
    ● Affects implementationsthat do incomplete ASN.1 decoding ● Fix: Use an implementation that does correct ASN.1 decoding BERserk
  • 67.
    Factoring RSA ExportKeys ● 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 weakkeys that the outdated stream cipher RC4 can sometimes generate ● Fix: Stop using RC4 Bar Mitzvah Attack
  • 69.
    ● Exploits legacySSL 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: ○ Astatic (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 fromObsolete 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 withObsolete 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 on64-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.
  • 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 ● Symmetricalgorithm 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 ● Performanceenhancement ● 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 HandshakeMessages ● 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 DerivationFunctions ● 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 ● Sessionresumption 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 3basic 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*} vParams {Certificate*} ^ {CertificateVerify*} |Auth {Finished} v <-------- [Application Data*] ^ {Certificate*} Auth | {CertificateVerify*} v {Finished} --------> [Application Data] <-------> [Application Data] TLS 1.3 - FULL Handshake
  • 88.
    ● Client sendsClientHello 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 processesClientHello ● 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 sendsEncryptedExtensions ○ 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 clienthas 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 HandshakeVariants! 1. Resumption and Pre-Shared Key (PSK) 2. Zero-RTT Data (0-RTT)
  • 97.
    TLS 1.3 OptimizedHandshake Variants 1. Resumption and Pre-Shared Key
  • 98.
    ● Resumption andPre-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 andPre-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 andPre-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 andPre-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 OptimizedHandshake 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 doesTLS 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.
  • 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 inwolfSSL ● Update on wolfSSL TLS 1.3 support ● How to use TLS 1.3 today!
  • 117.
    ● Draft 18Support ● 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 exampleclient 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 exampleclient 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 currentlysupports 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 newclient/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 notsend 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)DHEkey 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 thekeys 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-handshakeauthentication 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 acertificate 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 clientconnecting 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 serveraccepting 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 themaximum 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 earlydata to the server int wolfSSL_write_early_data(WOLFSSL*, const void*, int, int*); wolfSSL TLS 1.3 API Usage
  • 132.
    ● Read anyearly 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 Advancesthe Protocol World class testing helps keep it bug free
  • 135.
    Importance of TestingSecurity 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 Whatit 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 SuiteTesting 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 SuiteTesting $ ./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 Whatit 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 Whatit 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 MemoryErrors 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 Whatit 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 Whatit 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 PartyTesting 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 Whatit 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 Alsoadded this year: - Libfuzzer - Tlsfuzzer - OSS-Fuzz - AFL
  • 149.
    J. Continuous Integration Whatit 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 TestCycle 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