1 00:00:00,000 --> 00:00:04,760 Thank you everybody for your patience. Thank you for coming to the Crypto and Privacy Village 2 00:00:04,760 --> 00:00:09,600 today. We have a bunch of great talks today so far and I'd like you all to welcome our next 3 00:00:09,600 --> 00:00:15,580 speaker. He'll be talking about Rust TLS, modern, fast, safer TLS. Please give a warm welcome to 4 00:00:15,580 --> 00:00:16,480 Joseph Burr-Pixton. 5 00:00:23,100 --> 00:00:29,980 Thanks very much. Does everyone hear me at the back? Okay. So my name is Joe. I'm a 6 00:00:30,000 --> 00:00:37,120 I come from Cambridge in England. This is a project I've been doing for about the last 7 00:00:37,120 --> 00:00:44,160 year in my spare time. It's not really a work thing. So what I'm going to be talking 8 00:00:44,160 --> 00:00:54,400 about is a little bit of memory safety evangelism, not specifically Rust, but, you know, memory 9 00:00:54,400 --> 00:00:59,980 safety. And then I'll go through what is currently implemented in Rust. 10 00:01:00,000 --> 00:01:11,400 Rust TLS or Rustles is however you want to pronounce it. And then I'll be kind of justifying 11 00:01:11,400 --> 00:01:19,840 some of the things I haven't implemented with respect to well-known TLS vulnerabilities. And 12 00:01:19,840 --> 00:01:29,440 then there's a bit of performance testing and future work at the end. So Rustles is a TLS 1.2 13 00:01:30,000 --> 00:01:41,480 TLS 1.3 Draft 18 TLS library written in Rust. Triple licensed. So it's quite as open source as 14 00:01:41,480 --> 00:01:49,860 you really would want. And, yeah, it's a little bit over a year. First proper release was kind of 15 00:01:49,860 --> 00:01:59,860 a few weeks after DEF CON. I did quite a lot of work on it on the plane here and back. Last 16 00:01:59,860 --> 00:02:08,900 year. But let's talk about memory safety. It's a problem and it's kind of like software 17 00:02:08,900 --> 00:02:19,640 engineering industry is kind of in a bit of a rut with it. So let's assume that the last IOS 18 00:02:19,640 --> 00:02:29,840 update is typical of a large complex software project which is kind of more of a 19 00:02:29,860 --> 00:02:35,720 modern. It's not like from the 80s. Well, some of it is. But most of it has been written in the 20 00:02:35,720 --> 00:02:48,420 last 10 to 20 years. And so these releases get done every month, every couple of months. And as 21 00:02:48,420 --> 00:02:57,120 you can see from this fair. So I'm not presenting this as real research. It's kind of lazy. But 22 00:02:57,120 --> 00:02:59,840 hopefully you can see, well, two, three, four, five, six, seven, 10, 11, 12, 13, 14, 15, 16, 23 00:02:59,860 --> 00:03:07,280 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 30, 27, 30, 31, 32, 33, 34, 35, 36, 37, 38, 24 00:03:07,280 --> 00:03:07,340 38, 39, 40, 40, 41, 42, 42, 43, 44, 45, 45, 46, 47, 41, 42, 43, 44, 45, 46, 47, 48, 49, 49, 50, 51, 25 00:03:07,340 --> 00:03:11,560 52, 57, 56, 57, 57, 58, 58, 59, 59, 60. And what I mean by software engineering industry is 26 00:03:11,560 --> 00:03:19,520 stuck in a rut is this is kind of personified by this line here where they're saying we had a memory 27 00:03:19,520 --> 00:03:27,720 corruption issue and we kind of fixed it but there's nothing systematic being changed here 28 00:03:27,720 --> 00:03:36,740 they're very much in penetrate and patch penetrate and patch month upon month um so yeah this isn't 29 00:03:36,740 --> 00:03:44,280 working um it hasn't been working for well maybe since the early 90s it wasn't working before then 30 00:03:44,280 --> 00:03:56,740 but no one was really really cared um so um that slight um there is a little bit of rust evangelism 31 00:03:56,740 --> 00:04:01,300 but i'm trying to tone it down because people basically coming and telling people to rewrite 32 00:04:01,300 --> 00:04:10,340 everything in rust is at best counterproductive um it's also not actually necessary um if you 33 00:04:10,340 --> 00:04:14,260 choose which bits you're going to rewrite in in whatever memory safe language you're going to 34 00:04:14,260 --> 00:04:21,780 write in whatever language you like um then it's you you know you can choose your attack surface 35 00:04:21,780 --> 00:04:28,400 you you say oh tls is an important attack surface which it is um then re-implement that in rust and 36 00:04:28,400 --> 00:04:36,680 stick it in front of your random thing like apache or nginx which is all written in c or c++ or 37 00:04:36,680 --> 00:04:44,240 whatever um uh so there's there's it's not a case of it's not a case of it's not a case of 38 00:04:44,260 --> 00:04:49,280 a total case of just choosing a programming language as well um it gets more complicated 39 00:04:49,280 --> 00:05:02,520 like node.js only recently um removed an api which was like the heartbeat heartbleed primitive 40 00:05:02,520 --> 00:05:13,940 that you'd want um and actual real javascript um uh projects had cvs as a result of this this 41 00:05:14,260 --> 00:05:19,940 terribly insane api they implemented so yeah it needs more attention than just write everything 42 00:05:19,940 --> 00:05:27,340 in rewrite everything in rust or go or javascript but um you know rewrite everything in rust is a 43 00:05:27,340 --> 00:05:36,560 good first step um so rust for people who haven't come across it is a um programming language which 44 00:05:36,560 --> 00:05:43,420 came out of mozilla um it's memory safe and concurrency safe and what i mean by that is when 45 00:05:44,260 --> 00:05:53,440 you have um a whole class of vulnerabilities are basically impossible um uh uh to achieve if you 46 00:05:53,440 --> 00:06:01,140 were thinking that a vulnerability was something that you wanted to have um there is a an unsafe 47 00:06:01,140 --> 00:06:08,360 subset so there's an unsafe um keyword which introduces basically unconstrained memory access 48 00:06:08,360 --> 00:06:14,200 um calling into c libraries all this kind of thing so that's that's a good um 49 00:06:14,260 --> 00:06:24,280 trapdoor to um do function interfaces so calling into libraries written in c c++ and and the other 50 00:06:24,280 --> 00:06:30,080 way it's got a really good type system so in terms of like there's like a trade-off between 51 00:06:30,080 --> 00:06:35,760 how good your type system is and how complex it is rust is i would say 52 00:06:37,880 --> 00:06:42,860 um it's more complicated than go it's more complicated than c 53 00:06:43,520 --> 00:06:44,240 it's less complicated than go it's less complicated than c it's less complicated than go it's less 54 00:06:44,260 --> 00:06:53,540 complicated than c plus plus um so i've been writing c plus plus since about 1998 something like that 55 00:06:54,340 --> 00:07:03,840 and i still could not claim to know the whole language i've been writing rust for maybe a year 56 00:07:03,840 --> 00:07:12,180 and a half and well i feel like i'm closer to that maybe not totally there but you know um the 57 00:07:12,180 --> 00:07:14,240 other important thing is um it's got no rust it's got no code it's got no code it's got no code it's 58 00:07:14,260 --> 00:07:27,260 got no workspaces it's got no shortcuts it's got textures orě 데j 59 00:07:34,320 --> 00:07:43,960 and it's quite quick as well 60 00:07:44,260 --> 00:07:48,660 It can be quicker than C in some certain circumstances, 61 00:07:49,070 --> 00:07:52,480 mainly due to aliasing. 62 00:07:52,720 --> 00:07:54,940 So there's this thing in C called aliasing 63 00:07:54,940 --> 00:07:58,180 where basically if you've got a function 64 00:07:58,180 --> 00:08:00,020 with two arguments of the same type, 65 00:08:00,140 --> 00:08:01,420 then they can, in fact, overlap, 66 00:08:02,060 --> 00:08:04,740 and writes to one can invalidate the other. 67 00:08:06,080 --> 00:08:08,020 That can't happen in safe Rust, 68 00:08:08,340 --> 00:08:11,660 and so there's a whole slew of other optimizations 69 00:08:11,660 --> 00:08:15,620 that the compiler can take advantage of. 70 00:08:19,100 --> 00:08:24,720 So, apart from all the memory safety stuff, 71 00:08:25,460 --> 00:08:31,020 I've also been trying to learn 72 00:08:31,020 --> 00:08:38,920 from some of the slightly poor API designs 73 00:08:39,460 --> 00:08:40,680 that have been... 74 00:08:42,160 --> 00:08:45,300 kind of a common feature of other TLS libraries. 75 00:08:48,100 --> 00:08:52,880 And so the inspiration here 76 00:08:52,880 --> 00:08:58,060 is this paper from, well, five years ago now, 77 00:08:58,700 --> 00:08:59,560 from Dan Bernay. 78 00:09:01,460 --> 00:09:04,320 The last paragraph is the one that you should read 79 00:09:04,320 --> 00:09:05,580 if you're just going to read any of it, 80 00:09:05,660 --> 00:09:08,400 but that's what I've been trying to go for. 81 00:09:08,640 --> 00:09:10,540 So my... 82 00:09:10,540 --> 00:09:12,900 my kind of use case here is 83 00:09:14,300 --> 00:09:15,380 you have a program, 84 00:09:15,540 --> 00:09:16,400 you want to call an API, 85 00:09:16,640 --> 00:09:19,000 say GitHub or AWS or something like that, 86 00:09:20,800 --> 00:09:21,820 but you don't... 87 00:09:21,820 --> 00:09:24,580 you're not interested in TLS. 88 00:09:24,920 --> 00:09:27,740 You're more interested in talking to GitHub, 89 00:09:27,880 --> 00:09:29,240 talking to AWS, something like that. 90 00:09:30,840 --> 00:09:33,600 And because TLS, H3S, 91 00:09:33,820 --> 00:09:36,020 is such a given these days, 92 00:09:36,260 --> 00:09:39,320 there's a lot of such users 93 00:09:39,320 --> 00:09:40,520 who just don't know how to use it. 94 00:09:40,520 --> 00:09:41,480 They don't want to... 95 00:09:41,480 --> 00:09:43,760 It really shouldn't be tasked with 96 00:09:43,760 --> 00:09:46,620 working out what host name verification actually means 97 00:09:46,620 --> 00:09:48,920 and certificate verification, 98 00:09:49,080 --> 00:09:53,480 all this stuff that is necessary 99 00:09:53,480 --> 00:09:57,160 but redundant if 100 people do it all different ways. 100 00:09:58,720 --> 00:10:01,620 Also, the security outcomes of making everyone do it 101 00:10:01,620 --> 00:10:03,480 are poor. 102 00:10:06,540 --> 00:10:09,560 So this is what is currently implemented. 103 00:10:10,520 --> 00:10:14,420 I've gone for a quite conservative set of features. 104 00:10:16,600 --> 00:10:20,060 I should say TLS 1.3 is still not standardized, 105 00:10:20,820 --> 00:10:25,580 but it's been progressing in drafts. 106 00:10:25,880 --> 00:10:31,000 Draft 18 is the most common current one. 107 00:10:31,240 --> 00:10:35,840 So if you see TLS 1.3 on the public internet at the minute, 108 00:10:35,880 --> 00:10:37,140 it will be draft 18. 109 00:10:38,100 --> 00:10:40,480 Draft 19, 20, and now 20. 110 00:10:40,520 --> 00:10:43,660 Draft 21 are all kind of minor tweaks. 111 00:10:43,920 --> 00:10:46,440 They're incompatible, but they're minor tweaks, 112 00:10:46,680 --> 00:10:48,300 and so it doesn't actually make sense 113 00:10:48,300 --> 00:10:50,880 to break compatibility with the rest of the internet 114 00:10:50,880 --> 00:10:53,860 at the minute while people are doing testing. 115 00:10:57,840 --> 00:10:59,320 The other thing is 116 00:11:00,180 --> 00:11:03,140 Rustle always does forward secrecy. 117 00:11:03,460 --> 00:11:09,420 So there's no implementation of RSA key 118 00:11:09,420 --> 00:11:10,500 and cap secrecy. 119 00:11:10,520 --> 00:11:11,780 So there's no implementation of Cipher Suites, 120 00:11:11,840 --> 00:11:15,600 which are, well, very kind of crap. 121 00:11:17,000 --> 00:11:18,860 The other thing, well, there's a slide later, 122 00:11:19,040 --> 00:11:22,300 but TLS 1.3 has also abolished this, 123 00:11:22,420 --> 00:11:23,260 so it's kind of similar. 124 00:11:25,520 --> 00:11:26,700 And the other thing is 125 00:11:27,660 --> 00:11:29,800 server authentication is basically non-negotiable. 126 00:11:29,900 --> 00:11:33,300 So you both don't need to do anything, 127 00:11:33,700 --> 00:11:35,860 and also it's kind of hard to turn off. 128 00:11:39,340 --> 00:11:40,500 The other thing is, 129 00:11:40,520 --> 00:11:42,920 the other thing which is very, very recent 130 00:11:42,920 --> 00:11:47,820 is OCSP and SET pinning. 131 00:11:48,260 --> 00:11:54,860 SET is related to certificate transparency. 132 00:11:55,120 --> 00:11:57,020 So this is basically a proof 133 00:11:57,020 --> 00:12:00,040 that the certificate you've just been given by a server 134 00:12:00,040 --> 00:12:03,780 has been included on a certificate transparency log. 135 00:12:04,140 --> 00:12:06,480 And I think sometime later this year, 136 00:12:06,580 --> 00:12:08,660 Chrome will be requiring that... 137 00:12:10,520 --> 00:12:14,620 all servers provide at least two valid SCTs 138 00:12:15,240 --> 00:12:17,460 along with the certificate to prove that 139 00:12:18,620 --> 00:12:20,760 certificate transparency is in play. 140 00:12:22,320 --> 00:12:22,920 Yeah. 141 00:12:23,660 --> 00:12:25,720 So this is what the dependencies look like. 142 00:12:26,340 --> 00:12:28,460 So there's Russell's down at the bottom there. 143 00:12:30,980 --> 00:12:33,620 For users of... 144 00:12:33,620 --> 00:12:35,420 So first of all, setback. 145 00:12:37,100 --> 00:12:40,280 Russ has a package manager called Cargo. 146 00:12:41,120 --> 00:12:44,640 All these orange boxes are crates, 147 00:12:44,680 --> 00:12:50,900 so they're individually versioned separate modules, 148 00:12:51,620 --> 00:12:53,840 all stored in their own version history and everything. 149 00:12:55,480 --> 00:12:56,640 So at the bottom here, 150 00:12:56,800 --> 00:13:01,700 CT logs is a list of all the valid CT logs from Google. 151 00:13:01,920 --> 00:13:03,980 WebPKI routes is all Mozilla's. 152 00:13:04,020 --> 00:13:05,640 Route CA is minus a bunch, 153 00:13:06,340 --> 00:13:09,000 which have been bad. 154 00:13:12,020 --> 00:13:15,120 And SCT.RS is a very recent 155 00:13:17,380 --> 00:13:19,460 SCT validation library, 156 00:13:20,180 --> 00:13:21,160 which I wrote. 157 00:13:21,500 --> 00:13:25,200 WebPKI is a cert validation thing 158 00:13:25,200 --> 00:13:27,420 written by Brian Smith. 159 00:13:29,400 --> 00:13:30,840 And then at the top, 160 00:13:30,860 --> 00:13:33,940 which is the kind of apex of all these, 161 00:13:34,000 --> 00:13:34,680 there's Ring, 162 00:13:34,800 --> 00:13:36,380 which is also written by Brian Smith. 163 00:13:36,780 --> 00:13:40,500 And that's got a lineage from Boring SSL, 164 00:13:40,520 --> 00:13:44,260 so some of the crypto comes from Boring SSL, 165 00:13:44,400 --> 00:13:45,860 pretty much unchanged. 166 00:13:46,040 --> 00:13:49,340 Some of it has been re-implemented in Rust, 167 00:13:49,960 --> 00:13:53,220 in the Ring project by Brian Smith and others. 168 00:13:55,400 --> 00:13:57,120 But yeah, I trust Brian Smith. 169 00:13:57,480 --> 00:13:59,440 If anyone doesn't know Brian Smith, 170 00:14:01,220 --> 00:14:02,800 well, I guess his claim to fame was 171 00:14:02,800 --> 00:14:05,780 he single-handedly rewrote 172 00:14:05,780 --> 00:14:09,480 the whole of certificate validation for Mozilla 173 00:14:09,480 --> 00:14:10,380 and then he wrote a certificate validation for Mozilla 174 00:14:10,380 --> 00:14:13,260 in C++ and WebPKI is kind of like 175 00:14:13,260 --> 00:14:15,420 not a direct transcription, 176 00:14:15,720 --> 00:14:18,340 but it comes from the same place. 177 00:14:20,680 --> 00:14:21,640 So there's that. 178 00:14:22,660 --> 00:14:26,060 And now I'm going to go through some old TLS problems. 179 00:14:26,200 --> 00:14:27,300 So this is going to go quite quickly 180 00:14:27,300 --> 00:14:33,720 because you'll notice a pattern as we go through. 181 00:14:36,120 --> 00:14:39,460 I'm splitting this into protocol versus implementation. 182 00:14:41,100 --> 00:14:42,300 I'm splitting this into protocol versus implementation. 183 00:14:42,300 --> 00:14:43,360 But this is the approach. 184 00:14:43,600 --> 00:14:46,820 Basically, don't implement things which are broken. 185 00:14:50,060 --> 00:14:53,440 So particularly, I mean, I think these are fairly, 186 00:14:55,720 --> 00:14:57,440 well, no one's going to argue with me, 187 00:14:57,480 --> 00:15:00,060 maybe on discrete log Diffie-Hellman, 188 00:15:00,180 --> 00:15:02,080 but in fact, discrete log Diffie-Hellman, 189 00:15:02,120 --> 00:15:05,180 you can't negotiate it properly in TLS 1.2, 190 00:15:06,240 --> 00:15:08,620 which means it's basically impossible 191 00:15:08,620 --> 00:15:09,840 to do that. 192 00:15:10,380 --> 00:15:13,900 To deploy and have people talk to you 193 00:15:13,900 --> 00:15:15,220 at an acceptable security level 194 00:15:15,220 --> 00:15:17,380 without having interop failures. 195 00:15:22,340 --> 00:15:23,060 Okay. 196 00:15:23,220 --> 00:15:24,160 Is that better? 197 00:15:25,200 --> 00:15:25,920 Okay. 198 00:15:26,960 --> 00:15:27,680 Sorry? 199 00:15:29,020 --> 00:15:29,740 Okay. 200 00:15:33,160 --> 00:15:36,180 So the next is a, 201 00:15:36,340 --> 00:15:37,440 well, there's more of this. 202 00:15:38,840 --> 00:15:39,980 GCM nonces. 203 00:15:40,380 --> 00:15:42,560 Well, that was, I think, 204 00:15:44,240 --> 00:15:47,100 disclosed last year here and at Black Hat 205 00:15:48,180 --> 00:15:51,740 by Hannah Bock and co., I think. 206 00:15:52,540 --> 00:15:54,060 I've put this as part of, 207 00:15:54,800 --> 00:15:56,140 as a protocol problem 208 00:15:56,140 --> 00:15:57,760 rather than an implementation problem. 209 00:15:57,900 --> 00:15:59,680 What they reported was implementations 210 00:15:59,680 --> 00:16:00,480 which got this wrong, 211 00:16:00,600 --> 00:16:01,860 but I think it's a protocol problem 212 00:16:01,860 --> 00:16:05,240 because the protocol allowed them 213 00:16:07,320 --> 00:16:09,440 to make such a poor decision. 214 00:16:11,860 --> 00:16:14,920 And so this counter from a random start point 215 00:16:14,920 --> 00:16:16,840 has a security proof. 216 00:16:17,080 --> 00:16:22,460 It's exactly what is required in TLS 1.3. 217 00:16:24,760 --> 00:16:26,700 And then all the rest are, again, 218 00:16:26,740 --> 00:16:28,520 not very controversial. 219 00:16:30,240 --> 00:16:32,700 And then triple handshake and renegotiation. 220 00:16:32,940 --> 00:16:36,020 Well, there's not a single renegotiation vulnerability. 221 00:16:36,320 --> 00:16:37,540 There's a whole stack. 222 00:16:37,920 --> 00:16:39,400 And the answer is, 223 00:16:39,400 --> 00:16:41,220 don't do renegotiation. 224 00:16:41,400 --> 00:16:43,180 It doesn't end well. 225 00:16:43,520 --> 00:16:46,200 Well, it hasn't ended well about three times now. 226 00:16:49,240 --> 00:16:51,260 And so this is what I was talking about earlier, 227 00:16:51,400 --> 00:16:57,680 which was comparing the subset of TLS 1.2 228 00:16:57,680 --> 00:16:58,840 that I've implemented 229 00:16:58,840 --> 00:17:04,420 versus the design of TLS 1.3. 230 00:17:05,400 --> 00:17:09,380 And you see there's a quite nice overlap there. 231 00:17:12,360 --> 00:17:17,320 And then implementation problems. 232 00:17:19,760 --> 00:17:21,680 I'm sure everyone knows about these. 233 00:17:21,740 --> 00:17:23,580 The middle two are very similar. 234 00:17:23,740 --> 00:17:26,860 They're basically like implementations. 235 00:17:27,620 --> 00:17:30,640 Do things wrong if you miss out messages 236 00:17:30,640 --> 00:17:32,460 or you send messages in the wrong order. 237 00:17:35,840 --> 00:17:38,200 And yeah, so for Hartley particularly, 238 00:17:38,380 --> 00:17:39,080 because it's all... 239 00:17:39,080 --> 00:17:40,680 It's all anyone ever talks about 240 00:17:40,680 --> 00:17:42,700 in terms of TLS implementation vulnerabilities, 241 00:17:43,480 --> 00:17:45,180 memory safety gets you most of the way. 242 00:17:46,080 --> 00:17:50,740 Not implementing random kind of pointless extensions 243 00:17:52,840 --> 00:17:54,860 like the heartbeat extension, 244 00:17:55,120 --> 00:17:58,520 which was solely really used for DTLS. 245 00:18:01,200 --> 00:18:03,440 Implementing that as well for TLS. 246 00:18:04,360 --> 00:18:05,740 It's a bit weird. 247 00:18:05,840 --> 00:18:09,060 And also always doing performance... 248 00:18:09,080 --> 00:18:10,480 It's a bit weird for perfect forward secrecy 249 00:18:10,480 --> 00:18:12,600 because no leak of a private key 250 00:18:12,600 --> 00:18:14,560 should compromise past traffic. 251 00:18:14,700 --> 00:18:16,020 It's just a terrible idea. 252 00:18:18,340 --> 00:18:20,740 So I thought I'd talk about marker types. 253 00:18:21,020 --> 00:18:23,140 This is something I did on the plane here. 254 00:18:24,060 --> 00:18:25,620 So it's kind of new, 255 00:18:25,660 --> 00:18:27,780 but I'm not sure whether it's an actual new idea. 256 00:18:27,920 --> 00:18:31,180 I haven't seen it in other TLS or crypto libraries. 257 00:18:33,580 --> 00:18:36,640 So the whole problem with go to fail 258 00:18:36,640 --> 00:18:37,560 was... 259 00:18:38,520 --> 00:18:39,060 I don't know if you've seen it, but I don't know if you've seen it. 260 00:18:39,680 --> 00:18:40,680 But there was a function. 261 00:18:41,000 --> 00:18:44,200 It did some signature verification, 262 00:18:45,040 --> 00:18:46,620 but due to an accident, 263 00:18:47,260 --> 00:18:50,440 half of the signature verification got missed off. 264 00:18:53,260 --> 00:18:54,880 And so there was a jump 265 00:18:54,880 --> 00:18:56,800 from halfway through the function to the end, 266 00:18:56,840 --> 00:18:57,740 and at the end, 267 00:18:58,340 --> 00:19:01,020 there was just like a return with a 268 00:19:01,020 --> 00:19:03,380 there's no error return code. 269 00:19:03,720 --> 00:19:05,740 But actually, saying there's no error 270 00:19:05,740 --> 00:19:09,040 is not a positive... 271 00:19:11,020 --> 00:19:12,260 affirmation that, yes, 272 00:19:12,320 --> 00:19:14,720 I have verified the signature you asked me to. 273 00:19:14,820 --> 00:19:15,620 It's more like 274 00:19:16,460 --> 00:19:18,660 it was fine. 275 00:19:19,120 --> 00:19:20,600 Or maybe, you know... 276 00:19:21,240 --> 00:19:23,120 So you can delete the whole 277 00:19:25,340 --> 00:19:26,460 function body 278 00:19:26,460 --> 00:19:30,440 and still end up with something that seems to work, 279 00:19:30,560 --> 00:19:33,400 but obviously is terribly vulnerable. 280 00:19:34,500 --> 00:19:35,640 So the idea here 281 00:19:35,640 --> 00:19:38,540 is instead of having the absence of error, 282 00:19:39,060 --> 00:19:42,320 you have a specific type 283 00:19:42,720 --> 00:19:44,460 which has no size at all, 284 00:19:44,540 --> 00:19:45,520 so it's totally free. 285 00:19:45,640 --> 00:19:47,560 It's just a figment of the compiler's imagination. 286 00:19:52,000 --> 00:19:54,540 And then you reduce the problem 287 00:19:54,540 --> 00:19:57,200 to just checking 288 00:19:57,200 --> 00:19:59,980 that there's only one route 289 00:19:59,980 --> 00:20:01,440 to making these types, 290 00:20:01,640 --> 00:20:03,100 and that that route 291 00:20:03,100 --> 00:20:06,100 goes through all the steps 292 00:20:06,100 --> 00:20:07,760 that you want to do in the signature validation. 293 00:20:08,240 --> 00:20:09,040 So there's... 294 00:20:09,040 --> 00:20:11,480 There's no concept of missing out steps. 295 00:20:14,380 --> 00:20:16,480 And so this is 296 00:20:17,380 --> 00:20:19,220 some code from Russell. 297 00:20:19,320 --> 00:20:21,320 So the top is 298 00:20:21,320 --> 00:20:24,500 us verifying 299 00:20:24,500 --> 00:20:27,720 a TLS finished message. 300 00:20:27,980 --> 00:20:29,140 So this is just like 301 00:20:29,140 --> 00:20:33,420 a check that both sides in the protocol 302 00:20:33,420 --> 00:20:34,940 saw the same handshake. 303 00:20:36,400 --> 00:20:38,920 And if that's true, 304 00:20:39,040 --> 00:20:40,860 if that matches, 305 00:20:40,940 --> 00:20:42,940 then we produce one of these values. 306 00:20:43,620 --> 00:20:44,780 And then at the bottom, 307 00:20:44,800 --> 00:20:47,180 we've got the protocol state 308 00:20:47,180 --> 00:20:50,020 which you really want to end up in 309 00:20:50,020 --> 00:20:51,280 because this is the state 310 00:20:51,280 --> 00:20:52,780 where you can send application data 311 00:20:53,380 --> 00:20:54,560 back and forth. 312 00:20:56,280 --> 00:20:57,480 That means... 313 00:20:57,480 --> 00:20:59,260 So these types at the bottom 314 00:20:59,260 --> 00:21:00,560 mean by construction, 315 00:21:01,700 --> 00:21:03,860 the compiler will prevent you 316 00:21:03,860 --> 00:21:04,980 from getting to that state 317 00:21:04,980 --> 00:21:06,560 unless you've been through 318 00:21:06,560 --> 00:21:07,520 all these... 319 00:21:07,920 --> 00:21:08,340 all these... 320 00:21:09,300 --> 00:21:10,020 checks 321 00:21:10,020 --> 00:21:12,140 and produce the right types 322 00:21:12,140 --> 00:21:13,480 and then pass them through. 323 00:21:13,760 --> 00:21:14,580 So there's no... 324 00:21:14,580 --> 00:21:15,620 There's no possibility 325 00:21:15,620 --> 00:21:18,300 of skipping a state 326 00:21:18,300 --> 00:21:19,620 which produced... 327 00:21:19,620 --> 00:21:20,720 which say 328 00:21:21,700 --> 00:21:23,340 validated the service up 329 00:21:23,340 --> 00:21:25,580 because the thing just won't compile. 330 00:21:29,620 --> 00:21:30,560 So yeah, 331 00:21:30,660 --> 00:21:32,680 there's some stuff about testing. 332 00:21:33,760 --> 00:21:35,740 The one thing about testing 333 00:21:35,740 --> 00:21:36,540 I would say is 334 00:21:36,540 --> 00:21:37,960 BOGO. 335 00:21:38,340 --> 00:21:41,080 Which is the boring SSL test suite. 336 00:21:41,260 --> 00:21:43,160 That's been super useful. 337 00:21:45,080 --> 00:21:46,960 They basically took 338 00:21:46,960 --> 00:21:49,860 the Golang TLS library 339 00:21:49,860 --> 00:21:52,580 and then made it really, really, really evil. 340 00:21:52,960 --> 00:21:53,960 Configurably evil. 341 00:21:54,260 --> 00:21:56,180 So it could do a whole 342 00:21:57,180 --> 00:21:58,380 suite of 343 00:21:59,440 --> 00:22:00,660 subtly different 344 00:22:00,660 --> 00:22:02,360 but broken 345 00:22:03,440 --> 00:22:04,140 handshakes. 346 00:22:05,770 --> 00:22:06,660 And that's pretty cool. 347 00:22:06,800 --> 00:22:08,040 It found some good bugs. 348 00:22:08,340 --> 00:22:09,300 Most of these bugs were like 349 00:22:10,020 --> 00:22:11,620 I didn't send an alert 350 00:22:11,620 --> 00:22:12,720 in a particular place 351 00:22:12,720 --> 00:22:13,520 when I was meant to. 352 00:22:14,140 --> 00:22:15,500 I sent the wrong alert. 353 00:22:15,760 --> 00:22:16,600 That kind of thing. 354 00:22:17,040 --> 00:22:18,260 There's some places where 355 00:22:18,260 --> 00:22:19,320 I sent the wrong alert. 356 00:22:19,520 --> 00:22:20,840 I sent a different alert 357 00:22:20,840 --> 00:22:21,700 to boring SSL. 358 00:22:21,860 --> 00:22:22,680 But in fact, 359 00:22:22,820 --> 00:22:23,900 the library just... 360 00:22:23,900 --> 00:22:27,340 The TLS 1.2 spec says 361 00:22:28,580 --> 00:22:29,440 send an alert 362 00:22:30,000 --> 00:22:32,460 and not what kind of alert to send. 363 00:22:32,700 --> 00:22:35,980 So I kind of aligned with boring SSL 364 00:22:35,980 --> 00:22:37,440 at that point because just well, 365 00:22:37,560 --> 00:22:38,320 life just goes on. 366 00:22:38,340 --> 00:22:38,660 It's too short. 367 00:22:41,700 --> 00:22:43,680 The other thing is performance. 368 00:22:46,560 --> 00:22:49,220 So the important number down here. 369 00:22:50,640 --> 00:22:52,580 This is just on my random machine at home. 370 00:22:53,520 --> 00:22:57,160 OpenSSL can do raw AS128 GCM 371 00:22:57,160 --> 00:23:00,080 at 37 gigabits per second 372 00:23:00,940 --> 00:23:02,160 on that machine. 373 00:23:04,060 --> 00:23:06,180 The library started out quite slowly. 374 00:23:06,340 --> 00:23:07,560 It was very copy heavy. 375 00:23:08,340 --> 00:23:11,520 So it would copy the data 376 00:23:11,520 --> 00:23:12,860 you wanted to send a whole bunch 377 00:23:15,000 --> 00:23:16,020 while encrypting it, 378 00:23:16,040 --> 00:23:17,100 fragmenting it and so on. 379 00:23:18,740 --> 00:23:22,520 Those copies got removed as time went on. 380 00:23:23,080 --> 00:23:26,720 And I think 22 gigabits per second 381 00:23:26,720 --> 00:23:28,720 per core is reasonably good. 382 00:23:28,820 --> 00:23:32,200 What I haven't done is measure OpenSSL 383 00:23:32,200 --> 00:23:36,880 in a similar phase. 384 00:23:36,980 --> 00:23:37,980 Because the difference between 385 00:23:37,980 --> 00:23:41,740 37 and 22 is basically going to be 386 00:23:41,740 --> 00:23:44,240 all the protocol framing and parsing. 387 00:23:44,620 --> 00:23:46,440 So I expect OpenSSL to be somewhere 388 00:23:46,440 --> 00:23:47,380 between those numbers. 389 00:23:48,240 --> 00:23:51,700 But yeah, I think 22 gigs per second 390 00:23:51,700 --> 00:23:56,320 per core is pretty reasonable at this point. 391 00:24:01,080 --> 00:24:03,940 The other thing was, 392 00:24:05,320 --> 00:24:07,020 so TLS 1.3, 393 00:24:07,020 --> 00:24:08,620 as it got mentioned yesterday, 394 00:24:08,700 --> 00:24:10,320 has this new and exciting feature 395 00:24:12,040 --> 00:24:15,740 coming to a DEF CON near you 396 00:24:16,660 --> 00:24:18,420 called zero RTT. 397 00:24:19,660 --> 00:24:21,900 In the protocol it's called early data, 398 00:24:22,120 --> 00:24:23,800 which is a much better name, frankly. 399 00:24:24,100 --> 00:24:27,640 This is when you're resuming a connection, 400 00:24:27,900 --> 00:24:30,900 you can start sending data with the resumption 401 00:24:31,520 --> 00:24:34,880 on the assumption that the resumption will work. 402 00:24:37,020 --> 00:24:41,760 The problem with that is that first message you send, 403 00:24:41,860 --> 00:24:44,540 that resumption and the data is replayable. 404 00:24:44,960 --> 00:24:51,100 And there are some limitations to that replay, time-based. 405 00:24:51,620 --> 00:24:54,680 And there's a new thing added to the RFC saying, 406 00:24:54,880 --> 00:24:57,780 well, you should probably prevent people 407 00:24:57,780 --> 00:25:00,780 from doing this kind of replay. 408 00:25:01,000 --> 00:25:04,420 But not, yeah, it seems like, 409 00:25:07,020 --> 00:25:09,900 a very, very tricky thing to actually get right. 410 00:25:10,740 --> 00:25:12,960 The other thing, applications have to know 411 00:25:12,960 --> 00:25:17,760 this is happening because they can, in some circumstances, 412 00:25:18,900 --> 00:25:22,860 servers at least, can receive duplicate requests 413 00:25:24,640 --> 00:25:26,760 under attacker control, basically. 414 00:25:29,340 --> 00:25:30,480 So that's not great. 415 00:25:30,880 --> 00:25:34,440 On the other hand, it's basically in a state 416 00:25:34,440 --> 00:25:36,680 where it can't really be deployed because the RFC, 417 00:25:36,680 --> 00:25:40,360 it says you have to have a profile saying, 418 00:25:40,580 --> 00:25:43,840 so there might be a profile for HTTPS which says, 419 00:25:43,960 --> 00:25:47,360 well, you know, get requests without any cookies 420 00:25:47,360 --> 00:25:50,800 can be sent like this or something like that. 421 00:25:51,220 --> 00:25:54,100 There isn't such any, there aren't any profiles 422 00:25:54,100 --> 00:25:55,960 like that at all at the minute. 423 00:25:56,080 --> 00:26:00,000 So I'm aware that some people have deployed it, 424 00:26:00,060 --> 00:26:03,840 but it's largely in a testing capacity rather than 425 00:26:03,840 --> 00:26:05,520 an actual production. 426 00:26:06,680 --> 00:26:08,640 So it's a very, very tricky system because that would be crazy. 427 00:26:10,640 --> 00:26:14,140 The other thing is, finishing off OCSP verifications. 428 00:26:14,220 --> 00:26:17,880 That's on the client side, checking that a staple OCSP 429 00:26:19,880 --> 00:26:22,460 response is valid and that your certificate 430 00:26:22,460 --> 00:26:25,540 that you've just got hasn't been revoked. 431 00:26:27,560 --> 00:26:29,680 And there's PSK support, that's kind of been 432 00:26:30,210 --> 00:26:34,220 bubbling over for a long time, but in TLS 1.3, PSK 433 00:26:34,850 --> 00:26:35,900 and resumption are, 434 00:26:36,680 --> 00:26:37,860 basically the same mechanism. 435 00:26:38,400 --> 00:26:43,260 So with resumption working, PSK is a mere matter of making 436 00:26:43,260 --> 00:26:47,820 the API exposed to the rest of the world 437 00:26:47,820 --> 00:26:51,320 and implementing it in TLS 1.2. 438 00:26:54,240 --> 00:26:58,700 And then the other thing I'd like to do is stop this library 439 00:26:58,700 --> 00:27:01,260 from being kind of rust-centric. 440 00:27:02,740 --> 00:27:06,100 So it would be really nice if this could be, you know, 441 00:27:07,340 --> 00:27:12,820 compiled into like an Apache module to terminate TLS, 442 00:27:13,480 --> 00:27:15,400 or an Nginx module or whatever. 443 00:27:18,500 --> 00:27:22,980 And the LibreSSL people came up with a nice C library, 444 00:27:23,300 --> 00:27:28,820 C interface I should say, which, it looks quite nice. 445 00:27:28,960 --> 00:27:33,100 It doesn't make me retch, so that might be a good choice. 446 00:27:33,460 --> 00:27:36,080 And hopefully by the time I get back to work, I'll be able to 447 00:27:36,080 --> 00:27:36,780 really do some more stuff around doing that. 448 00:27:36,860 --> 00:27:41,040 There'll be integrations with things like Apache and Nginx. 449 00:27:42,440 --> 00:27:45,860 And then a third party audit would be nice once everything, 450 00:27:46,140 --> 00:27:49,980 you know, once TLS 1.3 has been finalized, 451 00:27:51,160 --> 00:27:54,980 and once I'm fairly sure I'm not gonna add, you know, 452 00:27:55,060 --> 00:27:56,700 more features. 453 00:27:59,700 --> 00:28:01,680 So that's that. 454 00:28:01,820 --> 00:28:05,940 I did have some extra slides, but there. 455 00:28:06,080 --> 00:28:09,180 that kind of screwed up. 456 00:28:09,860 --> 00:28:12,700 So, any questions? 457 00:28:14,880 --> 00:28:15,440 Yeah. 458 00:28:16,960 --> 00:28:20,000 So, you mentioned a lot of the vulnerabilities 459 00:28:20,000 --> 00:28:25,060 of other TLS libraries and how you avoided them 460 00:28:25,540 --> 00:28:28,700 through non-inputting broken features and the type system, 461 00:28:28,940 --> 00:28:32,640 but of course you mentioned that there were some bugs 462 00:28:32,640 --> 00:28:33,560 that you wrote in your implementation 463 00:28:33,560 --> 00:28:36,140 which kind of by definition are bugs 464 00:28:36,140 --> 00:28:37,640 that were not prevented by those vendors. 465 00:28:37,860 --> 00:28:40,500 So, what were the kind of classes of bugs 466 00:28:40,500 --> 00:28:42,760 that did get written in Rustles 467 00:28:42,760 --> 00:28:46,480 and how can we improve our compiler and type system tooling 468 00:28:46,480 --> 00:28:48,040 to prevent those kinds of bugs as well? 469 00:28:48,720 --> 00:28:50,840 Okay, so I'll just repeat the question. 470 00:28:51,160 --> 00:28:54,620 The question was roughly what kind of bugs 471 00:28:54,620 --> 00:28:56,800 did I find in Rustles having written it 472 00:28:57,300 --> 00:28:59,760 and how could they be prevented? 473 00:29:00,740 --> 00:29:01,820 So, as I said, 474 00:29:03,560 --> 00:29:07,780 most of the bugs I found were spec non-compliance, 475 00:29:09,880 --> 00:29:11,840 not in a security, 476 00:29:14,100 --> 00:29:16,380 so they weren't necessarily vulnerabilities, 477 00:29:16,620 --> 00:29:18,920 but they could cause interrupt problems. 478 00:29:21,040 --> 00:29:24,420 So, I feel reasonably confident 479 00:29:24,420 --> 00:29:25,960 about the security of Rustles. 480 00:29:26,060 --> 00:29:29,460 What I'm not totally confident about is 481 00:29:30,920 --> 00:29:32,920 that it would be 482 00:29:32,920 --> 00:29:39,680 as interop as well as say OpenSSL or NSS or BoringSSL. 483 00:29:40,700 --> 00:29:42,820 So, those kinds of bugs, 484 00:29:43,100 --> 00:29:45,080 those interop kind of bugs, 485 00:29:45,180 --> 00:29:46,360 which I'm more worried about, 486 00:29:49,560 --> 00:29:51,620 BOGO found some of those, 487 00:29:52,900 --> 00:29:55,760 but I'm sure there are some still there. 488 00:29:56,340 --> 00:30:02,260 I think really most of those get squeezed out 489 00:30:02,260 --> 00:30:05,480 either through use or some kind of formal analysis. 490 00:30:07,340 --> 00:30:10,160 There is a project called Mount Everest, 491 00:30:11,420 --> 00:30:12,660 Project Everest, I think, 492 00:30:14,620 --> 00:30:16,520 being done by a bunch of people, 493 00:30:16,560 --> 00:30:17,880 including Microsoft Research, 494 00:30:18,220 --> 00:30:22,120 and that is gonna produce a full end-to-end, 495 00:30:23,040 --> 00:30:25,420 formally verified TLS 1.3 stack. 496 00:30:27,260 --> 00:30:29,600 So, hopefully I can use some of the results of that 497 00:30:29,600 --> 00:30:31,580 to either generate test cases, 498 00:30:33,340 --> 00:30:35,900 or generate some of the code that I've written 499 00:30:35,900 --> 00:30:41,220 from their formally verified protocol implementation. 500 00:30:41,820 --> 00:30:43,240 And I think that would be pretty cool. 501 00:30:46,940 --> 00:30:47,840 Any other questions? 502 00:30:55,160 --> 00:30:56,060 I'm looking at you, 503 00:30:56,080 --> 00:30:57,040 because you asked me a question. 504 00:31:02,260 --> 00:31:02,720 Thank you very much. 505 00:31:02,920 --> 00:31:03,660 Thank you.