TLS 1.3: What developers should know about the APIs Daiki Ueno - PowerPoint PPT Presentation

TLS 1.3: What developers should know about the APIs Daiki Ueno Red Hat Crypto team

TLS 1.3: RFC 8446 Published in August 2018 – Low latency – More security – Cleaner protocol

Low latency: 1-RTT handshake TLS 1.2: 2-RTT TLS 1.3: 1-RTT key exchange & authentjcatjon authentjcatjon* + client Finished applicatjon traffjc

More security ● No RSA / statjc DH key exchange ● Legacy algorithms were removed ● All symmetric ciphers are AEAD

Protocol refactoring ● Ciphersuites ● Session resumptjon

Ciphersuites TLS 1.2 > 100 Key Cipher MAC Hash Exchange Algorithm Algorithm Algorithm TLS 1.3 = 5 k e y _ s h a r e extension Cipher Hash Algorithm Algorithm (AEAD)

Session resumptjon 1 st connectjon TLS 1.2 Client and server share the secret Server stores the state in 2 nd connectjon Client keeps the secret the session cache Client sends the previous session ID

Session resumptjon 1 st connectjon TLS 1.3 Client and server share the secret Session tjcket Server doesn’t need to 2 nd connectjon Client keeps the secret keep the secret Client sends back the tjcket Forward secure if DHE key exchange is used

How can I use TLS 1.3? ● Enabled in major libraries – OpenSSL, GnuTLS, NSS ● No Litule code changes are needed – for typical use-cases ● New features need new API

New features ● Post-handshake authentjcatjon ● Key update ● Length hiding ● 0-RTT mode

What is a good API? ● Usability ● Flexibility

Usability ● Easy to use, hard to misuse ● “Hufgman coding” by usage patuern – Less code for common use-cases – More code for uncommon use-cases ● Default to be safe

Flexibility ● Scale from embedded to servers – Decouple resource access from the code – Provide callbacks ● Future proof – There will probably be TLS 1.4 – Don’t assume parameters are fjxed

What is a good API? Usability Flexibility Christoph Strässler (CC-BY-SA 2.0)

Existjng design choices ● I/O abstractjon – Generic I/O used for both TLS and non-TLS ● Handshake – Explicitly triggered or implicitly during I/O ● Resumptjon data – Manually or automatjcally tracked

Existjng design choices I/O abstractjon Handshake Resumptjon data Yes Automatjc OpenSSL Implicit / explicit (BIO) (cached per-ctx) GnuTLS No Explicit Manual Yes Automatjc NSS Implicit / explicit (NSPR) (cached per-process)

New features, new API ● Post-handshake authentjcatjon ● Key update ● Length hiding ● 0-RTT mode

Post-handshake auth ● The server can request client-auth at any tjme with a CertjfjcateRequest message ● Re-associate client’s identjty with a difgerent certjfjcate ● Can delay client authentjcatjon untjl a CertjfjcateRequest resource is actually Certjfjcate requested CertjfjcateVerify

Post-handshake auth / * c l i e n t : i n d i c a t e p o s t h a n d s h a k e a u t h * / S S L _ s e t _ p o s t _ h a n d s h a k e _ a u t h ( c l i e n t , 1 ) ; / * s e r v e r : r e q u e s t p o s t h a n d s h a k e a u t h * / S S L _ v e r i f y _ c l i e n t _ p o s t _ h a n d s h a k e ( s e r v e r ) ; / * c l i e n t : i n d i c a t e p o s t h a n d s h a k e a u t h * / g n u t l s _ i n i t ( & c l i e n t , . . . | G N U T L S _ P O S T _ H A N D S H A K E _ A U T H ) ; / * s e r v e r : r e q u e s t p o s t h a n d s h a k e a u t h * / g n u t l s _ r e a u t h ( s e r v e r , 0 ) ; Not implemented

Key update ● Peers can update traffjc keys with a KeyUpdate message ● There is a limit of data that can be safely encrypted with a single key – GnuTLS and NSS KeyUpdate implement automatjc KeyUpdate key updates

Key update / * s c h e d u l e k e y u p d a t e , a n d r e q u e s t t h e p e e r t o * u p d a t e t h e i r k e y * / S S L _ k e y _ u p d a t e ( s , S S L _ K E Y _ U P D A T E _ R E Q U E S T E D ) ; / * s c h e d u l e k e y u p d a t e , a n d r e q u e s t t h e p e e r t o * u p d a t e t h e i r k e y * / g n u t l s _ s e s s i o n _ k e y _ u p d a t e ( s , G N U T L S _ K U _ P E E R ) ; / * s c h e d u l e k e y u p d a t e , a n d r e q u e s t t h e p e e r t o * u p d a t e t h e i r k e y * / S S L _ K e y U p d a t e ( s , P R _ T R U E ) ;

Length hiding e n c r y p t e d _ r e c o r d 2 3 0 x 0 3 0 3 l e n g t h c o n t e n t c o n t e n t p a d d i n g t y p e P r e v e n t a t t a c k e r s b e i n g a b l e t o g u e s s t h e a c t u a l c o n t e n t l e n g t h

Length hiding / * d e f a u l t t o p a d m u l t i p l e o f 4 0 9 6 * / S S L _ s e t _ b l o c k _ p a d d i n g ( s , 4 0 9 6 ) ; / * o v e r r i d e t h e p a d d i n g w i t h a c a l l b a c k p e r m e s s a g e * / S S L _ s e t _ r e c o r d _ p a d d i n g _ c a l l b a c k ( s , p a d d i n g _ c b ) ; / * s e n d a p p l i c a t i o n d a t a * / S S L _ w r i t e ( s , d a t a , s i z e ) ; s t a t i c s i z e _ t p a d d i n g _ c b ( S S L * s , i n t t y p e , s i z e _ t l e n , v o i d * a r g ) { / * r e t u r n n e w p a d d i n g * / }

Length hiding / * s e n d a p p l i c a t i o n d a t a w i t h o u t p a d d i n g * / g n u t l s _ r e c o r d _ s e n d ( s , d a t a , s i z e , 0 ) ; / * s e n d a p p l i c a t i o n d a t a w i t h a r b i t r a r y p a d d i n g * / g n u t l s _ r e c o r d _ s e n d 2 ( s , d a t a , s i z e , p a d , 0 ) ; Not implemented

0-RTT mode TLS 1.3: 1-RTT TLS 1.3: 0-RTT key exchange & resuming handshake authentjcatjon early applicatjon data Even lower latency authentjcatjon* + client Finished

0-RTT: Sending 1. Check the maximum amount of data the server would accept 2. Send early data 3. Check if the server has accepted it; otherwise re-send the data as 1-RTT

0-RTT: Sending ❶ / * c h e c k t h e m a x i m u m d a t a t h e s e r v e r w o u l d a c c e p t * / m a x s i z e = S S L _ S E S S I O N _ g e t _ m a x _ e a r l y _ d a t a ( S S L _ g e t 0 _ s e s s i o n ( c l i e n t ) ) ; i f ( s i z e > m a x s i z e ) r e t u r n - 1 ; / * s e n d e a r l y d a t a b e f o r e h a n d s h a k e * / ❷ S S L _ w r i t e _ e a r l y _ d a t a ( c l i e n t , d a t a , s i z e , & w r i t t e n ) ; / * d o h a n d s h a k e , e i t h e r e x p l i c i t l y o r i m p l i c i t l y * / ❸ / * c h e c k i f t h e e a r l y d a t a w a s a c c e p t e d * / s t a t u s = S S L _ g e t _ e a r l y _ d a t a _ s t a t u s ( c l i e n t ) ; i f ( s t a t u s ! = S S L _ E A R L Y _ D A T A _ A C C E P T E D ) { / * e a r l y d a t a w a s r e j e c t e d ; r e s e n d i t a s 1 - R T T * / S S L _ w r i t e ( c l i e n t , d a t a , s i z e ) ; }

0-RTT: Sending ❶ / * c h e c k t h e m a x i m u m d a t a t h e s e r v e r w o u l d a c c e p t * / m a x s i z e = g n u t l s _ r e c o r d _ g e t _ m a x _ e a r l y _ d a t a _ s i z e ( c l i e n t ) ; i f ( s i z e > m a x s i z e ) r e t u r n - 1 ; / * s e n d e a r l y d a t a b e f o r e h a n d s h a k e * / ❷ g n u t l s _ r e c o r d _ s e n d _ e a r l y _ d a t a ( c l i e n t , d a t a , s i z e ) ; g n u t l s _ h a n d s h a k e ( c l i e n t ) ; ❸ / * c h e c k i f t h e e a r l y d a t a w a s a c c e p t e d * / f l a g s = g n u t l s _ s e s s i o n _ g e t _ f l a g s ( c l i e n t ) ; i f ( ! ( f l a g s & G N U T L S _ S F L A G S _ E A R L Y _ D A T A ) ) { / * e a r l y d a t a w a s r e j e c t e d ; r e s e n d i t a s 1 - R T T * / g n u t l s _ r e c o r d _ s e n d ( c l i e n t , d a t a , s i z e ) ; }