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