 all right thank you everybody for your patience thank you for coming to the crypto and privacy village today we have a bunch of great talks today so far and I'd like you all to welcome our next speaker you'll be talking about Rust TLS modern fast safer TLS please give a warm welcome to Joseph Burr-Pickston thanks so much everyone hear me at the back okay um so my name's Joe I come from Cambridge in England this is a project I've been doing for about the last year in my spare time it's not really a work thing so what I'm going to be talking about is a little bit of memory safety evangelism not specifically Rust but you know memory safety and then I'll go through what is currently implemented in Rust TLS or Russell's as however you want to pronounce it and then I'll be kind of justifying some of the things I haven't implemented with respect to well-known TLS vulnerabilities and then there's a bit of performance testing and and future work at the end so Russell's is a TLS 1.2 and TLS 1.3 draft 18 TLS library written in Rust triple licensed so it's quite as open-source as you really would want and yeah it's it's it's a little bit over a year first proper release was kind of a few weeks after DEF CON I did quite a lot of work on it on the plane here and back last year but let's talk about memory safety it's a problem and it's kind of like software engineering industry is kind of in a bit of a rut with it so let's let's let's assume that the the last IOS update is typical of a large complex software project which is kind of modern it's not like from the 80s well some of it is but most of it has been written in the last 10 to 20 years and so these releases get done every month every couple of months and as you can see from this fair so I'm not presenting this as real research it's it's kind of lazy but hopefully you can see well two three-quarters of all the CVs Apple recently fixed are all memory safety issues and what I mean by software engineering industry is stuck in a rut is this is kind of personified by this line here where they're saying we had a memory control corruption issue and we kind of fixed it but there's nothing systematic being changed here they're they're very much in penetrating patch penetrating patch month upon month so this isn't working it hasn't been working for well maybe since the early 90s it wasn't working for them but no one was really really cared so that slight there is a little bit of rust of angelism but I'm trying to tone it down because people basically coming and telling people to rewrite everything in rust is at best counterproductive it's also not actually necessary if you choose which bits you're going to rewrite in in whatever memory safe language you like then it's you know you can choose your attack surface you say oh TLS an important tax surface which it is then we implement that in rust and stick it in front of your random thing like Apache or engine X which is over in in C or C plus or whatever so that there's there's it's not a case of a total case of just choosing a programming language as well it gets more complicated like no JS only recently removed an API which was like the heartbeat limit heartbeat primitive that you'd want and actual real JavaScript projects had CVs as a result of this this terribly insane API they implemented so yeah it needs more attention than just writing everything in rewrite everything in rust or go or JavaScript but you know rewrite everything in rust is a good first step so rust for people who haven't come across it is a programming language which came out of Mozilla it's memory safe and concurrency safe and what I mean by that is when you write stuff a whole class of vulnerabilities are basically impossible to achieve if you were thinking that a vulnerability was something that you wanted to have there is a an unsafe subsets as an unsafe keyword which introduces basically unconstrained memory access calling into C libraries all this kind of thing so that's that's a good trapdoor to do from function interfaces so calling into libraries written in C C plus plus and and the other way it's got a really good type system so in terms of like there's like a trade-off between how good your type system is and how complex complex it is rust is I would say it's more complicated than go it's more complicated than see it's less complicated than C plus plus so I've been writing C plus plus since about 1998 something like that and I still could not claim to know the whole language I've been writing rust for maybe a year and a half and well I feel like I'm closer to that maybe not totally there but you know the other important thing is it's got no run a runtime overhead like go does so go has a garbage collector and a bunch of other runtime overhead for doing lightweight concurrency rust doesn't have any of that so that makes rust quite good for embedded programming where you don't really have any of the stuff that you'd need to have well you don't have any resources to run a concurrent garbage garbage collector or anything and it's quite quick as well it can be quicker than see in some certain circumstances mainly due to aliasing so there's this thing in C called aliasing where basically if you've got a function with two arguments of the same type then they can in fact overlap and rights to one can invalidate the other that can't happen in safe rust and so there's a whole slew of other optimizations that the compiler can take advantage of so Russell's a puff apart from all the memory safety stuff I've also been trying to learn from some of the slightly poor API designs that have been kind of a common feature of other TLS libraries and so the the inspiration here is this paper from well five years ago now from Dan Bernay the last paragraph is the most is the one that you should read if you're just going to read any of it but that's what I've been trying to go for so my my kind of use case here is you have a program you want to call an API say GitHub or AWS or something like that but you don't you're not you're not interested in TLS you're more interested in talking to GitHub talking to AWS or something like that and because TLS H2S is such a given these days there's a lot of such users who just don't want to it really shouldn't be tasked with working out what host name verification actually means and certificate verification all this all this stuff that is necessary but redundant if a hundred people do it all different ways also the security outcomes of making everyone do it poor so this is what is currently implemented I've gone for a quite conservative set of features I should say TLS 1.3 it's still not standardized but there it's been progressing in drafts draft 18 is the most common current one so if you see TLS 1.3 on the public internet at the minute it will be draft 18 draft 19 20 and now 21 are all kind of minor tweaks that they're incompatible but they're minus weeks and so it doesn't actually make sense to break compatibility with the rest of the internet at the minute while people are doing you know testing the other thing is Russell's always does forward forward secrecy so there's no implementation of RSA Keans up encapsulation Cypher suites which are well very kind of crap and the other well there's a slide later but I'm TLS 1.3 has also abolished this so it's kind of similar and the other thing is several authentication is basically non-negotiable so you don't you both don't need to do anything and also it's kind of hard to turn off the other thing which is very very recent is OCSP and SCT pinning SCT is related to certificate transparency so this is basically a proof that the certificate you've just been given by a server has been included on a certificate transparency log and I think sometimes later this year Chrome will be requiring that all servers provide at least two valid SCTs along with certificate to prove that certificate transparency is in play so this is what the dependencies look like so there's Russell's down at the bottom there for users of so first of all setback Russ has a package manager called cargo all these orange boxes are crates so they're individually versioned separate modules all stored in their own version history and everything so the bottom here CT logs is a list of all the valid CT logs from Google where PKI roots is all Mozilla's root CA is minus a bunch which have been bad SCT dot RS is a very recent SCT validation library which I wrote where PKI is a certain validation thing written by Brian Smith and then at the top which is the kind of apex of all these there's ring which is also written by Brian Smith and that's got a lineage from boring SSL so some of the crypto comes from boring SSL pretty much unchanged some of it has been re-implemented in rust in in the ring project by Brian Smith and others but yeah I trust Brian Smith if anyone doesn't know Brian Smith well I guess his claim to fame was he single-handedly rewrote the whole of certificate validation for Mozilla in C++ and where PKI is kind of like not a direct transcription but it's comes from the same place so there's that and now I'm going to go through some old TLS problem so this is going to go quite quickly because it's you'll you'll you'll notice a pattern as we go through so that I'm splitting this into protocol versus implementation problems but this is the approach basically don't implement things which are broken so particularly I mean I think these are fairly well no one's going to argue with me maybe on discrete log Diffie-Hellman but in fact discrete log Diffie-Hellman you can't negotiate it properly in TLS 1.2 which means it's basically impossible to to deploy and have people talk to you and acceptable security level without having interrupt failures okay is that better okay sorry okay so the next is a well there's more of this GCM nonces well that that was I think disclosed last year here in a black hat by Hanna Wock and Co I think I've put this as part of as a protocol problem rather than an implementation problem what they reported was implementations which got this wrong but I think it's a protocol problem because the protocol allowed them to make such a poor decision and so this counter from a random start point has a security proof it's exactly what is required in TLS 1.3 and then all the rest are again not very controversial and then triple handshake and renegotiation well there's not a single renegotiation vulnerability there's a whole stack and the answer is don't do renegotiation it doesn't end well well hasn't ended well about three times now and so this is what I was talking about earlier which was comparing the subset of TLS 1.2 that I've implemented versus the design of TLS 1.3 and you see there's a quite nice overlap there and yeah and then implementation problems I'm sure everyone knows about these the middle two are very similar they're basically like in implementations do things wrong if you miss out messages or you send messages in the wrong order and yeah so for heartbleed particularly because it's all it's all anyone ever talks about in terms of TLS implementation vulnerabilities memory safety gets you most of the way not implementing random kind of pointless extensions like the heartbeat extension which was solely really used for DTLS implementing that as well for TLS it's a bit weird and also always doing perfect perfect forward secrecy because no leak of private key should compromise past traffic it's just a terrible idea so I thought I'd talk about market types this is something I did on the plane here so it's kind of new but I'm not sure whether it's an actual new idea I haven't seen it in other TLS or crypto libraries so the whole problem with go to fail was there was a function it did some six signature verification but due to an accident half of the significant verification got missed off and so there was a jump from halfway through the function to the end and at the end there was just like a return with a there's no error return code but actually saying there's no error is not a it's not it's not a positive affirmation that yes I have verified the signature you asked me to is more like it was it was fine or maybe you know so you can delete the whole the whole function body and still end up with something that seems to work obviously is terribly vulnerable so the idea here is instead of having the absence of error you have a specific type which has no size at all so it's totally free it's just a figment of the compiler's imagination and then you reduce the problem to just checking that there's only one route to making these types and that route goes through all the steps that you want to do in the signature validation so there's no there's no concept of missing out steps and so this is some code from Russell so the top is us verifying that a TLS finished message so this is just like a check that both sides in the protocol saw the same handshake and if that's true if that matches then we produce one of these values and at the bottom we've got the protocol state which you really want to end up in because this is the state where you can send application data back and forth that means so these types of the bottom mean by construction it's the compiler will prevent you from getting to that state unless you've been through all these checks and produce the right types and then pass them through so there's no there's no possibility of skipping a state which produced which say validated the service up because the thing just won't compile so yeah there's some stuff about testing the one thing about testing I would say is this Bogo which is the boring cell test week that's been super useful that they basically took the Golang TLS library and then made it really really really evil configurably evil so it could do a whole suite of subtly different but broken handshakes and that's pretty cool it found some good bugs most of these bugs were like I didn't send an alert in a particular place when I was meant to I sent the wrong alert that kind of thing there's some places where I sent the wrong alert I sent a different alert to boring SSL but in fact the library just the TLS 1.2 spec says send an alert and not what kind of alert to send so I kind of aligned with boring SSL at that point because just well less too short the other thing is performance so the important number down here this is just on my random machine at home open SSL can do raw AS 128 GCM at 37 gigabits per second on that machine the library started out quite slowly it was very copy heavy so it would copy the data you wanted to send a whole bunch while encrypting it fragmenting it and so on those copies got removed as time went on and I think 22 gigabits per second per core is reasonably good what I haven't done is measure open SSL in a similar phase because the difference between 37 and 22 is basically going to be all the protocol framing and passing so I expect open SSL to be somewhere between those numbers but yeah I think 22 gigs per second per core is pretty reasonable at this point the other thing was so TLS 1.3 as it got mentioned yesterday has this new and exciting feature coming to a DEF CON near you called zero RTT in the protocol it's called early data which is a much better name frankly this is when you're resuming a connection you can start sending data with the resumption on the assumption that the the resumption will work the problem with that is that first message you send that resumption and the data is replayable and there are some limitations that replay time-based and there's a new thing added to the RFC saying well you should probably prevent people from doing this kind of replay but not yeah it seems like a very very tricky thing to actually get right the other thing applications have to know this is happening because they can in some circumstances servers at least can receive like duplicate requests under attacker control basically so that's not great the on the other hand it's basically in a state where it can't really be deployed because the RFC says you have to have a profile saying so there might be a profile for HTTPS which says well you know get requests without any cookies can be sent like this or something like that there isn't such any there aren't any profiles like that at all at the minute so I'm aware that some people have deployed it but it's largely in a testing capacity rather than actual production system because that would be crazy the other thing is finish off OCSP verification that's on the client side checking that a staple OCSP response is valid and that your certificate that you've just got hasn't been revoked and there's PSK sport that's kind of been bubbling over for a long time but in TLS 1.3 PSK and resumption are basically the same mechanism so with resumption working PSK is a mere matter of making the API exposed to the the rest of the world and implementing it in TLS 1.2 and then the other thing I'd like to do is stop this library from being kind of rust centric so it would be really nice if this could be compiled into like an Apache module and to terminate TLS or an engine X module or whatever and the Libre SL people came up with a nice C library at C interface I should say which it looks quite nice it doesn't make me retch so that might be a good good choice and hopefully by the time I get around to doing that there'll be integrations with things like Apache and engine X and then a third party audit would be it would be nice once everything you know once TLS 1.3 has been finalized and once I'm fairly sure I'm not going to add you know more features so that's that I did have some extra slides but they're kind of screwed up so any questions mentioned a lot of the vulnerability of another TLS libraries and how you you know avoided that you know you mentioned that there were some bugs that were not prevented by those vendors so what were the kind of classes of bugs that did get written in Russell's and how can we improve our compiler and type system tooling to prevent those kinds of bugs as well okay so I'll just repeat the question the question was roughly what kind of bugs did I find in Russell's having written it and how could they be prevented so as I said most of the bugs I found were spec non-compliance not in a a security so they weren't necessarily vulnerabilities but they could cause interrupt problems so I'm I feel reasonably confident about the security of Russell's what I'm not totally confident about is that it would be as interrupt as well as say open SSL or NSS or boring SSL so those kinds of bugs those interrupt kind of bugs which I'm more worried about Bogo found some of those but I'm sure there are some still there I think really most of those get get squeezed out either through use or some kind of formal analysis there is a project called Mount Everest project Everest I think being done by a bunch of people including Microsoft research and that is going to produce a full end-to-end formally verified TLS 1.3 stack so hopefully I can use some of the results of that to either generate test cases or generate some of the code that I've written from from their formally verified protocol implementation and I think that would be pretty cool. Any other questions? I'm looking at you because you asked me a question.