 All right, so please join me in welcoming Alfonso and Alejo. Hi Defcon, our presentation today is about TLS 1.3, which is going to be the next major version of TLS, which will be released soon. It has a new feature, which is called Zero RTT, Zero Round Trip time and resumption, which speeds up the session resumption. However, it has some security impacts. This is a known issue that has been acknowledged by the protocol specification. So our 10 today is to give you a better understanding of TLS 1.3 and this new feature, Zero RTT. Two is to raise awareness across the audience about the potential risks of using Zero RTT. And three is to provide you recommendations about how to mitigate those risks of using Zero RTT. Finally, a minor disclaimer. What we are going to discuss here is just our own opinion and does not reflect the view of our employer. Hi Defcon, my name is Alfonso García Guacil. I work for Cisco as a senior security consultant. I mostly do penetration testing and some research and development focused on offensive security and I'm glad to be here for the first time. Hi, my name is Alejo Murillo-Moya. I am a senior security consultant at Cisco. I am the red team lead for EMEAR, Europe, Middle East, Africa and Russia. I have more than 10 years of experience in the security field and as Alfonso said, we are really happy to be here at Defcon. So once we have introduced ourselves, let's introduce TLS 1.3. So first a bit of history. So four years ago, a working group was created at that working group had a mission. That mission was to develop the new version of TLS, TLS 1.3. There has been 28 iterations of the protocol specification and as you can imagine, that has been a long journey. So now with this introduction, let's move on to some of the good things that TLS is going to bring to us, 1.3. One of the good things is that it has followed a keep the simple approach. So only five ciphers are going to be defined on the TLS 1.3 specification. That means that the implementation is going to be easier and also that will reduce the complexity of the protocol. If we compare this to previous version of TLS, that's a huge improvement because if you recall, those previous versions support those sense of ciphers. Another good thing is that TLS 1.3 is not going to be vulnerable to previous known attacks against previous versions of TLS. So for example, you can think about RC4, RSA, CVC increase in mode, or even compression attacks. Good luck finding them on TLS 1.3 because you are not going to find them. Also another good thing is that it supports perfect forward secrecy by default. It's by default enabled and that's something that is not going to be optional like on previous version of TLS. There's a quick recap of the forward secrecy. Imagine that an attacker is able to store all your secure communications. Perfect forward secrecy is going to ensure that even that if the attacker managed to steal the server private keys, he wouldn't be able to decrypt your secure communications because ephemeral session keys were used. Also the TLS 1.3 protocol went through some formal security analysis which basically it took and the protocol specification, its machine state, its security assumption and those were analyzed and some witnesses were identified. With that information, the protocol was refined and improved before its final release. Let's talk now about the compatibility issues. So last year, Chrome and Firefox were doing some field tests and what they found is that around five percent of the users were not able to connect to the website using TLS 1.3. They analyzed the data and they found that that behavior was caused by something called middle boxes. A middle box is a corporate networking device that is inspecting or intercepting HTTPS. What happened at the end is that they made some modifications to the protocol specifically they changed the TLS 1.3 handshake in order to look like one looks like a TLS 1.2 session resumption and that fixed the issues with the middle boxes. So at the end the protocol it may not be as pure as it could be but given circumstances I think it was the right thing to do. Then let's focus on the topic for this presentation. So one of the things that the working group wanted to do is to have a faster TLS and that's especially important on mobile networks due to the latency. So CRTT was created. CRTT is a session resumption that can push data to the server also called early data. Basically the important thing about the CRTT is that it should have a session ticket the message and also the early data will be encrypted using a pre-shared key and then when the server receives that message if he can decrypt it it will process that data. So it seems that CRTT is making things faster because it's pushing data to the server however it has some security implications. So which are those security implications? The first one is that we lose perfect forward secrecy on CRTT messages and the second thing is that CRTT messages could be vulnerable to replay attacks. Yes and that's something really important because we know TLS and replay attacks was never one of our concerns but that's going to change with CRTT. So you may be wondering hopefully I have convinced you or take your attention on the previous slide but maybe you can say that okay you're not going to use TLS when monitoring or that TLS is not yet an official internet standard which is true but however you should at least I will try to convince you because TLS is going to be presenting their browsers, implementations or even CDNs right now. So for example it will look at Firefox. You will see that Firefox has been supporting TLS 1.3 and CRTT by default for months. Also Chrome is supporting TLS 1.3. If we move to the implementations we can see that OpenSSL on the next version of OpenSSL which is going to be 1.1.1 is on pre-release status and will support TLS 1.3 with CRTT. Same goes for boring SSL and maybe you have heard the news but Facebook has just released their own implementation of TLS 1.3 which also supports zero RTT and then we have the CDNs and the CDNs may be supporting or planning to be supporting zero RTT also. Just going back a bit about Facebook and their implementation they mentioned on that announcement that they are receiving around 50% of all the traffic that they are receiving is using TLS 1.3 which is a lot. So that means that TLS 1.3 is already with us and its use is going to be increased over the upcoming weeks and months. So let's dig a bit more about TLS specifically on the TLS 1.3 handshake. So first the client will send a client hello message to the server making some educated guesses about which options the server would prefer. The server will receive that message and then we'll send back the required cryptographic material in order to complete the handshake including the certificate and a proof that he has the secret keys of that certificate. The client will receive that message, it will verify that the certificate is valid in order to ensure that he's talking with the right end point. He will also check for that proof of knowledge and then he will send that finished message saying okay we have finished the TLS handshake, let's start the secret communications. And as you can see here after the TLS 1.3 handshake has been completed application data can be transmitted securely. We have also added the new session ticket message because that's important and it will be used in the future. So now let's discuss the CRDT message which is used to do session resumptions. So imagine that we have a browser that needs to resume the previous established session with a web application what it's going to do is going to create a CRDT message. But the bits that are interesting to us is that it will contain a session ticket and it will contain data that is going to be pushed to the server that will be encrypted using a pressure key. That will be sent to the server. The server will process that information, we will check if the session ticket is valid one and also we'll try to decrypt the data. If the encryption is successful it will push that data to the web application and then it will send the response back to the to the client including a new session ticket. And then the client will receive that message and will say okay we have done this session resumption then I'm not going to send you any more early data let's continue the conversation and as you can see there the application data will be sent securely. So hopefully as you can see it may be feasible to do replay attacks and that's because the only thing that an attacker needs to have is to have that message that can be replayed to the server and the server will just check that he has a valid session ticket and that he can decrypt the data. So let's see how a real attacker may look like. So imagine that we have a banking application and there is a customer that is using the banking application because he wants to do a money transfer to one of his friends. However he doesn't know that this friend is not really trustworthy because he's the attacker that is on that diagram. Okay so the customer when he clicks submit on the browser form the browser is going to create a zero RTT message that will include that HTTP request of transfer funds and this message will have a session ticket and then this data encrypted with a pressure key. Oops sorry that message will be sent to the server in this case the attacker is not going to do anything with it he will only copy that message because he plans to replay it later on. So then the server will receive the message he will decrypt because he has the right pressure key and will send that message up to the to the web application which will perform the first money transfer and then the server will send back the response to the browser. So what could happen if the if the attacker replays that original message? Let's see. So as that message has the right session ticket and is encrypted with the right pressure key the server will receive it process it send to the web application which would perform the second money transfer and then as we can see the attacker can do this as many times as he wants he just need to keep repaying that original message again and again. So is it everything as bad as this looks like? Not really. Okay the working group put a lot of effort in order to describe these potential security risks and security implications regarding the zero RTT functionality and they also added within the RFC the recommended protections and even mitigations. One of those two protections is single use tickets. With single use tickets the server is able to prevent replay attacks because it has a database of fresh session tickets. How it will work is when the server sends a session ticket to the browser it will add to his database and when he receives a zero RTT message with a session ticket he will verify that that session ticket is on the database and then he will accept the message and then will remove that session ticket from the database of fresh session tickets. The next time he receives a second message, zero RTT message, he will check again that session ticket and will find that it's no longer in the database and then he will read that message because it means that it is a replay attack. So it seems that this protection is quite good however it has one potential issue and it's how you keep that database synchronized in medium or big environments and that's the challenge here is to synchronize the database across multiple systems without allowing and without creating an opportunity window that an attacker can take advantage of. Another protection will be the client-hello recording. Same is similar to before in this instance the server will keep a list of all the client-hello that he is receiving so the first time that he receives a zero RTT message he will store that client-hello on his list and if he receives that message again he will see that that client-hello has been already processed so he will read that zero RTT message. Same as before the challenge here is how you synchronize that list on global and distributed environments. Another mitigation that is specified within the RFC is called freshness checks. So when the client is sending zero RTT messages to the server it's including a time stamp which is basically from the perspective of the client when that message was sent. So what a server can do is that he can just read any messages that has arrived outside an acceptable time frame window. Another protection that is mentioned in the RFC is application profiles and according to the TLS 1.3 specification or to the RFC let me see if I can quote it properly. Application protocols must not use zero RTT data unless it has a profile that defines its use which basically means that the application should be able to define which functionality or which paths are going to be exposed over zero RTT. Application profiles is a RFC which is related to TLS but it's still working progress. And after that we can have different other types of protections or mitigations. For example OpenSSL has decided to have segregated APIs for the traditional TLS and this new zero RTT TLS feature. That means that if a developer wants to use zero RTT it's because he really wants to do it and because he ideally knows what which are the potential security risks. Other security controls can be added also at the browser or at the server level like for example not allowing zero RTT on only allowing zero RTT messages on HTTP safe methods which would be get, head or option methods. Finally what also can be done is just for example for the requests that are being sent to the web application make sure that those requests are idempotent. What means that? It means that the final state of the web application or backend it will be the same independently of how many times you receive the same request. If it's once or multiple times it shouldn't matter. Now let's see here a table that we have put together of after our research of what we have seen so far. So the first two columns are basically related to the two protections that are mentioned on the RFC. Single use tickets and client hello recordings. You don't need to implement both you just need to implement one of those two. Then the third column is for application profile and finally we have added a fourth column for some interesting notes. So as you can see here open SSL is using single use tickets and as I mentioned before it has different APA in order to handle the zero RTT and normal TLS. Warrior SSL has a support for zero RTT but it's disabled by default. Cloudflare is working to implement single use tickets. They have implemented application profiles using HTTP headers and they have zero RTT disabled by default. You can enable it but you need to go to the dashboard and doing that explicitly and if you enable that zero RTT will only be available on HTTP safe methods like get and they added on top of that another protection which is that they are only allowing get methods without parameters for zero RTT messages. Then we have Chrome. Chrome has no zero RTT at the moment support and Firefox is support zero RTT by default and as we can see here it will only send zero RTT messages on safe methods. In this case get request will be over zero RTT but not post request. Okay so we are going to show the potential impact of zero RTT when an attacker is in the middle of the communications path between the web browser and the web server. Of course both the web browser and the web server will have TLS 1.3 and zero RTT enabled. As a web browser we are going to use Firefox with HTTP 2 enabled which is already enabled by default. As a victim application we are going to use our own banking application which uses a get request with REST format to perform a money transfer. Firefox only uses zero RTT for safe methods. However how many applications you get to perform actions which should be made using post or other methods but we see a lot of them while we are performing web service assessments. In a normal situation in which the web browser well in which there is not any attacker in in the middle of the communications the web browser will only show a message or will only send a request using zero RTT the first one. Then the TLS connection would be established and the following request will be sent using this created secure channel until the KIPA lifetime times out. So this is why we think that it is highly unlikely that an attacker could catch a tempting request to be replayed only with passive techniques but let's see this with a video. As I mentioned before we are going to use the latest Firefox version. This is the tool that we created to test the replay attacks. The tool is in the middle of the communications and in this first mode it will only show a message when zero RTT is detected. The tool is not a HTTPS proxy it is only a TCP proxy which means that it is not the TLS termination point and therefore it cannot see the unencrypted data. However it can see the TCP the TLS packet headers and using this information it can detect when zero RTT is used. This is our banking application. The domain points directly to the web server and as you can see the certificate was correctly validated by the web browser so I would not note that we are performing the money in the middle. As you are performing requests nothing is shown by the tool because nothing is sent using zero RTT. As seen on the timer we go forward three minutes without performing any request to consume the KIPA lifetime. Now that the KIPA lifetime has been consumed the first request and only the first request that the user performs will be sent using zero RTT. This is the request and this request could be potentially replaced but the next requests until the KIPA lifetime times out again will be sent using the established secure channel. This is why we think that passive attack is unlikely to work. Okay but can we control when the web browser uses zero RTT? So can we improve this attack? The response is let's see. This is the TLS handshake that Alejo already explained. After a full TLS handshake or a zero RTT handshake we want the server to receive the HTTP request and the browser to receive the server response. After that if we don't do anything the next request will be sent using the established secure channel like we show before. However we can finish the connection at the TCP layer by sending fins or reset packets and then the browser will send the next HTTP request using zero RTT. If we do this for every new TLS connection there will be much more chances that the attacker can replay the request that he wants because the most part of the request will be sent using zero RTT. Let's see this with another video. Well now the tool is configured to do this technique. Now it's hosted behind Cloudflare with zero RTT enabled. As you can see now the most part of the requests are sent using zero RTT. Well due to the use of HTTP 2 some of the get requests are not really sent over zero RTT. Only the HTTP 2 preface is sent over it and the real request is sent later in the established secure channel. However we have noticed that for the requests initiated by Ajax the most part of them are sent using zero RTT. Now we perform a money transfer of two dollars but we don't want to replay it just to demonstrate that we are not tricking you and as you can see we have one money transfer. Now we perform a money transfer of three dollars and this time we want to replay it three times and refreshing the transaction list it can be seen that the attack was successful because well the only the user only sent one money transfer but we have four. Okay but now we have seen that a replay attack can work against a vulnerable application which is hosted behind a server which doesn't implement single use ticket or client help. What about a server that demands these techniques. Is it possible to replay yet? Well as you can imagine the response is yes and I'm going to try to explain how. In this situation the web browser will send money transfer request using zero RTT. The attacker intercepts it and sends it to the web server. The web server will accept it because it is a fresh zero RTT. At this moment the web browser is waiting for the server confirmation that the zero RTT was accepted but the attacker sends this message. The attacker can well open in any UTCP connection but he sends again the same zero RTT packets to the web browser to the web server. And now the web server rejects it because it is implementing single use ticket and a simple reply like this one doesn't work because it is a non fresh zero RTT. The attacker now sends back the rejection to the web browser. From the point of view of the web browser the zero RTT was rejected and no money transfer was made. However in reality one money transfer was made. According to the TLS 1.3 RFC after a zero RTT rejection a full handshake has to be done. So the web browser and the web server do the full handshake and after that the web browser since it thinks that the money transfer was not made at the first time now it repeats the request the HTTP request and the web server accept it because now it is not using zero RTT it is using the established secure channel. So after the attack from the point of view of the web browser only one money transfer has been made but really what has happened is that two money transfers has been made. With this we can basically perform only one replay but at least we can perform one replay against a server which has these anti replay protections. Let's see this in a new video. The tool is now configured to perform this last replay technique in combination with the killing technique of zero RTT. The banking application is now hosted behind a reverse proxy which has enabled zero RTT. This reverse proxy uses OpenSSL the pre-release version which implements single use ticket. Like in the previous video we perform a money transfer of two dollars without replaying it and refreshing the transactions list can be seen that only one money transfer was made because we didn't perform any replay attack. However now we perform a money transfer of three dollars and we perform this last replay technique in which the web browser helps us and as you can see here instead of having one money transfer we have two money transfers so the attack was successful. Okay this brings me to tell you that we are going to release this tool and if you want to use it you have to redirect somehow the traffic from the web browser to the tool. As you saw in the in the demos we were using tags for the HTTP requests like for example send money. The tags are based on the encrypted packets lens and you can create them in the monitor mode of the tool. The tool also provides two other modes to perform the two different replay techniques and also with the kill parameter it performs the killing technique to force the web browser to use zero RTT and all. The tool should be available now at this Github repo. So let's talk about the side effects of zero RTT. When we deploy previous version of TLS how the data is being transmitted is totally transparent to the web application. However with zero RTT that's going to change because it creates a dependency between the TLS and the application layer which was not present before so that means that the application will need to know if zero RTT is being used so he can prevent replay attacks and at the end the ultimate responsibility would be on the application itself to prevent replay attacks and you can ask how we can do that. Let's see what we can do. So first thing that you can do and you should do is disable zero RTT and only enable it if you are really really really sure of what you're doing. Other things that can be done is just for example you can try to make sure that your application is and is replay safe but that can be quite a challenge but if you go there what you can do is you can apply I street cross request for the policy not only at the session level not only at the form level but at the request level. Another mitigation that you can deploy is to migrate those get requests that are not replay safe to post requests and why because most likely the browsers are not going to send zero RTT data on post requests. Also you can make sure regarding the web services and especially with the rest web services you need to make sure that those are developed properly and that get, post, put and delete are used properly and with regarding the get methods you need to make sure that those sessions are either read-only or idempotent and finally you should deploy a street application profile which basically defines which are the functionality that you really want to expose over zero RTT. To finish this presentation we have some takeaways the first one is that TLS 1.3 is awesome and all of us will use it but take care with zero RTT. The second one is that your application should be zero RTT a web to prevent side effects and the last one is that maybe you need to change your application or your server configuration in order to prevent replay attacks. Thank you so much and if you have any questions we will be around.