 Hello everyone our next talk is about TLS 1.3 and what you should know as developers. Let's all welcome Daiki So Hello, everyone. This talk is about TLS 1.3. I'm Daiki Weno working in Red Hat Clip Team so I Think everyone is already familiar with the TLS 1.3, but I'll quickly recap TLS 1.3 is a is a successor of TLS 1.2 and the final standard was published in last summer After four years of development it has basically three major improvements, low latency Sorry So yeah, so it has basically three major Sales points, low latency and more security and cleaner protocol So low latency today TLS clients Commodity and probably most of most people have smartphones and with web browsers and also a bunch of Applications are talking TLS underneath. On the other hand the server need to handle a lot of connections So avoiding unnecessary latency is quite important these days So in TLS 1.2 to establish the secure communication channel it required two round trips In TLS 1.3 it can start With only one round trip. So it makes huge difference in initial connection so more security TLS 1.3 TLS 1.3 brought some modern crypto primitives like EDDSA. It's also Removed some legacy algorithms Which are considered as insecure today and in particular All the symmetric ciphers are only used in AAD mode There are many protocol refactoring, but I pick these two cipher suites organization and session resumption in TLS 1.2 there are more than Okay Sorry for the instability In TLS 1.3 there are over 100 of cipher suites defined That's because a cipher suites consists of four elements That is key exchange algorithm and cipher algorithm and mark algorithm and hash algorithm in TLS 1.3 Key exchange algorithm was moved to other part of the protocol and cipher and mark algorithm are combined into one cipher algorithm thanks to AAD mode and In the other result The total number of cipher suites is now reduced to five Session resumption In TLS 1.3 1.2 The session resumption is mainly done using session ID so that means The server need to store the security parameters for the client into a database and When resuming the connection the server need to Look up the database that makes the server stateful In TLS 1.3 it only allows session resumption with session tickets that is That is basically encrypts the security parameters in Tickets and pass it to the client and the client then send it back to the server with the ticket when resuming so Basically the server Use the clients as an external database This is not a new idea and it can be also useful use usable in TLS 1.2, but it's also Bring some for the security with the DHE key exchange when used with TLS 1.3 So TLS 1.3 is all good. So how do I use? TLS 1.3 Actually basically nothing So major libraries for example OpenSSL, VNU TLS, NSS all support TLS 1.3 already But There are actually new features that need to be accessed through new APIs that are Post-hand shake authentication key update and the links hiding and finally zero RTT mode So before looking into the detail of the API, so Let's think about what is a good to API So some people say usability is Most important factor and some other people say flexibility is more important so usability so Usable library should should be easy to use and hard to misuse to achieve this goal One common suggestion is using half-man coding based on usage patterns that is to require writing less code for common use cases and require writing more code for uncommon or Potentially insecure use cases So this is about the security libraries so Default behave it is also important that default behavior is as aligned to safe side Yeah, and flexibility So those major libraries don't have any specific targets it can be run on small devices and also we Learn on some powerful device powerful servers data center. So So basically those libraries are designed to run to to be flexible using some callbacks or Decoupled resource access from the code and also Teres 1.3 is not the Last version of the TLS one TLS so there will be probably TLS 1.4 in 10 years so we can't predict predict the future but maybe Good to not assume some parameters are fixed but Usually those Aspects don't compromise. So we need to find some trade-off So let's look at the existing design choices So I pick three factors in those libraries one is IO abstraction That is that means It has some generic value that can be used for both TLS and non TLS connections and hand shake and shake process can be triggered through the Manual process or it's can be automatically done use through IO And resumption data it can be manually Retrieved and restored on same connection or it can be automatically tracked by the library so This is basically summary This doesn't mean it is good to about but open SSL and NSS has Share similar design principles that basically means Most of those things automatically done under food, but the beauty is is a bit manual So it requires some code to do some low low level stuff So new APIs so first post-hand shake authentication That essentially means the server can request client authentication at any time even after the hand shake That's in particular Useful when it used with HTTP server So the server can request client authentication. It is the rear that some resources really required So it can delay the authentication so Open SSL and new TLS provides similar API In the client side to indicate the post-hand shake authentication is supported and server Can request post-hand shake authentication with the second API and NSS has not in not yet implemented, but it is being worked on and Key update so Some cipher Symmetric cipher algorithms have a have a amount have a limit of the amount of data that's can be safely encrypted using a single key It's can be requested to using a new special Hand shake message called key update but it can be sent explicitly but We need to listen to NSS implement automatic key updates So basically you don't need to do anything, but if you want to send key update manually All those libraries has a similar API's and the links hiding so the TLS 3 Arrows some of the arbitrary links padding to hide the actual links of the plain text So this is useful if you transfer a series of small files from the server. So The that prevents attackers being attackers being able to guess what is actually transferred So in Open SSL It can be enabled using two two kind of API's that is first is the SSL set block padding That to pass the records to multiple of specified block size and also For more for extra flexibility. It provides callback based padding scheme With this you can add really random padding if you want In GuNu TLS They simply added to new send function It's takes path parameter So this is simple, but it's only applies to application data On the other Open SSL approach applies to all the messages. So Yeah, there are some trade-offs there and NSS doesn't implement it yet yet So the last story Zero RTT mode I already mentioned TLS 1.3 Hand shape is one round-trip basically, but it's can use It's can be It's can send Application data even earlier when the client Connects to the server in a resuming connection. So that's called zero RTT mode The sending of the zero RTT data is done in three steps First check the maximum amount of data the server would accept and send the data and Finally check if the server Heart really accepted to it and if not The client need to resend the data in one RTT So Open SSL is basically like this. So check the limit and send it And finally check check if it is accepted and resend it if not Our utility less is similar, but it need to call Hand shake Function after sending the early data Yeah Yeah, and SS is also quite similar but the point is it uses It doesn't provide special function to send the early data, but it's used Existing generic PR send function Okay Yeah But on the receiving side of the zero RTT there are some risks Because zero RTT data is encrypted using a key directly derived from the previous session so there is no forward security and Attacker can send the same data if they Deplicate the client. Hello So all those libraries has a countermeasure to these attacks and Zero RTT Open SSL provides using the method called single use tickets and utility list and NSS use Client hello recording So single use tickets is actually quite powerful idea And it is ideal if the client Use the session ticket only once But it requires some Server side stuff that tracks Issued tickets is stored in the DB and removed once it is used. It makes the server Stateful and even us sometimes session tickets are long removed So we need to keep keep the data in the sub in the database for a long time On the other hand client hello recording is to record the client hello messages in a very short time frame impact typically it is around 10 seconds and check if clients views of Ticket age and servers views of ticket age has not Doesn't have any significant gaps So it's can roll over the database every Time time frame time window is fast So let's look at the receiving API. It's can be done in two steps Enable the RTT with anti-replay and accept or reject our leader This is open SSL It's basically nothing to do because the single ticket single use ticket is already enabled In the first step and second step its loops with this special new function SSL read early data And then proceed to handle shake. This is a good idea this. It's a bit complicated It's require manual initialization first and then Set up the anti-replay mechanism with these four functions and set it and Even it requires some callbacks to access the database and then The Ali data is sent During the handle shake it need to be retrieved using callback function and yeah this is NSS it uses the same Same approach, but it is quite simple because it doesn't use database, but using uses a broom filter That that is a data structure Used to detect The entry is not in the set reliably Okay, but we Okay but It is all in the Program memory, so it might not be able to scale to Distributed servers so summary Yeah, basically TLS 1.3 is better than TLS 1.2 and TLS 1.3 brings Additional features some of them need to new APIs to access And as we have already see Some API designs may look complicated But the API designs have some reasons behind them. For example Gerality receiving is quite risky. So it require Writing some code is quite reasonable choice. So don't blame the developers and There are some resources on the web so it summarizes approaches so Yeah That's it. Thank you We have time for two questions Any questions? So you showed in your slides that the limit of early application data that you can send somehow has to be configured In the API is that a limitation in the protocol to client and server negotiating maximum amount of early data? And why why is that? Yeah so it There are TT data is only usable in resuming session So in the initial initial connection the server indicate the maximum In there Why is it limited? I thought that you in theory could send as much early data as you want during as long as the Authenticated keys are not established yet Sorry, so I don't I don't get your question. I'm sorry. What's the technical reason to limit the amount? I'm not sure Yeah Any other question? Thank you, thank you