 Okay, anyone? Okay, okay, perfect. Okay, perfect. We can start. So welcome for who is arrived now. We continue our talks and we're talking about automated analysis of TLS. I will present Thailand. Sorry for. So welcome at all and enjoy the talk. Okay, so as I was saying, I'll be talking about an automated analysis of TLS 1.3 and the monkey reference should become clear as we go. So TLS 1.3 has been a very hot topic. It still is, I'm told. But what a lot of people don't realize is that getting to the TLS 1.3 protocol that we have today has involved a significant amount of collaboration between academia and industry. And what I'm going to talk about today is an academic effort to prove that TLS 1.3 is secure. So this is work that I did as part of my PhD just prior to starting at Mozilla. Okay, what is TLS? Every TLS talk needs a what is TLS slide. So TLS is a network protocol. You can think of it as being sandwiched between the transport layer and the application layer and this is the TCP IP stack. And the goal of TLS is to provide security services to applications or to protocols running at the application layer. So HTTP will run over TLS, TLS will run over TCP and this gives us HTTPS. Now we all use TLS every single day. When you check your email, if you use Facebook, any sort of online banking, even your encrypted signal messages go through TLS tunnels. And even IoT devices like that baby camera over there need to be able to talk TLS when they phone home, when they connect to the back end server. So the web is locked in to TLS. TLS will run between a client and a server and is largely made up of two sub-protocols. And then we have the handshake protocol and the record protocol. And the goal of the handshake protocol is to provide identity guarantees for the two communicating entities and to establish the symmetric session keys that would be used as part of the record protocol to protect application data. So TLS started life as a secure sockets layer protocol, SSL, developed by Netscape Communications. And then in the mid-90s, the ITF, the Internet Engineering Task Force, took over this critical protocol and rebranded it as transport layer security. Then in 1999, we see the release of TLS 1.0, 2006, the release of 1.1, and then in 2008, TLS 1.2. And excitingly, TLS 1.3 has just been released and that was released in August of last year. So we're moving from TLS 1.2 and below to TLS 1.3, but why? So firstly, this happened where red means an attack against TLS. So weaknesses against TLS 1.2 and below really meant that we had to start thinking about a new version of the protocol. Also, quick was released. Now I don't know if you can see the diagram over there, but quick was meant as an equivalent for TCP and TLS. And quick is really fast. It's faster than TCP and TLS on initial connections and it also provides the zero RTT functionality, zero round trip time, which means that the client can start sending application data with its first flights of messages. So the TLS working group was under pressure to improve the efficiency of TLS. So these two factors combined led the TLS working group to start developing TLS 1.3 in the spring of 2014. Now what's changed? Well, in TLS 1.2 and below, we see some technical changes. We're also going to see changes on the process front and the standardization front. Now in terms of technical changes, 1.2 and below need two round trip times in initial connection before the client can start sending application data. They use static RSA and Diffie-Hellman primitives. A lot of the handshake is not encrypted. And these protocols or the handshake allowed for the negotiation are bad record protection mechanisms. So something like RC4 up until quite recently actually could have been negotiated. And RC4 is pretty bad because its key string is biased particularly in the early weeks. In comparison, TLS 1.3 has this one round trip time in initial connection and also has the zero round trip time functionality. So the client can start sending data with its first flights of messages. That it only negotiates ephemeral Diffie-Hellman. A lot of the handshake is encrypted and a lot of the record protection mechanisms have been updated. We now only allow for authenticated encryption for the record protection. Now in terms of the process for TLS 1.2 and below, the standardization was very reactive in nature. So following the announcement of an attack, the TLS working group would take a longish time to respond to that attack. They'd respond by either updating the next version of the protocol and in some cases releasing an extension which is almost like a patch. The process for 1.3 has been vastly different. It's been highly collaborative in nature. And the TLS working group has welcomed analyses from the academic community prior to the protocol being officially released so that we can find and remedy flaws before TLS 1.3 is in the wild. And it's this process, this more collaborative process to which this work contributes. So there are many different ways in which you can look at TLS. There's program verification, so that is actually looking at implementations of TLS, looking at the code, trying to find bugs that could lead to weaknesses. Then they're what cryptographers call a provable security. This is like coming up with pen and paper proofs to show that a protocol is secure. And then there's formal methods where you can use state-of-the-art's formal methods tools to show that a protocol is robust. And this is where our work falls in. Now we'll state now that I am not a formal methods expert. How a lot of these tools work is still, well under the hood at least, is black magic to me. But you don't really need to know how these tools work in order to be able to use them. Okay, so the tool that we used is known as the tamarind prover. And this is an emperor tamarind monkey. They are found in South America. So now hopefully you can see the monkey connection. And this is a symbolic analysis tool. Now, what is this? Well, it's an automated tool for protocol analysis. And how does it work? So for simple protocols, it allows you to prove properties in a very automated fashion. You can code them up and you push a button and say, go. For more complex protocols, like something like TLS, a lot more interaction with the tool is actually required. But if you get a proof in this tool, it shows that the property will hold in all possible combinations of client, server and adversary behaviors. And this is what you want. Okay, so tamarind is actually a custom constraint solver, which is masquerading as a theorem prover. So tamarind will take as inputs a property P and a system S. And then using S and the negation of P, it comes up with a set of constraints. And it tries to solve for those constraints. If it actually finds a solution, it means we have an attack. It means that P is not satisfied by S. And tamarind will spit out a very nice attack graph for you to be able to see this. If you don't find a solution, it means we have a proof. P is always satisfied by S. Now for simple protocols, this process is automated. But this is generally an undecidable problem. So you could run out of time or memory and patience. So in the case of tamarind, this isn't necessarily a bad thing because you can go back and look at the graphical user interface, look at some partial proofs and then code up some hints and feed them back into S, right? And then try again. And then hopefully the next time around, you will terminate. So how do you specify protocols in tamarind? Well, you use things called rewrite rules. And these rewrite rules transition the system from one state to the next. All right? A rule is made up of a left-hand side and a right-hand side, and there are some actions in between. So the left-hand side. In this rule, we're taking in, these things are called facts. We're taking in an in-fact. So this models data coming in from the network, which we assume the adversary is controlling. This is a state fact, which captures the state of the thread which we label with this thread ID. Now this rule can only fire if a previous rule had actually produced these facts. A rule will then spit out conclusions. This is the right-hand side. And in this rule, we're spitting out some data with an artifact that goes to the network. And again, we're updating the state. This will then be consumed by the next rule. So this is how we transition state. Now these things, the middle, these actions, they're not actually part of the transition, but they act as a log, right? So they tell us when something has happened and we use them as part of the, when we specify properties. Okay. So rules give rise to a state machine and these edges, right, correspond to rules. So what did we do with TLS 1.3? So we both model the TLS 1.3 specification on drafts 10 and 21, right? We wanted to verify the main security properties of TLS 1.3. So that's looking at the secrecy of session keys and the unilateral and mutual authentication. We found an attack in what we call draft 10 plus. So this is when we wanted to add something extra that was meant to be included in draft 11. And this provided feedback to the TLS working group and we actually helped fix the specification. And then we updated our model to reflect draft 21 and showed that the TLS 1.3 specification was actually quite sound. Or from a logical, the logical core of it at least. Okay. So this is the typical process for analyzing security property. You start with the spec. You pull out properties you want to prove and then you build a model and code those security properties and come up with proofs. If you come up with a proof, maybe you're happy. If you come up with an attack, maybe you're sad. If you're using Tamarin and it doesn't terminate, terminate you often in this state, right? So I was in that very unhappy state a lot of the time. So I'll explain what we did with TLS 1.3 by walking through all of these steps. Step one, build the model in Tamarin. Step two, encode the security properties using the Tamarin specification language and in step three, produce some proofs. All right. So draft 10, I worked there, started back in 2015 where Sam Scott and I, that's Sam, were interns at Mozilla and this is our sort of first attempt at trying to figure out what was going on in TLS 1.3 and we were trying to model in Tamarin. We wanted our model to encode honest party and actions as Tamarin rules. These honest client rules and for the server as well correspond to the processing of flights of messages and rules transition the protocol from one state to the next. Now in TLS 1.3, there are many different handshake modes that you need to be able to model. There's the initial electric curve Diffie Helman handshake, right? There's the zero RTT handshake where the client sends data immediately. There's the PSK resumption handshake which means when you want to resume a session you use a pre-shade key and there's also its Diffie Helman variant. So we had to capture all of these handshake modes in the tool and also capture the record protocol. We do this very abstractly just by modeling the client and the server sending and receiving data. This is an example of a rule. This is our first client rule and this is probably the simplest rule in the model. They got far more complex after this. And this is the client state machine and this represents all of the relevant client rules and it's the union of all the options available to a client in a single execution. So if an initial handshake were to run it would correspond to the following rules being fired in succession and eventually the client will get to state C3 where it's ready to start sending and receiving data. This is the corresponding state machine diagram for the server. We also had to encode adversarial capabilities so what the adversary can do and again you use a rule and this just gives the adversary the power to reveal long term keys and you need that when you specify properties. So we worked our way through the draft end specification and we came up with a list of properties that we could prove in tamarin and that's where they are in the specification and this is what an encoding looks like in tamarin. This is our secret session key lemma and what it says is that for all possible variables on the first line if a key is accepted at time point I and the adversary has not revealed the long term key then the adversary cannot derive this key then the adversary does not know your session key. And we aim to show that this holds in all possible combinations of client, server and adversary behaviors. So we wrote tamarin encodings for all of these properties and that's what they looked like but how did we go about proving them? And remember we're actually in this world. It's not like we're only looking at one of these state machines. Tamarin reasons about an unbounded number of sessions. So the adversary can actually use data from any of these sessions to corrupt your test session. Right, so to prove we will simplify our secret session keys lemma and that says if a secret session key is established and the adversary has not performed any reveals then the adversary cannot know the key. If we negate this logic formula we get a secret session key is established, the adversary has not performed any reveals and the adversary knows the key. So what Tamarin will do is we'll look for a protocol execution that contains the session key has been established, the adversary knows the key but it hasn't performed any reveals. If we find that the set is empty it means that the property holds. If we find a counter example, if we find a member of the set, it means we have an attack. Okay, so Tamarin translates our encoding into this constraint system because remember it's a constraint solver and it refines its knowledge until it can determine that either a property holds in all cases or there is an attack. And Tamarin will use a set of heuristics to determine what it's going to do next and it has this auto-approved functionality but it also has an interactive functionality. So you can go into the graphical user interface and help guide the proof through the, or the tool through the proof tree. And this is what the GUI looks like and when you have a proof it all turns green. And that's what you want. You want to see that. So what Tamarin is really doing from an intuitive perspective is it's starting, it's using backward search. It starts with the action you tell it to track and then it says well where can that action occur? And then from here it rolls backwards even further at each stage considering what the adversary can do and what the adversary knows. And eventually it either gets to a point where it can determine if there's no solution or there is a counter example which is an attack. So maybe it seems simple but in actual fact for us to prove the secret session keys lemma we needed to write a whole bunch of, and prove these lemmas as well, these auxiliary lemmas, right, before we could even start proving that. So the proof of this relies on ES basic which relies on these, which relies on these. And this is only half of the lemma tree. So to get to our proofs we needed to write or improve about 45 auxiliary lemmas. Okay, but we did that for draft 10. And we found that secret session keys was good. So as entity authentication and as mutual variant, transcript agreements and as mutual variant and also for the secrecy of early data keys. So draft 10 looked good. But then we included this post handshake client authentication mechanism. So this means the server can request that the client authenticates at any time after a handshake has happened and it's just, it's kind of indicated by these red loops. And we found this attack, right. These attacks are actually very easy. Oh no, they're not easy to find. They're very subtle to find. But Tamarind can easily find these attacks because it's so good at looking at the interaction of different components of TLS. So the attack, I won't go through it in much detail, but actually exploits the use of three different TLS handshakes. So this is an initial handshake. It will exploit the post handshake client authentication and it will also exploit this resumption handshake, which is a appreciate key handshake. And all of those handshakes in combination lead to this attack where an adversary can actually right at the end here impersonate a client. So if you are an honest client and this is your bank, the adversary can impersonate you, right, and that's bad. And it happens because there isn't a proper binding of certain things in these connections. Full details of this are in the papers and I'll show you links to those later. Okay, we had to update our model to draft 21 because TLS 1.3 was a rapidly moving target. And draft 21 looked like a very new protocol. And we modeled in far more granularity this time. This was good for us but also good for anyone who wanted to look at our model. And Sam actually made a very nice website that compares our model to the TLS 1.3 specification. And these are state machines, they're just far more fine grained and we have more rules this time around. And the properties are specified quite well in draft 21. And again we had a whole host of auxiliary lemmas that we needed to prove before we could even prove the main properties of TLS 1.3. So we found the draft 21 pretty much looks good. This is an edge case, not considered to be that important by the working group. Again you can see details in the paper. But this time we had to model with far more granularity and so we needed far more computation and power. We used a 48 core machine, 512 gigs of RAM. The model takes about 10 gigs to load and can consume up to 100 gigs for one proof. To prove the entire model takes about a week continuously and we needed about three person months to model before we could even start proving. And I think that's actually an underestimate. I think it took us a lot longer. But in the end we showed that 21 pretty much looks good and therefore the logical core of TLS 1.3 actually looks pretty good. And TLS 1.3 is out there. The model says that 10.7% of sites are now supporting it. That's a quick uptake if you think it was released in August. Facebook claimed a few months ago that 50% of its traffic uses TLS 1.3. I can believe that because it can control both ends of the connection. And at Pazilla we see about 10 or 8% of our Firefox connections using TLS 1.3. Okay so there's more stuff happening with Tamarin. We're actually starting to model more extensions in TLS 1.3 and those are looking good. And then just quickly to close our modeling effort has showed that the logical core of TLS 1.3 does look good. We've built a very transparent model that others can use and it's available. People can go and find it on GitHub. There are many complementary ways for analyzing TLS 1.3. We just used one of them. And I think the most standardization process has hopefully helped us build a protocol that is more robust and require less patching in the future. And what I will say is I think we're going to see more of these automated tools being used for protocol analysis. So I think the machines are coming. Thank you. Any questions? Yes. I have one question about the collaboration between academia and the industry. I think it's quite rare to have that kind of collaboration in the history of computing. Like between FORTRAN and COBOL there was no cooperation between the business and the academia. Why do you think was a factor which made it more like which made it a good collaboration in TLS? I think because of the history of TLS and all of these attacks and the fact that we had this kind of patch action for the working group. So working group continually needed to start patching these protocol specifications. So I think that was becoming a problem. Also I think the attacks against TLS started to become far more practical. So I think the working group was like oh we should probably try and prevent these before we actually release the specification. And the analysis tools for TLS and for protocols have developed in the years. So now we can actually analyze these protocols before they are out in the wild. And TLS has star power, right? It's a very big protocol and people wanted to use it and if we get it wrong that's kind of bad. Any other question? No? Okay, thank you so much. So the next talk is about how XR goes behind demos and games by Boris Burini. So we will start in