0 00:00:00,000 --> 00:00:30,000 Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/483 Thanks! 1 00:00:09,310 --> 00:00:10,660 So please welcome Nick. 2 00:00:16,059 --> 00:00:18,219 OK. Hello, is this thing 3 00:00:18,220 --> 00:00:18,399 on? 4 00:00:18,400 --> 00:00:20,379 It is OK. Hello, everybody. 5 00:00:20,380 --> 00:00:21,459 I'm Nick. 6 00:00:21,460 --> 00:00:23,379 I work yes, at CloudFlare, everybody's 7 00:00:23,380 --> 00:00:25,629 favorite CDN and 8 00:00:25,630 --> 00:00:27,519 I work in applied cryptography. 9 00:00:27,520 --> 00:00:30,039 And I'm going to talk today about 10 00:00:30,040 --> 00:00:31,989 the most interesting protocol in the 11 00:00:31,990 --> 00:00:34,899 world, transport layer security. 12 00:00:34,900 --> 00:00:37,209 So if 13 00:00:37,210 --> 00:00:39,279 anybody has used this browser, 14 00:00:39,280 --> 00:00:41,379 do you recognize this little icon 15 00:00:41,380 --> 00:00:43,659 right here? This is this 16 00:00:43,660 --> 00:00:46,299 is Netscape, one point one. 17 00:00:46,300 --> 00:00:48,819 This is the first Web browser 18 00:00:48,820 --> 00:00:51,009 that had SSL that had some sort of 19 00:00:51,010 --> 00:00:52,479 layer of security built into it. 20 00:00:52,480 --> 00:00:54,009 And it had this little icon here that 21 00:00:54,010 --> 00:00:56,169 looked like a gun and maybe a pin from 22 00:00:56,170 --> 00:00:57,170 a grenade. 23 00:00:58,510 --> 00:01:00,129 But if they're connected, then that means 24 00:01:00,130 --> 00:01:02,109 your site security eventually improved it 25 00:01:02,110 --> 00:01:04,719 to this little lock icon 26 00:01:04,720 --> 00:01:07,209 that evolved to this 27 00:01:07,210 --> 00:01:09,459 like screen lock in the address bar 28 00:01:09,460 --> 00:01:10,460 that we all know and love. 29 00:01:11,500 --> 00:01:14,019 But https SSL 30 00:01:14,020 --> 00:01:15,879 this this whole encryption thing on the 31 00:01:15,880 --> 00:01:18,279 web enabled a revolution, 32 00:01:18,280 --> 00:01:20,889 starting with e-commerce. 33 00:01:20,890 --> 00:01:23,319 You can go to this beautiful website here 34 00:01:23,320 --> 00:01:25,269 with your with your browser and then buy 35 00:01:25,270 --> 00:01:27,399 some books or buy some of these you 36 00:01:27,400 --> 00:01:28,400 stuff. 37 00:01:30,200 --> 00:01:32,319 It actually was of a revolution. 38 00:01:32,320 --> 00:01:34,429 And to put 39 00:01:34,430 --> 00:01:36,489 it into context, this is 40 00:01:36,490 --> 00:01:38,709 this drawing that we did once of of what 41 00:01:38,710 --> 00:01:40,089 the Internet looks like. 42 00:01:40,090 --> 00:01:42,279 And there's all these different 43 00:01:42,280 --> 00:01:43,509 links that connect over all these 44 00:01:43,510 --> 00:01:44,739 different protocols. 45 00:01:44,740 --> 00:01:47,109 But to access websites, it's really 46 00:01:47,110 --> 00:01:48,369 point to point. 47 00:01:48,370 --> 00:01:50,379 And you go from either your phone to a 48 00:01:50,380 --> 00:01:52,569 data center or your laptop computer 49 00:01:52,570 --> 00:01:53,769 to a data center. 50 00:01:53,770 --> 00:01:56,049 And it's, 51 00:01:56,050 --> 00:01:58,059 you know, a way to get information and 52 00:01:58,060 --> 00:01:59,049 websites. 53 00:01:59,050 --> 00:02:02,079 And this originally 54 00:02:02,080 --> 00:02:04,119 is a plain text protocol. 55 00:02:04,120 --> 00:02:06,399 Everything is sent without any encryption 56 00:02:06,400 --> 00:02:08,258 or encoding. It's just letters on the 57 00:02:08,259 --> 00:02:09,159 wire. 58 00:02:09,160 --> 00:02:10,160 And 59 00:02:11,650 --> 00:02:13,689 after this came out, people wanted to add 60 00:02:13,690 --> 00:02:15,849 some security. So this 61 00:02:15,850 --> 00:02:18,759 protocol was invented called HTP 62 00:02:18,760 --> 00:02:21,009 and the S is supposed to stand 63 00:02:21,010 --> 00:02:23,349 for secure. But lately 64 00:02:23,350 --> 00:02:25,120 it's been sort of another S word. 65 00:02:27,520 --> 00:02:29,729 So HDB, HDB, 66 00:02:30,880 --> 00:02:32,499 this is HGP plus security. 67 00:02:32,500 --> 00:02:34,779 And right now what that 68 00:02:34,780 --> 00:02:36,759 means almost exclusively is this protocol 69 00:02:36,760 --> 00:02:38,199 called transport layer security that 70 00:02:38,200 --> 00:02:39,279 you've all heard about. 71 00:02:39,280 --> 00:02:41,379 And it provides 72 00:02:41,380 --> 00:02:43,659 data encryption and integrity as 73 00:02:43,660 --> 00:02:45,319 well as authentication of the server, 74 00:02:45,320 --> 00:02:46,869 tells you what website you're actually 75 00:02:46,870 --> 00:02:49,449 going to and gives you a way to verify 76 00:02:49,450 --> 00:02:50,620 that that's who it really is. 77 00:02:51,940 --> 00:02:54,099 So this is 78 00:02:54,100 --> 00:02:56,439 this is this is a messy details talk. 79 00:02:56,440 --> 00:02:58,899 So as with anything, the devil 80 00:02:58,900 --> 00:03:00,159 is in the details. 81 00:03:00,160 --> 00:03:01,779 So let's go a little bit back to the 82 00:03:01,780 --> 00:03:02,780 beginning. 83 00:03:03,760 --> 00:03:05,799 SSL was secure. 84 00:03:05,800 --> 00:03:08,409 Sockets Layer was the original protocol 85 00:03:08,410 --> 00:03:10,599 that Netscape invented back 86 00:03:10,600 --> 00:03:12,759 in the early 90s to encrypt 87 00:03:12,760 --> 00:03:14,859 the web. And it was invented by 88 00:03:14,860 --> 00:03:17,119 this guy, Kip Ebbie Hickman. 89 00:03:17,120 --> 00:03:19,089 And, you know, I heard some stories about 90 00:03:19,090 --> 00:03:21,249 this. I saw that Moxie Marlinspike 91 00:03:22,360 --> 00:03:24,459 in DEFCON 18 sort of tracked him down 92 00:03:24,460 --> 00:03:26,409 and had a phone call with him. 93 00:03:26,410 --> 00:03:28,539 But there was this story about SSL 94 00:03:28,540 --> 00:03:29,799 one being presented. 95 00:03:29,800 --> 00:03:31,989 And I emailed Phillip Halam 96 00:03:31,990 --> 00:03:34,329 Baker and he kind of described 97 00:03:34,330 --> 00:03:35,919 the setting in which SSL one was 98 00:03:35,920 --> 00:03:38,499 presented, and it was by Marc Andreessen, 99 00:03:38,500 --> 00:03:40,569 MIT to a group of around 100 00:03:40,570 --> 00:03:41,589 six people. 101 00:03:41,590 --> 00:03:42,590 And 102 00:03:43,690 --> 00:03:44,949 the people in the audience apparently 103 00:03:44,950 --> 00:03:47,079 broke it right away because there was 104 00:03:47,080 --> 00:03:50,199 no authenticity checks at all. 105 00:03:50,200 --> 00:03:52,629 So SSL V1 was an auspicious 106 00:03:52,630 --> 00:03:54,459 start to a security protocol. 107 00:03:54,460 --> 00:03:55,929 It's, you know, completely 108 00:03:55,930 --> 00:03:56,930 unauthenticated. 109 00:03:57,910 --> 00:04:00,129 So to to get back 110 00:04:00,130 --> 00:04:01,329 to it, it was evolved. 111 00:04:01,330 --> 00:04:03,759 And I'll get into how SSL 112 00:04:03,760 --> 00:04:06,039 became and, you know, became something 113 00:04:06,040 --> 00:04:07,359 that we use every day. 114 00:04:07,360 --> 00:04:09,459 But it really breaks 115 00:04:09,460 --> 00:04:10,779 down into two different pieces. 116 00:04:10,780 --> 00:04:12,939 One is public key cryptography. 117 00:04:12,940 --> 00:04:15,069 And this is how you as 118 00:04:15,070 --> 00:04:16,509 a browser and your server sort of 119 00:04:16,510 --> 00:04:18,669 established shared keys and 120 00:04:18,670 --> 00:04:20,289 the identity of the server and data 121 00:04:20,290 --> 00:04:22,389 encapsulation, which is you want to 122 00:04:22,390 --> 00:04:24,429 send data to the server and back, you 123 00:04:24,430 --> 00:04:25,719 have to encrypt it somehow and 124 00:04:25,720 --> 00:04:26,720 authenticate it. 125 00:04:28,240 --> 00:04:30,339 This key establishment part happens 126 00:04:30,340 --> 00:04:32,199 with this with what's called SSL 127 00:04:32,200 --> 00:04:34,329 handshake. And this is, you 128 00:04:34,330 --> 00:04:35,259 know, pretty complicated. 129 00:04:35,260 --> 00:04:36,970 There's pieces going back and forth. 130 00:04:38,650 --> 00:04:40,989 But let's focus first on 131 00:04:40,990 --> 00:04:43,179 that little checkmark on the left, 132 00:04:43,180 --> 00:04:44,680 which is cert validation. 133 00:04:46,000 --> 00:04:48,909 And this is how Tlas provides 134 00:04:48,910 --> 00:04:49,910 authenticity. 135 00:04:51,070 --> 00:04:53,199 This beautiful thing that 136 00:04:53,200 --> 00:04:54,759 we've all built together called the 137 00:04:54,760 --> 00:04:56,379 public key infrastructure. 138 00:04:56,380 --> 00:04:59,109 And so just 139 00:04:59,110 --> 00:05:00,099 bear with me for a second. 140 00:05:00,100 --> 00:05:01,509 Like, how how does this work? 141 00:05:01,510 --> 00:05:03,819 This is it's based on something called X 142 00:05:03,820 --> 00:05:05,529 five or nine certificates and 143 00:05:05,530 --> 00:05:06,639 certificates are 144 00:05:07,720 --> 00:05:09,789 files with different things 145 00:05:09,790 --> 00:05:11,859 like the identity of who you 146 00:05:11,860 --> 00:05:13,959 are, a public key, and they're usually 147 00:05:13,960 --> 00:05:15,219 digitally signed by. 148 00:05:15,220 --> 00:05:17,889 Certificate authority and 149 00:05:17,890 --> 00:05:19,839 this certificate authority has a 150 00:05:19,840 --> 00:05:22,179 certificate itself, and then 151 00:05:22,180 --> 00:05:23,619 oftentimes that's signed by another 152 00:05:23,620 --> 00:05:25,719 certificate authority, this forms a chain 153 00:05:25,720 --> 00:05:26,679 of trust. 154 00:05:26,680 --> 00:05:28,809 And as long as you 155 00:05:28,810 --> 00:05:30,939 can trust the sort 156 00:05:30,940 --> 00:05:33,099 of dark brown certificate there, 157 00:05:33,100 --> 00:05:35,259 then you can find these signatures 158 00:05:35,260 --> 00:05:37,389 are correct. Then you can say, OK, yes, 159 00:05:37,390 --> 00:05:38,859 this is someone I trust to issue 160 00:05:38,860 --> 00:05:41,319 certificates for websites, 161 00:05:41,320 --> 00:05:43,269 and therefore this site is really who it 162 00:05:43,270 --> 00:05:44,270 is. 163 00:05:44,650 --> 00:05:46,299 So this this whole chain of trust thing 164 00:05:46,300 --> 00:05:47,709 seems really easy, right? 165 00:05:47,710 --> 00:05:49,779 It's just checking digital 166 00:05:49,780 --> 00:05:51,549 signatures, checking, making sure that 167 00:05:51,550 --> 00:05:53,829 the the metadata inside it 168 00:05:53,830 --> 00:05:55,209 is correct and matches the site. 169 00:05:55,210 --> 00:05:56,109 You're going to. 170 00:05:56,110 --> 00:05:57,639 Well, yeah. 171 00:05:57,640 --> 00:05:59,859 Boy, was that 172 00:05:59,860 --> 00:06:01,869 they were wrong about that being easy. 173 00:06:01,870 --> 00:06:03,459 So I'm going to explore a couple of 174 00:06:03,460 --> 00:06:05,439 different ways in which this was 175 00:06:05,440 --> 00:06:07,419 completely messed up, including 176 00:06:07,420 --> 00:06:09,549 implementation, bugs, intentional 177 00:06:09,550 --> 00:06:11,649 flaws and issues 178 00:06:11,650 --> 00:06:13,059 of trust. 179 00:06:13,060 --> 00:06:15,249 So to make 180 00:06:15,250 --> 00:06:17,379 it more clear, this is what we mean when 181 00:06:17,380 --> 00:06:19,029 we validate a certificate. 182 00:06:19,030 --> 00:06:20,229 This is in that check. 183 00:06:20,230 --> 00:06:22,359 In that first diagram is 184 00:06:22,360 --> 00:06:25,209 as a client, you pass the certificate, 185 00:06:25,210 --> 00:06:27,519 you find a parent certificate, 186 00:06:27,520 --> 00:06:29,589 and you make sure that the signature 187 00:06:29,590 --> 00:06:31,749 on this certificate is signed by 188 00:06:31,750 --> 00:06:32,829 the parents publicly. 189 00:06:32,830 --> 00:06:35,199 And if that parent is trusted by you, 190 00:06:35,200 --> 00:06:36,309 then you're good. 191 00:06:36,310 --> 00:06:38,619 And you know, this is good and 192 00:06:38,620 --> 00:06:39,609 you go on. 193 00:06:39,610 --> 00:06:41,799 If not, you do the same 194 00:06:41,800 --> 00:06:42,999 thing on the certificate. 195 00:06:43,000 --> 00:06:44,959 You check it certificate, check it 196 00:06:44,960 --> 00:06:46,119 signature. 197 00:06:46,120 --> 00:06:48,369 And so this is just 198 00:06:48,370 --> 00:06:49,989 making sure the certificate is correct. 199 00:06:49,990 --> 00:06:52,059 What about actually tying this to 200 00:06:52,060 --> 00:06:53,289 your encryption channel? 201 00:06:53,290 --> 00:06:55,329 There's really two ways of doing this in 202 00:06:55,330 --> 00:06:56,409 terms. 203 00:06:56,410 --> 00:06:58,449 First is the RSA method. 204 00:06:58,450 --> 00:07:00,789 And in this method, 205 00:07:00,790 --> 00:07:03,099 as a client, you encrypt a pre 206 00:07:03,100 --> 00:07:04,719 master secret, a bit of data that you 207 00:07:04,720 --> 00:07:06,459 want to share with the server, with the 208 00:07:06,460 --> 00:07:08,319 servers publicly and send it over. 209 00:07:08,320 --> 00:07:10,149 If the server can derive the same keys 210 00:07:10,150 --> 00:07:12,369 from that information as you, then 211 00:07:12,370 --> 00:07:14,439 that's sort of an implicit validation 212 00:07:14,440 --> 00:07:16,629 that they have the corresponding private 213 00:07:16,630 --> 00:07:18,519 Key Diffie home. 214 00:07:18,520 --> 00:07:20,559 And this is much more recommended. 215 00:07:20,560 --> 00:07:21,560 By the way. 216 00:07:22,390 --> 00:07:23,920 What happens is, 217 00:07:25,330 --> 00:07:27,429 yeah, you you sign a couple 218 00:07:27,430 --> 00:07:28,389 of things, right? 219 00:07:28,390 --> 00:07:29,979 The server assigns several parameters 220 00:07:29,980 --> 00:07:31,419 that are used to derive these shared keys 221 00:07:31,420 --> 00:07:33,099 and you just verify it with the 222 00:07:33,100 --> 00:07:35,289 certificate now. 223 00:07:35,290 --> 00:07:36,579 So there's two things, right? 224 00:07:36,580 --> 00:07:38,529 Validate certificate type certificate to 225 00:07:38,530 --> 00:07:39,530 channel 226 00:07:40,720 --> 00:07:40,929 it. 227 00:07:40,930 --> 00:07:43,149 Phase one breaks, then all you have to do 228 00:07:43,150 --> 00:07:45,759 is use some untrusted certificate and 229 00:07:45,760 --> 00:07:47,859 the client will say, OK, this is good. 230 00:07:47,860 --> 00:07:49,569 I believe that this is a real trusted 231 00:07:49,570 --> 00:07:50,829 certificate. Go on from there. 232 00:07:51,880 --> 00:07:54,009 The second phase, if there's a problem 233 00:07:54,010 --> 00:07:55,239 with that, then you can use a real 234 00:07:55,240 --> 00:07:57,699 certificate, but a fake signature. 235 00:08:00,390 --> 00:08:02,079 Has anybody seen this code before? 236 00:08:03,160 --> 00:08:06,039 You got one couple of hands out here. 237 00:08:06,040 --> 00:08:08,349 This this is code in 238 00:08:08,350 --> 00:08:10,719 a library called Ganu Tools. 239 00:08:10,720 --> 00:08:12,549 And what this is really doing is it's 240 00:08:12,550 --> 00:08:15,069 supposed to check if this is a K, 241 00:08:15,070 --> 00:08:17,319 and it turns out if you remember your C 242 00:08:17,320 --> 00:08:19,479 correctly, that anything other 243 00:08:19,480 --> 00:08:22,059 than a zero return value is true and 244 00:08:22,060 --> 00:08:23,709 a zero is false. 245 00:08:23,710 --> 00:08:26,169 What happens here is if that 246 00:08:26,170 --> 00:08:28,389 one call check, if 247 00:08:28,390 --> 00:08:31,389 it's the get sign data fails, 248 00:08:31,390 --> 00:08:32,829 then you return result. 249 00:08:32,830 --> 00:08:35,199 And that result is going to be a negative 250 00:08:35,200 --> 00:08:37,359 number and therefore it's 251 00:08:37,360 --> 00:08:39,189 going to say, yes, this is a K. 252 00:08:39,190 --> 00:08:41,139 So this this bug really says if you give 253 00:08:41,140 --> 00:08:43,538 it an invalid issuer then 254 00:08:43,539 --> 00:08:44,739 oh yeah. This is a K. 255 00:08:44,740 --> 00:08:46,959 It's not bad. It's actually completely 256 00:08:46,960 --> 00:08:48,099 good as a K. 257 00:08:48,100 --> 00:08:50,499 And this code was introduced 258 00:08:50,500 --> 00:08:52,390 in 2005. 259 00:08:54,130 --> 00:08:56,229 It was discovered in again as a bug in 260 00:08:56,230 --> 00:08:58,689 2014. So in 261 00:08:58,690 --> 00:09:00,879 in all tools that used Linux. 262 00:09:00,880 --> 00:09:03,459 Can you tell us for nine years 263 00:09:03,460 --> 00:09:05,529 this channel binding, this 264 00:09:05,530 --> 00:09:07,839 is certificate authority code was 265 00:09:07,840 --> 00:09:08,769 was in there. 266 00:09:08,770 --> 00:09:09,819 This might be more familiar. 267 00:09:09,820 --> 00:09:11,889 Has anybody seen this code 268 00:09:11,890 --> 00:09:13,299 before? This is the title of the talk, 269 00:09:13,300 --> 00:09:14,289 right? 270 00:09:14,290 --> 00:09:16,359 This is an apples common crypto 271 00:09:16,360 --> 00:09:18,429 library. And again, this 272 00:09:18,430 --> 00:09:21,219 is just a simple programing bug. 273 00:09:21,220 --> 00:09:24,429 Accidentally, there's two Gote fails. 274 00:09:24,430 --> 00:09:26,139 I don't really know exactly how you could 275 00:09:26,140 --> 00:09:28,719 put to go to fails, but from 276 00:09:28,720 --> 00:09:31,089 what I understand, they're not using git 277 00:09:31,090 --> 00:09:32,979 at Apple for this library. 278 00:09:32,980 --> 00:09:35,199 So if anybody remembers how you 279 00:09:35,200 --> 00:09:37,479 merge it, merge problems 280 00:09:37,480 --> 00:09:38,919 and subversion, sometimes you end up 281 00:09:38,920 --> 00:09:40,419 getting duplicate lines. 282 00:09:40,420 --> 00:09:42,399 Maybe that's how it happened. 283 00:09:42,400 --> 00:09:43,809 Some people have considered that it may 284 00:09:43,810 --> 00:09:46,059 be more subversive, but I highly 285 00:09:46,060 --> 00:09:47,769 doubt it. But in any case, what this does 286 00:09:47,770 --> 00:09:50,319 is it'll always go to fail 287 00:09:50,320 --> 00:09:52,599 and go to fail will mean 288 00:09:52,600 --> 00:09:53,769 this key exchange. 289 00:09:53,770 --> 00:09:55,029 Yes. Is correctly tied. 290 00:09:55,030 --> 00:09:57,429 So all you have to do in this case is 291 00:09:57,430 --> 00:10:00,189 just use a certificate 292 00:10:00,190 --> 00:10:02,289 that's valid and put in some garbage 293 00:10:02,290 --> 00:10:04,299 as a signature and you're going to be 294 00:10:04,300 --> 00:10:05,499 good. 295 00:10:05,500 --> 00:10:06,849 So these are these are easy, right? 296 00:10:06,850 --> 00:10:09,189 These are just simple programing bugs 297 00:10:09,190 --> 00:10:11,079 and they completely invalidate the 298 00:10:11,080 --> 00:10:13,569 authentication in class. 299 00:10:13,570 --> 00:10:14,589 Let's look at something a little bit 300 00:10:14,590 --> 00:10:16,170 more. Complicated, 301 00:10:17,470 --> 00:10:18,470 so there's 302 00:10:19,960 --> 00:10:21,579 several different ways in which you can 303 00:10:21,580 --> 00:10:23,979 do digital signatures. 304 00:10:23,980 --> 00:10:25,689 This is the most common for RSA. 305 00:10:25,690 --> 00:10:28,149 It's a standard called pixel number one 306 00:10:28,150 --> 00:10:29,379 one point five. 307 00:10:29,380 --> 00:10:31,889 It's it's pretty horrible, 308 00:10:31,890 --> 00:10:33,999 but it looks for zero one 309 00:10:34,000 --> 00:10:35,499 a bunch of and a zero. 310 00:10:35,500 --> 00:10:37,599 And then it has this Digest's info 311 00:10:37,600 --> 00:10:39,339 which tells you what type of of hash it 312 00:10:39,340 --> 00:10:41,439 is. And this is an assigned 313 00:10:41,440 --> 00:10:43,329 one object. And if anybody's worked with 314 00:10:43,330 --> 00:10:46,089 someone, it's it's not super fun. 315 00:10:46,090 --> 00:10:47,769 And then the message digest 316 00:10:49,600 --> 00:10:51,969 back in 2006 317 00:10:51,970 --> 00:10:54,279 at the crypto conference, 318 00:10:54,280 --> 00:10:56,529 Daniel Blankenbaker, I 319 00:10:56,530 --> 00:10:58,509 hope I pronounce that correctly. 320 00:10:58,510 --> 00:11:00,609 I am in Germany anyway. 321 00:11:00,610 --> 00:11:02,919 So he found that sort of surmised 322 00:11:02,920 --> 00:11:05,019 that if you pass this incorrectly 323 00:11:05,020 --> 00:11:07,359 and we're able to put some extra garbage 324 00:11:07,360 --> 00:11:09,549 at the end, you can 325 00:11:09,550 --> 00:11:11,619 construct a fake signature 326 00:11:11,620 --> 00:11:13,209 or some signature that will actually 327 00:11:13,210 --> 00:11:15,939 work. And this only works if 328 00:11:15,940 --> 00:11:18,039 you're using RSA with the public 329 00:11:18,040 --> 00:11:19,659 exponent of three. 330 00:11:19,660 --> 00:11:21,729 And I don't 331 00:11:21,730 --> 00:11:23,379 need to go too much into the details of 332 00:11:23,380 --> 00:11:25,479 RSA, but if you 333 00:11:25,480 --> 00:11:27,549 if you do a signature verification, you 334 00:11:27,550 --> 00:11:29,799 want it to be fast and RSA and 335 00:11:29,800 --> 00:11:31,479 that's really an exponentiation with the 336 00:11:31,480 --> 00:11:32,589 public exponent. 337 00:11:32,590 --> 00:11:34,509 So people use three because that's 338 00:11:34,510 --> 00:11:35,469 incredibly fast. 339 00:11:35,470 --> 00:11:37,389 All you have to do is take your message 340 00:11:37,390 --> 00:11:39,459 and Cubitt and then 341 00:11:39,460 --> 00:11:41,559 you'll see that that's actually going to 342 00:11:41,560 --> 00:11:43,359 decrypt the message. 343 00:11:43,360 --> 00:11:45,429 And it turns out that if you can 344 00:11:45,430 --> 00:11:47,529 arbitrarily choose garbage in 345 00:11:47,530 --> 00:11:49,899 there, you can construct some value 346 00:11:49,900 --> 00:11:51,639 that cubes into 347 00:11:53,110 --> 00:11:54,129 something that looks like this. 348 00:11:55,600 --> 00:11:57,819 And then 349 00:11:57,820 --> 00:11:59,919 you can actually make a valid signature 350 00:11:59,920 --> 00:12:01,479 on on some certificate. 351 00:12:01,480 --> 00:12:03,249 And and it'll just work. 352 00:12:03,250 --> 00:12:05,529 And it turns out that there are several 353 00:12:05,530 --> 00:12:07,719 routes in the Certificate 354 00:12:07,720 --> 00:12:09,789 Authority, trusted route stores and all 355 00:12:09,790 --> 00:12:11,199 sorts of browsers that have been around 356 00:12:11,200 --> 00:12:12,939 forever that use this public exponent of 357 00:12:12,940 --> 00:12:15,009 three. So this is this is actually what's 358 00:12:15,010 --> 00:12:16,689 practical if you can put some garbage at 359 00:12:16,690 --> 00:12:18,399 the end of the Digest's. But every 360 00:12:18,400 --> 00:12:20,469 implementation now checks 361 00:12:20,470 --> 00:12:22,959 that there's no garbage at the end. 362 00:12:22,960 --> 00:12:23,960 But 363 00:12:25,330 --> 00:12:27,789 there was recently 364 00:12:27,790 --> 00:12:28,869 another mistake. Right. 365 00:12:28,870 --> 00:12:32,019 So this is another library 366 00:12:32,020 --> 00:12:34,239 called Nessus, which is very, very 367 00:12:34,240 --> 00:12:36,699 widely used. It was developed by Mozilla 368 00:12:36,700 --> 00:12:39,159 to do all the crypto in Firefox 369 00:12:39,160 --> 00:12:41,319 as well as it was used in Chrome 370 00:12:41,320 --> 00:12:42,369 back in the day. 371 00:12:42,370 --> 00:12:44,469 But it turns out there 372 00:12:44,470 --> 00:12:46,149 another coding error. And in this case, 373 00:12:46,150 --> 00:12:48,249 it's in this digest info. 374 00:12:48,250 --> 00:12:50,589 And as I mentioned, it's ACIN one, which 375 00:12:50,590 --> 00:12:52,719 is it's an 376 00:12:52,720 --> 00:12:55,059 encoding format that is is kind of crazy 377 00:12:55,060 --> 00:12:56,859 complicated, much more complicated than 378 00:12:56,860 --> 00:12:57,879 it has to be. 379 00:12:57,880 --> 00:13:00,579 And there are two encoding formats, 380 00:13:00,580 --> 00:13:02,769 B.R., which is what this is named after 381 00:13:02,770 --> 00:13:04,659 is the basic encoding rules. 382 00:13:04,660 --> 00:13:07,509 There are multiple ways of encoding data 383 00:13:07,510 --> 00:13:09,669 and you can just put extra zeros. 384 00:13:09,670 --> 00:13:12,009 There's multiple the length 385 00:13:12,010 --> 00:13:14,379 of length values is arbitrary 386 00:13:14,380 --> 00:13:16,539 so you can have different length length 387 00:13:16,540 --> 00:13:17,469 values. 388 00:13:17,470 --> 00:13:18,819 And that actually turned out to be the 389 00:13:18,820 --> 00:13:20,919 problem here is that there's 390 00:13:20,920 --> 00:13:23,139 an integer overflow in the and one 391 00:13:23,140 --> 00:13:25,539 length. So you could actually put 392 00:13:25,540 --> 00:13:26,889 a bunch of garbage in your length and 393 00:13:26,890 --> 00:13:29,259 have a several multi byte 394 00:13:29,260 --> 00:13:31,389 length value that it would 395 00:13:31,390 --> 00:13:32,469 just skip over the garbage. 396 00:13:32,470 --> 00:13:34,569 And as with 397 00:13:34,570 --> 00:13:37,719 the previous attack, you can construct 398 00:13:37,720 --> 00:13:39,849 a message that cubes into 399 00:13:39,850 --> 00:13:42,039 something like this by 400 00:13:42,040 --> 00:13:44,259 repeatedly just try and cube roots and 401 00:13:44,260 --> 00:13:45,579 there's an algorithm to do that. 402 00:13:45,580 --> 00:13:48,249 My colleague Flippo on 403 00:13:48,250 --> 00:13:49,419 put it put this up on GitHub. 404 00:13:49,420 --> 00:13:51,129 So if you want to exploit this, you can 405 00:13:51,130 --> 00:13:52,899 do so and your signatures are going to 406 00:13:52,900 --> 00:13:54,069 look weird, right? 407 00:13:54,070 --> 00:13:55,959 This is not what a digital signature 408 00:13:55,960 --> 00:13:57,609 usually looks like. It usually has quite 409 00:13:57,610 --> 00:13:59,799 a bit of entropy, but this is a 410 00:13:59,800 --> 00:14:01,449 small number. And if you cube that, you 411 00:14:01,450 --> 00:14:03,729 get something that actually looks like 412 00:14:03,730 --> 00:14:04,239 like this. 413 00:14:04,240 --> 00:14:06,399 And it'll this was actually trusted 414 00:14:06,400 --> 00:14:07,809 by by Firefox for a while. 415 00:14:09,160 --> 00:14:11,229 So there are subtle ways 416 00:14:11,230 --> 00:14:13,329 that, you know, programing bugs 417 00:14:13,330 --> 00:14:15,459 can can creep in and break the 418 00:14:15,460 --> 00:14:16,899 trust that you get from TLS. 419 00:14:18,190 --> 00:14:20,619 But speaking of 420 00:14:20,620 --> 00:14:22,539 this, issues of trust, speaking of the 421 00:14:22,540 --> 00:14:24,369 public infrastructure, you don't 422 00:14:24,370 --> 00:14:27,249 necessarily have to find 423 00:14:27,250 --> 00:14:29,529 bugs and flaws to take advantage 424 00:14:29,530 --> 00:14:30,549 of it. 425 00:14:30,550 --> 00:14:32,529 So here's a quiz for everybody 426 00:14:33,580 --> 00:14:36,039 in your say, browsers at home 427 00:14:36,040 --> 00:14:37,869 or operating systems, whatever you use, 428 00:14:37,870 --> 00:14:39,549 if you're not sort of paranoid like me 429 00:14:39,550 --> 00:14:41,649 and have removed syas, how 430 00:14:41,650 --> 00:14:43,719 many countries have controls, of 431 00:14:43,720 --> 00:14:45,819 course, that things are 432 00:14:45,820 --> 00:14:48,159 trusted that can actually sign 433 00:14:48,160 --> 00:14:49,989 any certificate that will be trusted so 434 00:14:49,990 --> 00:14:50,990 that we have a guess. 435 00:14:52,150 --> 00:14:52,689 Too many. 436 00:14:52,690 --> 00:14:54,279 Yeah that's. Yeah that's right. 437 00:14:54,280 --> 00:14:55,899 It's actually forty six. 438 00:14:55,900 --> 00:14:58,029 So this is from AIFS 439 00:14:58,030 --> 00:14:59,679 SSL Observatory data. 440 00:14:59,680 --> 00:15:01,029 Forty six countries around the world 441 00:15:01,030 --> 00:15:03,159 could you know, just arbitrarily create 442 00:15:03,160 --> 00:15:04,689 certificates for any website. 443 00:15:04,690 --> 00:15:05,690 And 444 00:15:07,540 --> 00:15:08,979 that's, that's also kind of crazy. 445 00:15:08,980 --> 00:15:10,359 How, how do you really trust that this 446 00:15:10,360 --> 00:15:12,669 was issued correctly if there are 447 00:15:12,670 --> 00:15:14,789 different entities that are supposed to. 448 00:15:14,790 --> 00:15:16,409 Follow rules, but technically can create 449 00:15:16,410 --> 00:15:17,429 certificates for anything, 450 00:15:19,410 --> 00:15:21,629 this came up earlier in this year and 451 00:15:21,630 --> 00:15:23,729 the year before, but it's been a 452 00:15:23,730 --> 00:15:25,949 sort of endemic problem with SSL. 453 00:15:25,950 --> 00:15:27,599 People want to look inside of encrypted 454 00:15:27,600 --> 00:15:30,179 data to look for bad stuff 455 00:15:30,180 --> 00:15:32,279 or to say inject ads. 456 00:15:32,280 --> 00:15:34,889 And Superfish is 457 00:15:34,890 --> 00:15:36,659 one of these things. It was installed on 458 00:15:36,660 --> 00:15:37,889 Lenovo laptops. 459 00:15:37,890 --> 00:15:39,929 And what it did was it installed its own 460 00:15:39,930 --> 00:15:41,999 trusted route into your 461 00:15:42,000 --> 00:15:43,919 route store. It made it so that every 462 00:15:43,920 --> 00:15:46,409 browser you have will trust 463 00:15:46,410 --> 00:15:48,359 this Lenovo route. So there's all sorts 464 00:15:48,360 --> 00:15:49,929 of different ways that these sort of 465 00:15:49,930 --> 00:15:51,579 things are installed. So they install 466 00:15:51,580 --> 00:15:53,009 routes, whether it's your corporate I.T. 467 00:15:53,010 --> 00:15:54,719 department, this happens all the time, 468 00:15:54,720 --> 00:15:57,209 especially here in Europe, antivirus 469 00:15:57,210 --> 00:15:59,309 software or Superfish, which is by 470 00:15:59,310 --> 00:16:01,439 your OEM or say the country 471 00:16:01,440 --> 00:16:03,569 of Kazakhstan just proposed this for the 472 00:16:03,570 --> 00:16:04,829 entire country. 473 00:16:04,830 --> 00:16:06,509 So they want to install a route so they 474 00:16:06,510 --> 00:16:08,369 can, you know, be the person in the 475 00:16:08,370 --> 00:16:10,169 middle, decrypt all your traffic and look 476 00:16:10,170 --> 00:16:11,399 at it and go go onwards. 477 00:16:11,400 --> 00:16:13,899 And the way that works is they 478 00:16:13,900 --> 00:16:16,019 on the fly forge a certificate that 479 00:16:16,020 --> 00:16:18,569 is trusted by your computer. 480 00:16:18,570 --> 00:16:20,639 So this this is 481 00:16:20,640 --> 00:16:21,839 this is bad in itself. 482 00:16:21,840 --> 00:16:23,909 But it also turns out that some of 483 00:16:23,910 --> 00:16:26,189 these proxies themselves don't validate 484 00:16:26,190 --> 00:16:28,409 certificates correctly upstream. 485 00:16:28,410 --> 00:16:31,019 So if someone was to 486 00:16:31,020 --> 00:16:32,729 manipulate this, that's not your proxy. 487 00:16:32,730 --> 00:16:34,589 Anybody can can create sort of a fake 488 00:16:34,590 --> 00:16:36,509 certificate. And this is some lot of the 489 00:16:36,510 --> 00:16:38,069 research around Superfish found that this 490 00:16:38,070 --> 00:16:39,070 is the case. Oops. 491 00:16:41,670 --> 00:16:44,099 Not only are you having ads injected 492 00:16:44,100 --> 00:16:46,679 into your supposedly encrypted streams, 493 00:16:46,680 --> 00:16:49,859 anybody on the outside can fake sites. 494 00:16:49,860 --> 00:16:51,929 An extra bonus on this is 495 00:16:51,930 --> 00:16:54,699 if you install routes into your store 496 00:16:54,700 --> 00:16:57,329 that you trust, they typically 497 00:16:57,330 --> 00:16:59,519 browsers will bypass 498 00:16:59,520 --> 00:17:02,009 these advanced techniques called keeping. 499 00:17:02,010 --> 00:17:04,108 So if you say, for example, 500 00:17:04,109 --> 00:17:06,449 in Chrome, you they have a 501 00:17:06,450 --> 00:17:08,009 pre computed list of sites and what 502 00:17:08,010 --> 00:17:09,629 certificates they should have. 503 00:17:09,630 --> 00:17:11,459 If it turns out they see a certificate 504 00:17:11,460 --> 00:17:13,709 that's signed by one of these extra 505 00:17:13,710 --> 00:17:15,899 routes that was added by, you know, any 506 00:17:15,900 --> 00:17:17,339 one of these things, then. 507 00:17:20,109 --> 00:17:21,818 Kaepernick doesn't work anymore. 508 00:17:21,819 --> 00:17:23,649 Oops, again. 509 00:17:23,650 --> 00:17:25,749 So trust, trust is 510 00:17:25,750 --> 00:17:28,059 hard and there's a lot of different ways 511 00:17:28,060 --> 00:17:30,429 in which in which it's been broken from 512 00:17:30,430 --> 00:17:33,069 bad code to bad infrastructure 513 00:17:33,070 --> 00:17:35,649 to just bad political 514 00:17:35,650 --> 00:17:37,839 organization of of who 515 00:17:37,840 --> 00:17:39,759 should get access to to making these keys 516 00:17:42,220 --> 00:17:44,289 looking a little more deeply. 517 00:17:44,290 --> 00:17:45,549 There's a bunch of different libraries 518 00:17:45,550 --> 00:17:48,849 that do crypto. And as I mentioned here, 519 00:17:48,850 --> 00:17:51,519 almost all of these were affected by 520 00:17:51,520 --> 00:17:53,139 these validation bugs at one point or 521 00:17:53,140 --> 00:17:55,059 another in the last in the last decade. 522 00:17:56,220 --> 00:17:57,399 So that's the client side. 523 00:17:57,400 --> 00:17:59,589 Let's talk about some issues on 524 00:17:59,590 --> 00:18:00,699 the server side. 525 00:18:00,700 --> 00:18:02,979 And just just as a summary, most 526 00:18:02,980 --> 00:18:05,439 websites use 527 00:18:05,440 --> 00:18:07,809 Apache, Microsoft, 528 00:18:07,810 --> 00:18:10,209 SS, Engine X, 529 00:18:10,210 --> 00:18:12,679 sorry, not ISIS and 530 00:18:12,680 --> 00:18:14,799 Engine X or say Google's internal 531 00:18:14,800 --> 00:18:15,849 stuff. And 532 00:18:16,990 --> 00:18:18,729 and this mostly uses open SSL. 533 00:18:18,730 --> 00:18:19,959 And you might have heard some things 534 00:18:19,960 --> 00:18:22,119 about openness so lately, but I'll get 535 00:18:22,120 --> 00:18:24,459 into that earlier 536 00:18:24,460 --> 00:18:26,709 in the decade or actually earlier 537 00:18:26,710 --> 00:18:28,629 in the last decade, there was another 538 00:18:28,630 --> 00:18:30,399 library that was very common and it was 539 00:18:30,400 --> 00:18:32,529 by RSA and it was 540 00:18:32,530 --> 00:18:34,809 called Be Safe and 541 00:18:34,810 --> 00:18:37,239 Be Safe was one of the first 542 00:18:37,240 --> 00:18:39,699 robust SSL implementations 543 00:18:39,700 --> 00:18:41,919 and SSL implementations. 544 00:18:41,920 --> 00:18:44,079 Are all these crypto 545 00:18:44,080 --> 00:18:46,059 things that I've mentioned require you to 546 00:18:46,060 --> 00:18:48,309 generate random numbers to generate 547 00:18:48,310 --> 00:18:49,299 these keys. 548 00:18:49,300 --> 00:18:51,369 And I don't know if you've heard 549 00:18:51,370 --> 00:18:52,779 about this. You probably have. 550 00:18:52,780 --> 00:18:55,179 But Dualeh RBG, 551 00:18:55,180 --> 00:18:57,579 it turns out there is a random 552 00:18:57,580 --> 00:18:59,739 number generator that was standardized 553 00:18:59,740 --> 00:19:01,869 benice from the NSA 554 00:19:01,870 --> 00:19:04,029 that is almost 555 00:19:04,030 --> 00:19:05,769 guaranteed to be back doored. 556 00:19:05,770 --> 00:19:08,079 So even if all of your implementation 557 00:19:08,080 --> 00:19:09,729 is good, if your random numbers that are 558 00:19:09,730 --> 00:19:11,949 using in your system are bad, you can 559 00:19:11,950 --> 00:19:14,799 work backwards and decrypt a stream. 560 00:19:14,800 --> 00:19:16,959 So this was in B safe and it 561 00:19:16,960 --> 00:19:18,549 came up even even in the last couple of 562 00:19:18,550 --> 00:19:21,159 weeks where in Juniper 563 00:19:21,160 --> 00:19:23,409 Juniper Screen OS 564 00:19:23,410 --> 00:19:26,109 they had this dual 565 00:19:26,110 --> 00:19:27,969 RBG, although they changed the parameters 566 00:19:27,970 --> 00:19:30,099 to not the ones that the NSA knows, but 567 00:19:30,100 --> 00:19:32,889 to the ones that potentially they know. 568 00:19:32,890 --> 00:19:34,989 But yeah, 569 00:19:34,990 --> 00:19:37,209 if randomness is also, you know, another 570 00:19:37,210 --> 00:19:38,260 weakness to the system. 571 00:19:41,050 --> 00:19:43,179 Heartbleed, this is a big 572 00:19:43,180 --> 00:19:45,699 deal last year, sort of, but 573 00:19:45,700 --> 00:19:47,679 it turns out this is this is just another 574 00:19:47,680 --> 00:19:49,689 dumb bug, Nancy, right. 575 00:19:49,690 --> 00:19:52,090 It's just an overread 576 00:19:53,620 --> 00:19:55,749 that ends up disclosing information 577 00:19:55,750 --> 00:19:56,889 on the server. 578 00:19:56,890 --> 00:19:59,349 This one was really bad because 579 00:19:59,350 --> 00:20:01,539 there is another architecture problem 580 00:20:01,540 --> 00:20:04,149 in Teela servers, which is 581 00:20:04,150 --> 00:20:06,069 your private key is kept in the same 582 00:20:06,070 --> 00:20:08,229 memory space as everything 583 00:20:08,230 --> 00:20:10,149 else. And if you think of the way that 584 00:20:10,150 --> 00:20:11,889 people design the security systems 585 00:20:11,890 --> 00:20:14,169 defense in depth, this this is kind 586 00:20:14,170 --> 00:20:16,269 of absurd that the 587 00:20:16,270 --> 00:20:18,549 most exposed system that you have, the 588 00:20:18,550 --> 00:20:20,019 Web server, what's actually being 589 00:20:20,020 --> 00:20:22,149 connected to by the outside world, has 590 00:20:22,150 --> 00:20:24,099 in its memory space the keys to the 591 00:20:24,100 --> 00:20:25,189 kingdom, the private key. 592 00:20:25,190 --> 00:20:27,579 But Harper just helped reveal this. 593 00:20:27,580 --> 00:20:29,319 And and it was another big one that 594 00:20:29,320 --> 00:20:31,689 affected. As I said, almost everything 595 00:20:31,690 --> 00:20:33,909 uses open SSL and 596 00:20:33,910 --> 00:20:36,279 if it was in open SSL for several 597 00:20:36,280 --> 00:20:37,280 versions. 598 00:20:38,690 --> 00:20:40,869 So implementation bugs are fun, right? 599 00:20:40,870 --> 00:20:42,699 It's it's fine. People write code, people 600 00:20:42,700 --> 00:20:43,869 mess up writing code. 601 00:20:43,870 --> 00:20:45,969 There are formal verification methods are 602 00:20:45,970 --> 00:20:47,439 a ways to catch this. 603 00:20:47,440 --> 00:20:50,319 But this talk is about tools. 604 00:20:50,320 --> 00:20:52,379 And so tell us 605 00:20:52,380 --> 00:20:53,859 it might be hard to implement correctly. 606 00:20:53,860 --> 00:20:55,029 A lot of people made mistakes. 607 00:20:55,030 --> 00:20:56,979 What about the protocol itself? 608 00:20:58,310 --> 00:20:59,859 It turns out this has been 609 00:21:01,060 --> 00:21:03,459 quite a disastrous 610 00:21:03,460 --> 00:21:06,579 couple of years in terms of the protocol. 611 00:21:06,580 --> 00:21:08,829 Let's this is the timeline of, I guess, 612 00:21:08,830 --> 00:21:10,629 tools and SSL versions. 613 00:21:10,630 --> 00:21:12,519 SSL one, I guess it's 1994. 614 00:21:12,520 --> 00:21:13,989 There's not really a lot of record as to 615 00:21:13,990 --> 00:21:16,329 when that happened, but SSL two 616 00:21:16,330 --> 00:21:18,609 came out in 94, 99 617 00:21:18,610 --> 00:21:20,799 was SSL three, then the ITF 618 00:21:20,800 --> 00:21:23,139 get their hands on it and turned it into 619 00:21:23,140 --> 00:21:26,169 a new protocol called Tlas one which 620 00:21:26,170 --> 00:21:28,389 on the underlying if you look at the bits 621 00:21:28,390 --> 00:21:30,099 and bytes, it's actually SSL three point 622 00:21:30,100 --> 00:21:32,199 one. It's not that much is 623 00:21:32,200 --> 00:21:34,569 different. There's a stronger definition 624 00:21:34,570 --> 00:21:36,639 of padding. I'll get into that later, but 625 00:21:36,640 --> 00:21:38,109 there's not many things have changed. 626 00:21:39,190 --> 00:21:41,319 Then down in 2006, we came 627 00:21:41,320 --> 00:21:44,019 up with one point one, which 628 00:21:44,020 --> 00:21:46,119 did almost again not very many changes. 629 00:21:46,120 --> 00:21:48,369 It just made sure that in CBC mode 630 00:21:48,370 --> 00:21:49,269 there's an I.V. 631 00:21:49,270 --> 00:21:50,679 I'll get to that, too. 632 00:21:50,680 --> 00:21:52,779 And then tell us one point two, 633 00:21:52,780 --> 00:21:54,879 one point three is sort of coming up in 634 00:21:54,880 --> 00:21:56,049 the next in the next year. 635 00:21:58,930 --> 00:22:00,669 It's it looks like, OK, nothing can 636 00:22:00,670 --> 00:22:01,839 really happen. 637 00:22:01,840 --> 00:22:04,869 These protocols all seem similar. 638 00:22:04,870 --> 00:22:07,179 But in the meantime, 639 00:22:07,180 --> 00:22:09,549 people have developed 640 00:22:09,550 --> 00:22:11,769 HTP and and how 641 00:22:11,770 --> 00:22:14,049 the Web is used for 642 00:22:14,050 --> 00:22:16,299 sending information has evolved 643 00:22:16,300 --> 00:22:18,699 it back in, say, 94 Web pages 644 00:22:18,700 --> 00:22:20,469 were just one static thing, but we didn't 645 00:22:20,470 --> 00:22:22,089 have cookies. We didn't have JavaScript. 646 00:22:22,090 --> 00:22:24,549 We didn't have all of these sort of fancy 647 00:22:24,550 --> 00:22:26,169 bells and whistles that are in the modern 648 00:22:26,170 --> 00:22:27,129 web. 649 00:22:27,130 --> 00:22:28,130 So. 650 00:22:29,970 --> 00:22:32,519 Turns out that HTP is really 651 00:22:32,520 --> 00:22:34,650 great for enabling crypto attacks, 652 00:22:36,660 --> 00:22:39,239 if you can use 653 00:22:39,240 --> 00:22:41,099 you can you can do repeated plaintext 654 00:22:41,100 --> 00:22:42,539 attacks, you can do chozen plaintext 655 00:22:42,540 --> 00:22:44,069 attacks. There's a lot of different 656 00:22:44,070 --> 00:22:46,319 things that HP allows you to do as 657 00:22:46,320 --> 00:22:47,819 long as you can get men in the middle 658 00:22:47,820 --> 00:22:48,719 access. 659 00:22:48,720 --> 00:22:50,849 And as an attacker, this is this is 660 00:22:50,850 --> 00:22:52,709 kind of how you do it. If you are on the 661 00:22:52,710 --> 00:22:55,169 local network with somebody else, then 662 00:22:55,170 --> 00:22:56,789 you can use AAFP spoofing or some other 663 00:22:56,790 --> 00:22:58,979 method to get man in the middle position 664 00:22:58,980 --> 00:23:01,619 and you can inject random JavaScript 665 00:23:01,620 --> 00:23:03,869 onto unencrypted pages. 666 00:23:03,870 --> 00:23:05,999 And with that JavaScript, you 667 00:23:06,000 --> 00:23:08,459 can trigger the browser to send requests. 668 00:23:08,460 --> 00:23:10,769 Now, in HTP, there are some nice 669 00:23:10,770 --> 00:23:13,019 things like cross site origin 670 00:23:13,020 --> 00:23:15,659 policies that prevent 671 00:23:15,660 --> 00:23:17,669 prevent you from from really doing a lot 672 00:23:17,670 --> 00:23:19,229 of different things. But you can you can 673 00:23:19,230 --> 00:23:21,089 inject JavaScript into one page to make 674 00:23:21,090 --> 00:23:22,769 requests to another. 675 00:23:22,770 --> 00:23:24,899 And the way that cookies work is 676 00:23:24,900 --> 00:23:26,759 they'll always be sent. 677 00:23:26,760 --> 00:23:28,829 Even if the server has 678 00:23:28,830 --> 00:23:30,750 cross site request forgery protection. 679 00:23:31,800 --> 00:23:33,539 You can still send cookies, you can still 680 00:23:33,540 --> 00:23:34,469 sound requests. 681 00:23:34,470 --> 00:23:36,719 And it turns out that if you can trigger 682 00:23:36,720 --> 00:23:39,509 errors and less, then 683 00:23:39,510 --> 00:23:41,129 the client will resend the same thing. 684 00:23:41,130 --> 00:23:42,659 So it'll send you can send passwords, 685 00:23:42,660 --> 00:23:44,339 anything that goes along, you can kind of 686 00:23:45,510 --> 00:23:47,609 put whatever you want in the URL and 687 00:23:47,610 --> 00:23:50,009 stretch this out, do chozen plaintext 688 00:23:50,010 --> 00:23:52,169 things. And what this allows 689 00:23:52,170 --> 00:23:53,849 is different, 690 00:23:54,870 --> 00:23:57,209 what are called oracles, which is 691 00:23:57,210 --> 00:23:59,339 tools to as an attacker 692 00:23:59,340 --> 00:24:01,409 reveal the plain text one bit or 693 00:24:01,410 --> 00:24:02,579 bite at a time. 694 00:24:02,580 --> 00:24:04,649 And compression oracles are, I guess, the 695 00:24:04,650 --> 00:24:06,959 easiest to explain 696 00:24:06,960 --> 00:24:09,419 in this HTP 697 00:24:09,420 --> 00:24:11,399 in order to save space is compressed. 698 00:24:11,400 --> 00:24:13,469 And typically we use some 699 00:24:13,470 --> 00:24:15,629 algorithm like Guiseppe or a dictionary 700 00:24:15,630 --> 00:24:17,969 based hash sorry compression 701 00:24:17,970 --> 00:24:20,159 algorithm in which if 702 00:24:20,160 --> 00:24:21,989 you have two repeated strings, it's going 703 00:24:21,990 --> 00:24:24,149 to be shorter than if you do not have two 704 00:24:24,150 --> 00:24:25,379 repeated strings. 705 00:24:25,380 --> 00:24:28,559 And that ends up being enough 706 00:24:28,560 --> 00:24:30,749 to allow you to decrypt an entire 707 00:24:30,750 --> 00:24:32,459 session if you can get the client to 708 00:24:32,460 --> 00:24:33,179 repeat. 709 00:24:33,180 --> 00:24:34,200 So if 710 00:24:35,340 --> 00:24:37,529 you use something like this, you 711 00:24:37,530 --> 00:24:40,439 can get a client to keep sending requests 712 00:24:40,440 --> 00:24:42,389 and you can as a man in the middle 713 00:24:42,390 --> 00:24:44,129 position, you can kind of rearrange bytes 714 00:24:44,130 --> 00:24:46,079 and packets around, but you can get the 715 00:24:46,080 --> 00:24:47,519 browser to keep sending requests with 716 00:24:47,520 --> 00:24:48,509 secret data in it. 717 00:24:48,510 --> 00:24:50,129 You can't see inside the browser, but you 718 00:24:50,130 --> 00:24:52,349 can see the encrypted packets going past 719 00:24:52,350 --> 00:24:53,399 you and 720 00:24:55,350 --> 00:24:57,569 crime in breach are. 721 00:24:57,570 --> 00:24:59,899 These came out a couple of years ago as 722 00:24:59,900 --> 00:25:01,349 a practical, very practical 723 00:25:01,350 --> 00:25:03,689 implementations of a 724 00:25:04,740 --> 00:25:06,779 oracle for compression. 725 00:25:06,780 --> 00:25:08,789 And in a practical sense, this is this is 726 00:25:08,790 --> 00:25:10,919 kind of how it works. You choose your 727 00:25:10,920 --> 00:25:12,269 padding and 728 00:25:13,950 --> 00:25:16,049 padding here is 729 00:25:16,050 --> 00:25:17,549 anything at the end of the query string. 730 00:25:17,550 --> 00:25:18,659 You control this, you control the 731 00:25:18,660 --> 00:25:19,979 JavaScript so you can put whatever you 732 00:25:19,980 --> 00:25:22,019 want there. You can get some padding and 733 00:25:22,020 --> 00:25:23,399 you want to guess the cookie. 734 00:25:23,400 --> 00:25:25,739 So the point is you keep repeating 735 00:25:25,740 --> 00:25:28,229 the guesses until 736 00:25:28,230 --> 00:25:29,579 it matches the cookie. 737 00:25:29,580 --> 00:25:31,229 And if you if your guess matches a 738 00:25:31,230 --> 00:25:32,759 cookie. Exactly. 739 00:25:32,760 --> 00:25:34,589 Then the message is going to be really 740 00:25:34,590 --> 00:25:35,590 small. 741 00:25:37,620 --> 00:25:39,689 And if you 742 00:25:39,690 --> 00:25:42,179 look at this say say you're guessing 743 00:25:42,180 --> 00:25:44,189 one bite at a time, if you have a bad 744 00:25:44,190 --> 00:25:46,439 guess, it's probably going to be longer 745 00:25:46,440 --> 00:25:48,239 and it's going to be five compress 746 00:25:48,240 --> 00:25:48,989 blocks. 747 00:25:48,990 --> 00:25:50,429 And if you have the correct guess, it's 748 00:25:50,430 --> 00:25:52,139 going to be for compressible blocks. 749 00:25:52,140 --> 00:25:54,269 So if you use your padding to kind 750 00:25:54,270 --> 00:25:56,429 of align yourself to hit the 751 00:25:56,430 --> 00:25:58,919 border between these encryption blocks, 752 00:25:58,920 --> 00:26:01,169 you can go one by one decrypting 753 00:26:01,170 --> 00:26:03,239 your values in this cookie and 754 00:26:03,240 --> 00:26:04,989 go all the way down to the to the bottom. 755 00:26:04,990 --> 00:26:06,930 And this is a practical text that's been 756 00:26:08,160 --> 00:26:10,649 that's been pulled off. So crime 757 00:26:10,650 --> 00:26:12,479 is about Tlas compression. 758 00:26:12,480 --> 00:26:14,639 Everyone disabled Tlas compression 759 00:26:14,640 --> 00:26:16,499 after crime happened. 760 00:26:16,500 --> 00:26:18,179 Breach came out the next year, a black 761 00:26:18,180 --> 00:26:20,339 hat. And this 762 00:26:20,340 --> 00:26:22,529 relies on HTP compression, 763 00:26:22,530 --> 00:26:24,959 which for performance reasons, 764 00:26:24,960 --> 00:26:26,039 nobody has turned off. 765 00:26:26,040 --> 00:26:28,169 So crime is not really a problem 766 00:26:28,170 --> 00:26:29,849 now, but breach is actually very 767 00:26:29,850 --> 00:26:32,010 exploitable in many, many, many websites, 768 00:26:33,300 --> 00:26:35,309 which is lamentable. 769 00:26:36,660 --> 00:26:38,999 But compression is not the only way to 770 00:26:39,000 --> 00:26:40,889 have an oracle padding. 771 00:26:40,890 --> 00:26:43,079 Oracles are a kind of an older 772 00:26:43,080 --> 00:26:43,979 idea. 773 00:26:43,980 --> 00:26:46,439 They were originally described by Vodoun 774 00:26:46,440 --> 00:26:48,629 in 2002 and they rely on 775 00:26:48,630 --> 00:26:50,999 two really, really bad choices that 776 00:26:51,000 --> 00:26:53,309 people made in deciding how 777 00:26:53,310 --> 00:26:55,469 to encrypt things into us. 778 00:26:55,470 --> 00:26:57,659 And these are CBC mode and 779 00:26:57,660 --> 00:26:59,759 then the Mac then encrypt 780 00:26:59,760 --> 00:27:01,380 construction, so. 781 00:27:02,840 --> 00:27:05,329 If you recall, I don't block cyphers 782 00:27:05,330 --> 00:27:07,609 require you to have a certain 783 00:27:07,610 --> 00:27:09,559 number of blocks of data that go in a 784 00:27:09,560 --> 00:27:11,609 certain and that same number comes out. 785 00:27:11,610 --> 00:27:13,849 So for as the most popular blocks 786 00:27:13,850 --> 00:27:15,949 ever, we have 16 bikes come in, 787 00:27:15,950 --> 00:27:17,419 16 bikes come out. 788 00:27:17,420 --> 00:27:19,519 So I'm sure you've all 789 00:27:19,520 --> 00:27:21,799 seen the ECB 790 00:27:21,800 --> 00:27:24,199 penguin. It's it's 791 00:27:24,200 --> 00:27:26,479 the classic example of why CBC matters 792 00:27:26,480 --> 00:27:27,829 or why you need to do chaining. 793 00:27:27,830 --> 00:27:29,959 If you if you only encrypt blocks 794 00:27:29,960 --> 00:27:31,219 on their own and don't chain them 795 00:27:31,220 --> 00:27:33,139 together, then you can actually see some 796 00:27:33,140 --> 00:27:35,119 if you have low entropy data, if you have 797 00:27:35,120 --> 00:27:37,189 data that does that repeats the same kind 798 00:27:37,190 --> 00:27:38,959 of 16 by blocks over and over again like 799 00:27:38,960 --> 00:27:40,999 images, then you can kind of make out 800 00:27:41,000 --> 00:27:43,129 with the images with CBC. 801 00:27:43,130 --> 00:27:45,049 This is a way just of mixing one block 802 00:27:45,050 --> 00:27:46,189 into the next block. 803 00:27:46,190 --> 00:27:49,009 And you just saw in the ciphertext 804 00:27:49,010 --> 00:27:50,539 into the next plain text block and 805 00:27:50,540 --> 00:27:52,609 encrypt. And this gives you a good amount 806 00:27:52,610 --> 00:27:54,469 of randomness all throughout your data. 807 00:27:54,470 --> 00:27:56,299 And decryption happens sort of the same 808 00:27:56,300 --> 00:27:58,219 way you start with this initialization 809 00:27:58,220 --> 00:28:00,289 vector and then you just 810 00:28:00,290 --> 00:28:01,489 or the ciphertext walk into your 811 00:28:01,490 --> 00:28:03,589 decrypted block and you go all 812 00:28:03,590 --> 00:28:04,590 the way down. 813 00:28:05,690 --> 00:28:07,429 So this is this is Corkman. 814 00:28:07,430 --> 00:28:09,349 It it looks it looks fine, right? 815 00:28:09,350 --> 00:28:11,419 I mean, this is this is something that 816 00:28:11,420 --> 00:28:13,489 is a good way to kind 817 00:28:13,490 --> 00:28:15,589 of combine crypto or so we thought 818 00:28:15,590 --> 00:28:17,089 in the 90s when this was invented. 819 00:28:19,160 --> 00:28:21,259 Another debate that happened was if you 820 00:28:21,260 --> 00:28:23,539 want to have you need integrity and 821 00:28:23,540 --> 00:28:25,669 encryption. So which do you do first? 822 00:28:25,670 --> 00:28:27,079 You encrypt first and then you add an 823 00:28:27,080 --> 00:28:28,119 integrity tag. 824 00:28:28,120 --> 00:28:29,539 You do integrity first and then add 825 00:28:29,540 --> 00:28:30,540 encryption 826 00:28:32,090 --> 00:28:33,349 somewhat disastrously. 827 00:28:33,350 --> 00:28:35,509 They decided to do the integrity 828 00:28:35,510 --> 00:28:38,249 first and then encryption and fertilize. 829 00:28:38,250 --> 00:28:39,379 It kind of looks like this. 830 00:28:39,380 --> 00:28:41,749 There's a data back 831 00:28:41,750 --> 00:28:44,119 and then padding and the data 832 00:28:44,120 --> 00:28:46,249 itself and then that 833 00:28:46,250 --> 00:28:48,649 whole thing is padded up to a 16 834 00:28:48,650 --> 00:28:50,959 by boundry for a yes or an API 835 00:28:50,960 --> 00:28:52,700 boundary for does, but 836 00:28:53,810 --> 00:28:55,999 up to the 16 by boundary and then 837 00:28:56,000 --> 00:28:58,459 encrypted. So this 838 00:28:58,460 --> 00:28:59,460 Mac is you have. 839 00:29:00,770 --> 00:29:02,929 Excuse me, Mac. The data with the header 840 00:29:02,930 --> 00:29:04,970 and the sequence number and 841 00:29:06,080 --> 00:29:08,359 that's that's gives you data 842 00:29:08,360 --> 00:29:09,769 that's authenticated and then encrypted. 843 00:29:09,770 --> 00:29:11,959 But that panning there is 844 00:29:11,960 --> 00:29:14,059 not authenticated, which 845 00:29:14,060 --> 00:29:15,559 turns out to be a critical flaw 846 00:29:16,880 --> 00:29:18,709 now in Telus or an SSL. 847 00:29:18,710 --> 00:29:20,629 What does that padding look like? 848 00:29:20,630 --> 00:29:21,630 Well, 849 00:29:22,820 --> 00:29:24,979 the terminal byte is the number of bytes 850 00:29:24,980 --> 00:29:26,659 of padding remaining and then it just 851 00:29:26,660 --> 00:29:28,879 have a bunch of garbage so you can pad 852 00:29:28,880 --> 00:29:30,949 things with zero and then it has zero 853 00:29:30,950 --> 00:29:32,219 bytes before it or one with one bite 854 00:29:32,220 --> 00:29:33,529 before up to whatever, whatever, 855 00:29:35,540 --> 00:29:37,819 and then it'll stay updated that so 856 00:29:37,820 --> 00:29:40,069 that these bytes of padding have to match 857 00:29:40,070 --> 00:29:41,059 the original pattern. 858 00:29:41,060 --> 00:29:42,060 But. 859 00:29:44,480 --> 00:29:46,339 Just having unauthenticated data is 860 00:29:46,340 --> 00:29:48,769 enough to give you what's called 861 00:29:48,770 --> 00:29:51,229 a padding oracle, so if an attacker 862 00:29:51,230 --> 00:29:54,529 is able to distinguish between 863 00:29:54,530 --> 00:29:56,539 guessing a pattern correctly or 864 00:29:56,540 --> 00:29:58,609 incorrectly, that's enough to 865 00:29:58,610 --> 00:30:00,989 decrypt an entire message. 866 00:30:00,990 --> 00:30:03,109 And technically, how that works is 867 00:30:05,660 --> 00:30:07,549 if you are in a man in the middle 868 00:30:07,550 --> 00:30:09,829 position, you want to guess the last 869 00:30:09,830 --> 00:30:11,869 bit of data. 870 00:30:11,870 --> 00:30:14,389 You modify the previous ciphertext 871 00:30:14,390 --> 00:30:16,369 block and you put in a guess. 872 00:30:16,370 --> 00:30:18,439 And the way CBC mode works is 873 00:30:18,440 --> 00:30:20,359 that gets expert in with B or decrypted 874 00:30:20,360 --> 00:30:23,119 block and you end up with 875 00:30:23,120 --> 00:30:24,619 M, which is the padding. 876 00:30:24,620 --> 00:30:25,620 So 877 00:30:26,720 --> 00:30:28,489 if you know that the pattern is wrong 878 00:30:28,490 --> 00:30:30,709 versus right in the bottom 879 00:30:30,710 --> 00:30:32,179 case here, you know that the padding is 880 00:30:32,180 --> 00:30:34,369 correct because zero zero zero 881 00:30:34,370 --> 00:30:36,109 is the correct padding. 882 00:30:36,110 --> 00:30:37,999 B is going to be wrong because this is 883 00:30:38,000 --> 00:30:39,769 your X or some bad decrypted data into 884 00:30:39,770 --> 00:30:40,770 there. But 885 00:30:41,870 --> 00:30:44,299 you can work backwards with this Exalogic 886 00:30:44,300 --> 00:30:46,639 to figure out what 887 00:30:46,640 --> 00:30:48,169 that value is. 888 00:30:48,170 --> 00:30:50,329 And then once you have a 889 00:30:50,330 --> 00:30:52,219 you can work back and figure out what the 890 00:30:52,220 --> 00:30:53,899 next value before it b is. 891 00:30:53,900 --> 00:30:56,179 And all you need to do is 892 00:30:56,180 --> 00:30:58,249 to be able to tell as 893 00:30:58,250 --> 00:31:00,439 an attacker whether you're in case 894 00:31:00,440 --> 00:31:01,640 one or case two 895 00:31:03,620 --> 00:31:05,299 this pattern. Oracle was originally 896 00:31:06,320 --> 00:31:08,089 built into the protocol. 897 00:31:08,090 --> 00:31:10,369 So there was 898 00:31:10,370 --> 00:31:11,779 this is the original Vodoun attack in 899 00:31:11,780 --> 00:31:12,780 2002. 900 00:31:13,920 --> 00:31:15,539 You'd have a different area code for 901 00:31:15,540 --> 00:31:17,249 whether the padding was wrong or the 902 00:31:17,250 --> 00:31:19,559 smack was wrong, and as an attacker, 903 00:31:19,560 --> 00:31:22,439 you try all 256 904 00:31:22,440 --> 00:31:24,989 values for X, and 905 00:31:24,990 --> 00:31:26,759 once you guessed correctly, it's going to 906 00:31:26,760 --> 00:31:29,009 give you the error code that says, oh, 907 00:31:29,010 --> 00:31:31,079 bad Mac, meaning you 908 00:31:31,080 --> 00:31:33,479 got past the padding and your your 909 00:31:33,480 --> 00:31:35,309 and then you're right and you actually 910 00:31:35,310 --> 00:31:36,839 have decrypted one bite. 911 00:31:36,840 --> 00:31:39,269 So this 912 00:31:39,270 --> 00:31:41,069 this problem keeps coming back. 913 00:31:41,070 --> 00:31:43,319 There are many, many ways 914 00:31:43,320 --> 00:31:45,599 in which you can have side panels. 915 00:31:45,600 --> 00:31:47,789 So the air side channel works 916 00:31:47,790 --> 00:31:49,499 as if you have an incorrect guess bad 917 00:31:49,500 --> 00:31:51,839 padding. Karakus that back. 918 00:31:53,340 --> 00:31:55,469 Later the next year, Binay and 919 00:31:55,470 --> 00:31:57,689 Bromley came up with this timing side 920 00:31:57,690 --> 00:31:59,939 channel. So it turns out that 921 00:31:59,940 --> 00:32:02,039 if you are having an incorrect 922 00:32:02,040 --> 00:32:05,249 guess, then this is going to be fast 923 00:32:05,250 --> 00:32:07,319 because you're not doing the Mac and it's 924 00:32:07,320 --> 00:32:09,959 going to be slow if you 925 00:32:09,960 --> 00:32:11,429 actually do get the padding correctly. 926 00:32:11,430 --> 00:32:13,619 So you just look at how long it takes for 927 00:32:13,620 --> 00:32:16,079 the server to do this, this computation. 928 00:32:16,080 --> 00:32:18,329 And voila, you have another 929 00:32:18,330 --> 00:32:19,889 categorical. You just might have to try a 930 00:32:19,890 --> 00:32:21,959 couple extra times to get rid of timing 931 00:32:21,960 --> 00:32:24,029 jitters. But this lets you decrypt 932 00:32:24,030 --> 00:32:25,049 entire messages. 933 00:32:25,050 --> 00:32:27,179 And in the context of HTP, this 934 00:32:27,180 --> 00:32:29,669 is your entire cookie or your password 935 00:32:29,670 --> 00:32:31,319 or something like this now. 936 00:32:34,910 --> 00:32:36,949 This is all well and good, but as I 937 00:32:36,950 --> 00:32:39,799 mentioned, things keep coming back 938 00:32:39,800 --> 00:32:40,800 and. 939 00:32:42,320 --> 00:32:45,679 Paterson came out with Lucky 13. 940 00:32:45,680 --> 00:32:47,959 This is two years ago, and it relies 941 00:32:47,960 --> 00:32:50,509 on a really kind of 942 00:32:50,510 --> 00:32:52,609 obscure fact about how 943 00:32:52,610 --> 00:32:54,859 this SCHMOCK is actually computed. 944 00:32:54,860 --> 00:32:56,989 So, as 945 00:32:56,990 --> 00:32:59,239 I mentioned before, you can 946 00:32:59,240 --> 00:33:01,369 make this this sort of 947 00:33:01,370 --> 00:33:03,199 eight by sequence number five byte header 948 00:33:03,200 --> 00:33:04,940 and your data and. 949 00:33:06,250 --> 00:33:08,559 The the fix for this timing 950 00:33:08,560 --> 00:33:10,599 attack that happened was you just always 951 00:33:10,600 --> 00:33:11,799 smacked the whole thing off the paddlings 952 00:33:11,800 --> 00:33:13,749 wrong, you smacked the whole message. 953 00:33:13,750 --> 00:33:16,089 And it turns out that 954 00:33:16,090 --> 00:33:17,950 in most implementations of Mac, 955 00:33:19,270 --> 00:33:21,579 there's a lucky 956 00:33:21,580 --> 00:33:23,589 bite. There's there's a point in which 957 00:33:23,590 --> 00:33:25,749 the Mac takes more time than 958 00:33:25,750 --> 00:33:27,039 it would before. There are different 959 00:33:27,040 --> 00:33:28,959 compression functions inside of it. 960 00:33:28,960 --> 00:33:31,689 And if you're at fifty five bytes, 961 00:33:31,690 --> 00:33:33,309 it's going to be faster than if you're at 962 00:33:33,310 --> 00:33:35,139 56 or 57. 963 00:33:35,140 --> 00:33:37,779 So if you 964 00:33:37,780 --> 00:33:40,239 this is an entire 64 byte message 965 00:33:40,240 --> 00:33:42,609 which is just aligned on a as 966 00:33:42,610 --> 00:33:44,739 blocks. And so what you can 967 00:33:44,740 --> 00:33:47,139 do is try to guess 968 00:33:47,140 --> 00:33:48,699 the padding and if you guess the padding 969 00:33:48,700 --> 00:33:50,679 wrong, it's going to be a slow hash. 970 00:33:50,680 --> 00:33:52,119 And if you guess the first body padding, 971 00:33:52,120 --> 00:33:54,369 right, it's going to be also slow. 972 00:33:54,370 --> 00:33:56,709 But if you get really lucky and guess 973 00:33:56,710 --> 00:33:59,109 the last two bites of padding correctly, 974 00:33:59,110 --> 00:34:01,539 it's going to be fast and 975 00:34:01,540 --> 00:34:03,699 voila, you're two steps into your Oracle 976 00:34:03,700 --> 00:34:05,619 attack and you can take this all the way 977 00:34:05,620 --> 00:34:08,559 down. So this this is found again 978 00:34:08,560 --> 00:34:10,119 this year, a couple of months ago in 979 00:34:10,120 --> 00:34:12,939 Amazon's new implementation 980 00:34:12,940 --> 00:34:15,249 as to when they created 981 00:34:15,250 --> 00:34:16,809 a tireless and full implementation from 982 00:34:16,810 --> 00:34:18,189 scratch, what could go wrong. 983 00:34:18,190 --> 00:34:20,259 And they tried to protect 984 00:34:20,260 --> 00:34:22,029 themselves from Lucky 13 and ended up 985 00:34:22,030 --> 00:34:22,928 having the same sort of thing. 986 00:34:22,929 --> 00:34:25,238 So if you look at it, there's this is 987 00:34:25,239 --> 00:34:27,189 a graph that a colleague of mine, Filipa, 988 00:34:27,190 --> 00:34:28,539 put together and trying to fix this. 989 00:34:28,540 --> 00:34:30,579 In goes Krypto Library, which 990 00:34:32,260 --> 00:34:34,479 sort of presciently 991 00:34:34,480 --> 00:34:36,549 Adam Langley, who wrote it, had a comment 992 00:34:36,550 --> 00:34:38,229 saying there's probably a timing side 993 00:34:38,230 --> 00:34:39,460 channel in this Mac. 994 00:34:40,630 --> 00:34:42,459 And it turned out that, yes, there was 995 00:34:42,460 --> 00:34:44,319 and that was lucky 13. 996 00:34:44,320 --> 00:34:45,320 So 997 00:34:47,830 --> 00:34:50,079 another really, really subtle thing that 998 00:34:50,080 --> 00:34:51,759 you would not have predicted in the 90s 999 00:34:51,760 --> 00:34:53,169 that came back to bite us. 1000 00:34:53,170 --> 00:34:55,238 And a really bad 1001 00:34:55,239 --> 00:34:56,349 thing about this is that 1002 00:34:57,850 --> 00:34:59,889 forty one point zero and one point two, 1003 00:34:59,890 --> 00:35:01,329 that was the only way to use block 1004 00:35:01,330 --> 00:35:03,189 ciphers is in CBC mode. 1005 00:35:03,190 --> 00:35:05,289 So unless you 1006 00:35:05,290 --> 00:35:07,599 have both servers, tell us one point two, 1007 00:35:07,600 --> 00:35:08,600 you're kind of screwed. 1008 00:35:09,700 --> 00:35:11,649 And that leads us to another idea, which 1009 00:35:11,650 --> 00:35:13,599 is the downgrade attack. 1010 00:35:13,600 --> 00:35:15,819 And the general philosophy around this 1011 00:35:15,820 --> 00:35:17,769 is that if you support something old, 1012 00:35:17,770 --> 00:35:19,329 someone's going to trick you into using 1013 00:35:19,330 --> 00:35:21,820 it and. 1014 00:35:23,160 --> 00:35:24,569 You know, there's ways to defend against 1015 00:35:24,570 --> 00:35:26,729 that, but it's really difficult 1016 00:35:26,730 --> 00:35:28,859 to get right as a 1017 00:35:28,860 --> 00:35:30,929 bit of a background that these 1018 00:35:30,930 --> 00:35:32,279 are cipher suites, right? 1019 00:35:32,280 --> 00:35:34,529 This is what SSL needs, all 1020 00:35:34,530 --> 00:35:36,059 these different things to this sort of 1021 00:35:36,060 --> 00:35:38,429 alphabet soup to decide on what crypto 1022 00:35:38,430 --> 00:35:40,619 algorithms to use and to break 1023 00:35:40,620 --> 00:35:41,639 it down. It's. 1024 00:35:43,230 --> 00:35:45,149 A key exchange certificate, key transport 1025 00:35:45,150 --> 00:35:47,699 cipher, and then an integrity function, 1026 00:35:47,700 --> 00:35:49,859 and the server gets a list 1027 00:35:49,860 --> 00:35:51,419 from the client and it sort of picks its 1028 00:35:51,420 --> 00:35:53,699 favorite from the list and then chooses 1029 00:35:53,700 --> 00:35:54,749 it. 1030 00:35:54,750 --> 00:35:57,119 And if anybody was over at 1031 00:35:57,120 --> 00:35:59,399 the next hall for the previous talk, 1032 00:35:59,400 --> 00:36:00,989 you'll know that there's something called 1033 00:36:00,990 --> 00:36:02,159 export cyphers. 1034 00:36:02,160 --> 00:36:03,719 And these were supported for a very long 1035 00:36:03,720 --> 00:36:05,969 time. And this is to comply with 1036 00:36:05,970 --> 00:36:08,129 this antiquated Nyos 1037 00:36:08,130 --> 00:36:09,989 crypto export law in the United States. 1038 00:36:09,990 --> 00:36:11,189 And these are really, really weak 1039 00:36:11,190 --> 00:36:12,119 ciphers. 1040 00:36:12,120 --> 00:36:14,549 So these were supported 1041 00:36:14,550 --> 00:36:16,259 by clients and servers all the way up 1042 00:36:16,260 --> 00:36:18,059 until this year. They still are. 1043 00:36:18,060 --> 00:36:20,189 And the fact that 1044 00:36:20,190 --> 00:36:21,839 the server will always pick the best one 1045 00:36:21,840 --> 00:36:24,029 of the client, everyone's safe, right? 1046 00:36:24,030 --> 00:36:25,859 The server will always pick the best one. 1047 00:36:25,860 --> 00:36:26,860 Turns out, no. 1048 00:36:28,290 --> 00:36:30,479 These are several attacks that 1049 00:36:30,480 --> 00:36:32,639 were described in the previous talk in 1050 00:36:32,640 --> 00:36:33,640 which. 1051 00:36:35,170 --> 00:36:37,239 You can end up forcing clients of servers 1052 00:36:37,240 --> 00:36:39,849 to use these really bad, crappy crypto, 1053 00:36:39,850 --> 00:36:42,129 and the reason is it boils down 1054 00:36:42,130 --> 00:36:44,079 to the only thing that's in this 1055 00:36:44,080 --> 00:36:46,359 handshake that's authenticated 1056 00:36:46,360 --> 00:36:48,759 is this key derivation 1057 00:36:48,760 --> 00:36:50,859 stuff. So the pieces that you use to 1058 00:36:50,860 --> 00:36:52,929 derive the shares, shared keys. 1059 00:36:52,930 --> 00:36:56,019 And so this is what Freekeh is. 1060 00:36:56,020 --> 00:36:58,149 If you sit in the middle, the client 1061 00:36:58,150 --> 00:36:59,559 is going to say, hey, these are the 1062 00:36:59,560 --> 00:37:00,639 ciphers I support. 1063 00:37:00,640 --> 00:37:02,799 You just change that list into, OK, I 1064 00:37:02,800 --> 00:37:04,779 only support export ciphers and then the 1065 00:37:04,780 --> 00:37:06,669 server say, OK, well, I support an export 1066 00:37:06,670 --> 00:37:08,289 cipher too. I guess we're gonna use this. 1067 00:37:08,290 --> 00:37:10,929 You must be an old client and 1068 00:37:10,930 --> 00:37:12,699 then all you have to do is crack that 1069 00:37:12,700 --> 00:37:14,949 export key, which is, you know, 40 bits 1070 00:37:14,950 --> 00:37:17,769 of encryption and and you're good. 1071 00:37:17,770 --> 00:37:19,839 Go from there or 1072 00:37:19,840 --> 00:37:21,579 in some cases that you have to crack a 1073 00:37:21,580 --> 00:37:24,069 512 bit RSA key, which is also 1074 00:37:24,070 --> 00:37:25,780 it's it's computationally doable. 1075 00:37:26,980 --> 00:37:29,199 The way that logjam works is very 1076 00:37:29,200 --> 00:37:30,200 similar. 1077 00:37:31,360 --> 00:37:32,949 This works with RSA Cipher Suites. 1078 00:37:32,950 --> 00:37:34,149 This works of Diffie home in cipher 1079 00:37:34,150 --> 00:37:36,729 suites. And this relies on the fact that 1080 00:37:36,730 --> 00:37:38,829 you can force the client and the server 1081 00:37:38,830 --> 00:37:41,199 to agree to use these 1082 00:37:41,200 --> 00:37:43,529 Halman parameters to 1083 00:37:43,530 --> 00:37:45,309 to Dukey Exchange that are weak, just old 1084 00:37:45,310 --> 00:37:47,499 crypto, small key sizes, 1085 00:37:47,500 --> 00:37:49,239 and you crack it. 1086 00:37:49,240 --> 00:37:51,579 And then as a man in the middle, you can 1087 00:37:51,580 --> 00:37:53,409 manipulate and read everything 1088 00:37:55,270 --> 00:37:57,159 we which is sort of the same thing. 1089 00:37:57,160 --> 00:37:59,109 It relies on the fact that some servers 1090 00:37:59,110 --> 00:38:01,239 use Diffie Helmund parameters 1091 00:38:01,240 --> 00:38:03,579 that were pre computed and you can go 1092 00:38:03,580 --> 00:38:05,859 kind of three quarters of the way 1093 00:38:05,860 --> 00:38:07,779 through the attack because they're all 1094 00:38:07,780 --> 00:38:10,359 using the same Apache shared prime 1095 00:38:10,360 --> 00:38:12,429 for this stiffy home and stuff. 1096 00:38:12,430 --> 00:38:14,439 So this relies on unauthenticated 1097 00:38:14,440 --> 00:38:15,639 protocol in the handshake. 1098 00:38:15,640 --> 00:38:16,640 More on this to come 1099 00:38:18,310 --> 00:38:20,769 in in the 1100 00:38:20,770 --> 00:38:23,019 the theme of downgrade attacks 1101 00:38:23,020 --> 00:38:24,069 poodle. 1102 00:38:24,070 --> 00:38:26,409 This turned out to be the nail 1103 00:38:26,410 --> 00:38:27,940 in the coffin for SLV three. 1104 00:38:29,770 --> 00:38:31,689 You can do this thing called the 1105 00:38:31,690 --> 00:38:34,029 downgrade dance. You can force browser's 1106 00:38:34,030 --> 00:38:36,309 to to negotiate down 1107 00:38:36,310 --> 00:38:38,559 from SSL from tearless 1108 00:38:38,560 --> 00:38:40,719 one point two to one point one to SSL 1109 00:38:40,720 --> 00:38:43,239 to 1.0, Tharsis all three. 1110 00:38:43,240 --> 00:38:45,429 And as I mentioned before, 1111 00:38:45,430 --> 00:38:47,709 the padding in SSL three is just a bunch 1112 00:38:47,710 --> 00:38:49,749 of X's and then a number, so you can fill 1113 00:38:49,750 --> 00:38:51,879 it in with anything. So if you align your 1114 00:38:51,880 --> 00:38:54,039 blocks so that the last block only 1115 00:38:54,040 --> 00:38:56,109 has one relevant bit of data, you can do 1116 00:38:56,110 --> 00:38:57,110 a panic attack. 1117 00:38:58,170 --> 00:39:00,299 And this 1118 00:39:00,300 --> 00:39:01,559 when people came up with this, they were 1119 00:39:01,560 --> 00:39:02,979 just like. 1120 00:39:02,980 --> 00:39:05,079 Obvious, obviously, we can do this, 1121 00:39:05,080 --> 00:39:07,269 this is terrible and SASE three is 1122 00:39:07,270 --> 00:39:08,270 completely broken 1123 00:39:09,400 --> 00:39:12,219 US poodle, it turns out that 1124 00:39:12,220 --> 00:39:13,689 I mentioned there's one change between 1125 00:39:13,690 --> 00:39:15,819 acetone and tell us one one one. 1126 00:39:15,820 --> 00:39:17,469 One of the major changes is that that 1127 00:39:17,470 --> 00:39:19,509 padding had to be defined as repeat the 1128 00:39:19,510 --> 00:39:20,709 same padding value. 1129 00:39:20,710 --> 00:39:22,569 Well, some servers didn't do that. 1130 00:39:22,570 --> 00:39:24,729 So you can end 1131 00:39:24,730 --> 00:39:27,229 up doing the same attack in several 1132 00:39:27,230 --> 00:39:28,749 large percentage of websites are still 1133 00:39:28,750 --> 00:39:30,949 susceptible to deloused poodle. 1134 00:39:30,950 --> 00:39:33,190 Another threat to tell us Agent Cryptome. 1135 00:39:35,220 --> 00:39:37,299 Yeah, I mean, he's he's 1136 00:39:37,300 --> 00:39:38,300 still doing well. 1137 00:39:39,010 --> 00:39:41,259 But this 1138 00:39:41,260 --> 00:39:43,779 is sort of in the news now with with 1139 00:39:43,780 --> 00:39:45,489 different signature algorithms based on 1140 00:39:45,490 --> 00:39:46,719 hash functions. 1141 00:39:46,720 --> 00:39:48,759 This was presented back here at C.C.C. 1142 00:39:48,760 --> 00:39:50,739 in 2000, 2008. 1143 00:39:50,740 --> 00:39:52,360 Some researchers were able to 1144 00:39:53,440 --> 00:39:55,809 forge one certificate from another 1145 00:39:55,810 --> 00:39:57,969 by finding a collision in 1146 00:39:57,970 --> 00:39:59,379 this hash function that you use in the 1147 00:39:59,380 --> 00:40:01,269 signature. But this is kind of the 1148 00:40:01,270 --> 00:40:03,369 details of it's a little complicated, but 1149 00:40:03,370 --> 00:40:04,869 they were able to make themselves a 1150 00:40:04,870 --> 00:40:07,179 trusted certificate authority and issue 1151 00:40:07,180 --> 00:40:08,229 certificates for everything. 1152 00:40:08,230 --> 00:40:10,899 And from that point onwards, 95, 1153 00:40:10,900 --> 00:40:13,029 this is an old hash function, had to be 1154 00:40:13,030 --> 00:40:15,009 kind of booted from everything. 1155 00:40:15,010 --> 00:40:16,839 So how how do all these attacks fit on 1156 00:40:16,840 --> 00:40:18,759 the timeline? This is our test timeline. 1157 00:40:18,760 --> 00:40:21,129 As I mentioned, these 1158 00:40:21,130 --> 00:40:23,229 are the major attacks that I that I 1159 00:40:23,230 --> 00:40:24,459 mentioned and they were really 1160 00:40:24,460 --> 00:40:26,589 concentrated pastilla at one point two. 1161 00:40:26,590 --> 00:40:29,079 And this beast, 1162 00:40:29,080 --> 00:40:31,209 I didn't go into this, but this is the 1163 00:40:31,210 --> 00:40:32,889 first one of the back rooms. 1164 00:40:32,890 --> 00:40:34,989 So attacks 1165 00:40:34,990 --> 00:40:37,599 that you've I forget Browsr 1166 00:40:37,600 --> 00:40:40,029 something something something that you 1167 00:40:40,030 --> 00:40:42,219 take a nice word and you make an attack 1168 00:40:42,220 --> 00:40:43,239 name out of it. But 1169 00:40:44,560 --> 00:40:46,209 down around Heartbleed, this is when the 1170 00:40:46,210 --> 00:40:47,199 logo trend happened. 1171 00:40:47,200 --> 00:40:48,729 So every vulnerability had to have a 1172 00:40:48,730 --> 00:40:50,859 logo. And there's a really 1173 00:40:50,860 --> 00:40:53,319 high concentration of these things 1174 00:40:53,320 --> 00:40:54,879 around the last three or four years. 1175 00:40:56,470 --> 00:40:58,059 So as I mentioned, if you can look here, 1176 00:40:58,060 --> 00:41:01,189 tell us one point to that was 2008, 1177 00:41:01,190 --> 00:41:02,079 2012. 1178 00:41:02,080 --> 00:41:03,080 Nobody was using it. 1179 00:41:04,330 --> 00:41:05,979 This is from SSL Pulse. 1180 00:41:05,980 --> 00:41:08,379 Even 2014 1181 00:41:08,380 --> 00:41:10,749 SSL V3 was supported almost universally. 1182 00:41:10,750 --> 00:41:12,729 Now we're in a slightly better position, 1183 00:41:12,730 --> 00:41:14,199 but it takes a really long time for 1184 00:41:14,200 --> 00:41:15,549 service to upgrade. 1185 00:41:15,550 --> 00:41:17,829 And same thing for clients. 1186 00:41:17,830 --> 00:41:20,109 Right now we're seeing something 1187 00:41:20,110 --> 00:41:22,179 around 75 percent of connections to 1188 00:41:22,180 --> 00:41:23,199 one point two, which is great. 1189 00:41:24,430 --> 00:41:26,529 But you can clap for that if 1190 00:41:26,530 --> 00:41:28,569 you want. But tell us one point two 1191 00:41:28,570 --> 00:41:30,249 solves most of most of these problems. 1192 00:41:30,250 --> 00:41:32,349 But most of these browsers, 1193 00:41:32,350 --> 00:41:35,379 they came out in 2003, 2004, 1194 00:41:35,380 --> 00:41:37,389 that it was at least five years later. 1195 00:41:37,390 --> 00:41:39,549 So it 1196 00:41:39,550 --> 00:41:41,439 takes a while for things to get up to 1197 00:41:41,440 --> 00:41:42,440 date. 1198 00:41:43,280 --> 00:41:44,280 Now, 1199 00:41:45,980 --> 00:41:47,449 this is this kind of paints a grim 1200 00:41:47,450 --> 00:41:49,939 picture for these old vulnerabilities, 1201 00:41:49,940 --> 00:41:52,129 but at least from the ones 1202 00:41:52,130 --> 00:41:54,079 that we've seen, we can learn a few 1203 00:41:54,080 --> 00:41:55,399 lessons. 1204 00:41:55,400 --> 00:41:57,319 And one is that if an attacker can 1205 00:41:57,320 --> 00:41:59,299 identify one bit of information about the 1206 00:41:59,300 --> 00:42:01,999 plaintext, then it's basically over 1207 00:42:02,000 --> 00:42:03,799 the way that works. 1208 00:42:03,800 --> 00:42:05,809 Repeated data can be sent and you can 1209 00:42:05,810 --> 00:42:07,399 take that one bit and expand it to an 1210 00:42:07,400 --> 00:42:08,400 entire message. 1211 00:42:09,260 --> 00:42:11,419 There are side channels everywhere, 1212 00:42:11,420 --> 00:42:13,309 timing side channels, computing side 1213 00:42:13,310 --> 00:42:16,159 channels. There's been research about 1214 00:42:16,160 --> 00:42:18,349 working on in the cloud 1215 00:42:18,350 --> 00:42:20,479 computing if you are able to 1216 00:42:20,480 --> 00:42:21,649 do cash timing. 1217 00:42:21,650 --> 00:42:23,209 So if you're running one process and 1218 00:42:23,210 --> 00:42:24,259 there's crypto hopping on another 1219 00:42:24,260 --> 00:42:26,359 process, you can find out how long 1220 00:42:26,360 --> 00:42:28,219 things are taking. This is incredibly 1221 00:42:28,220 --> 00:42:29,220 dangerous. 1222 00:42:30,580 --> 00:42:32,439 Almost all the things I mentioned having 1223 00:42:32,440 --> 00:42:33,440 to do with 1224 00:42:34,600 --> 00:42:37,209 Oracle's relied on unauthenticated 1225 00:42:37,210 --> 00:42:39,309 data and having 1226 00:42:39,310 --> 00:42:41,499 unauthenticated data, doing Mac first 1227 00:42:41,500 --> 00:42:43,149 and then encrypt, leaving, even patting 1228 00:42:43,150 --> 00:42:45,399 Padang is incredibly important 1229 00:42:45,400 --> 00:42:47,709 and verify and checking it correctly 1230 00:42:47,710 --> 00:42:49,479 is is incredibly hard. 1231 00:42:49,480 --> 00:42:51,399 It turns out we've messed it up so many 1232 00:42:51,400 --> 00:42:52,400 times, but 1233 00:42:53,470 --> 00:42:55,659 adds this is authenticated 1234 00:42:55,660 --> 00:42:57,129 encryption with additional data. 1235 00:42:57,130 --> 00:42:58,599 This is a construction that was 1236 00:42:58,600 --> 00:43:00,819 introduced into us at one point to 1237 00:43:00,820 --> 00:43:03,519 Ascham is sort of the most popular 1238 00:43:03,520 --> 00:43:04,779 version of that. 1239 00:43:04,780 --> 00:43:06,909 We should definitely use those and just 1240 00:43:06,910 --> 00:43:08,139 drop CBC altogether. 1241 00:43:08,140 --> 00:43:10,269 CBC is just a really, really 1242 00:43:10,270 --> 00:43:13,209 difficult, scrappy construction 1243 00:43:13,210 --> 00:43:15,279 that hasn't serviced it sort of served us 1244 00:43:15,280 --> 00:43:17,259 well to now. But it's there's there's 1245 00:43:17,260 --> 00:43:18,879 many ways to attack it and there will be 1246 00:43:18,880 --> 00:43:20,440 many ways to attack it in the future. 1247 00:43:21,640 --> 00:43:22,929 Five or nine, the structure for 1248 00:43:22,930 --> 00:43:25,449 certificate's, which is Ascencion, 1249 00:43:25,450 --> 00:43:27,309 these are really incredibly hard to 1250 00:43:27,310 --> 00:43:28,689 implement correctly. 1251 00:43:28,690 --> 00:43:30,129 There are at least nine years older than 1252 00:43:30,130 --> 00:43:32,829 SSL itself, these protocols 1253 00:43:32,830 --> 00:43:33,830 and. 1254 00:43:35,500 --> 00:43:36,969 They're going to cause you problems using 1255 00:43:36,970 --> 00:43:38,020 this and 1256 00:43:39,580 --> 00:43:41,439 as for downgrade attacks, you know, 1257 00:43:41,440 --> 00:43:43,389 support and secure crypto or protocols 1258 00:43:44,530 --> 00:43:46,629 at your own risk, because 1259 00:43:46,630 --> 00:43:49,449 people will be able to somehow downgrade 1260 00:43:49,450 --> 00:43:50,979 you to using them. 1261 00:43:50,980 --> 00:43:53,169 So I skipped a lot of issues here 1262 00:43:54,640 --> 00:43:56,439 that had tons, tons more issues. 1263 00:43:56,440 --> 00:43:58,659 I mean, Beast, this is the RSA decryption 1264 00:43:58,660 --> 00:44:00,789 Oracle ass channel, had a remote code 1265 00:44:00,790 --> 00:44:03,339 execution bug a few months ago. 1266 00:44:03,340 --> 00:44:05,409 Triple handshake had to 1267 00:44:05,410 --> 00:44:06,669 do. I didn't even mention client 1268 00:44:06,670 --> 00:44:09,099 authentication and how broken that is. 1269 00:44:09,100 --> 00:44:11,349 The whole ecosystem and cert 1270 00:44:11,350 --> 00:44:13,329 authorities messing up when it comes to 1271 00:44:13,330 --> 00:44:15,489 issuing certificates didn't even go into 1272 00:44:15,490 --> 00:44:17,639 that RC for weaknesses yet. 1273 00:44:17,640 --> 00:44:19,239 Apparently the stream cipher 1274 00:44:20,560 --> 00:44:22,659 Patterson around the same time is 1275 00:44:22,660 --> 00:44:24,489 lucky. 13 found you can decrypt an entire 1276 00:44:24,490 --> 00:44:26,679 RSA, an entire Teela stream 1277 00:44:26,680 --> 00:44:28,929 if you use RC for 1278 00:44:28,930 --> 00:44:31,329 their vulnerabilities and big numbers. 1279 00:44:31,330 --> 00:44:33,789 There's issues with forward secrecy. 1280 00:44:33,790 --> 00:44:36,159 Tlas is just absolutely loaded 1281 00:44:36,160 --> 00:44:37,989 with problems from everything from the 1282 00:44:37,990 --> 00:44:40,299 implementation side to the protocol 1283 00:44:40,300 --> 00:44:41,300 itself. 1284 00:44:42,160 --> 00:44:44,409 So just enough complexity to hang 1285 00:44:44,410 --> 00:44:45,410 yourself with. 1286 00:44:46,720 --> 00:44:48,219 Now, I would say this is the end of the 1287 00:44:48,220 --> 00:44:51,279 talk, but there's just one more thing 1288 00:44:51,280 --> 00:44:53,859 I'd like to just 1289 00:44:53,860 --> 00:44:56,079 as a thought experiment, go into some 1290 00:44:56,080 --> 00:44:58,239 other attacks that follow up 1291 00:44:58,240 --> 00:45:00,549 what we saw in the last room. 1292 00:45:00,550 --> 00:45:02,709 So there's other negotiations that happen 1293 00:45:02,710 --> 00:45:05,079 within Tlas as. 1294 00:45:06,520 --> 00:45:08,079 As we talked about with Freekeh and with 1295 00:45:08,080 --> 00:45:10,149 logjam, it's, hey, which 1296 00:45:10,150 --> 00:45:12,129 Diffie Helmond group do we choose or 1297 00:45:12,130 --> 00:45:14,049 which Sefer do we choose? 1298 00:45:14,050 --> 00:45:15,699 There's also some other negotiations that 1299 00:45:15,700 --> 00:45:17,859 happens. There's NPN and Alpen. 1300 00:45:17,860 --> 00:45:19,569 These are protocols that allow you to 1301 00:45:19,570 --> 00:45:21,069 upgrade, to be to. 1302 00:45:21,070 --> 00:45:22,899 And then there's which which elliptic 1303 00:45:22,900 --> 00:45:23,900 curves do I support. 1304 00:45:25,550 --> 00:45:27,080 This is really interesting, actually, 1305 00:45:28,320 --> 00:45:30,529 tell us supports a ton of 1306 00:45:30,530 --> 00:45:33,080 kind of crazy elliptic curves and 1307 00:45:34,400 --> 00:45:36,229 what if you did a downgrade attack on 1308 00:45:36,230 --> 00:45:37,249 that? 1309 00:45:37,250 --> 00:45:39,469 So this is a new kind of Tlas 1310 00:45:39,470 --> 00:45:40,789 vulnerability introducing called Kolff 1311 00:45:40,790 --> 00:45:43,099 Swap. So this follows 1312 00:45:43,100 --> 00:45:45,229 the exact same model is freekeh and log 1313 00:45:45,230 --> 00:45:46,249 jam. 1314 00:45:46,250 --> 00:45:48,349 And what you do in 1315 00:45:48,350 --> 00:45:50,509 a man in the middle position is you 1316 00:45:50,510 --> 00:45:52,609 take the supported cyphers 1317 00:45:52,610 --> 00:45:54,799 and you swap it with 1318 00:45:54,800 --> 00:45:57,079 the smallest, weakest possible curves 1319 00:45:57,080 --> 00:45:58,999 supported by both parties. 1320 00:45:59,000 --> 00:46:01,669 And you put in make sure that it's 1321 00:46:01,670 --> 00:46:03,919 a curve that sorry, 1322 00:46:03,920 --> 00:46:06,019 I elliptic curve diffie hulman for 1323 00:46:06,020 --> 00:46:07,759 key exchange so that both parties are 1324 00:46:07,760 --> 00:46:10,009 going to be using these kind of smaller 1325 00:46:10,010 --> 00:46:12,739 curves to derive their keys. 1326 00:46:12,740 --> 00:46:14,079 Step two is this one. 1327 00:46:15,260 --> 00:46:15,949 Bear with me. 1328 00:46:15,950 --> 00:46:17,449 Really, we don't know how to do this one 1329 00:46:17,450 --> 00:46:19,280 yet, but solve this great log problem. 1330 00:46:21,200 --> 00:46:22,399 So OK. 1331 00:46:22,400 --> 00:46:24,469 Yeah, yes. That's something that's 1332 00:46:24,470 --> 00:46:26,509 not really doable right now. 1333 00:46:26,510 --> 00:46:28,609 But on small curves, it might 1334 00:46:28,610 --> 00:46:30,799 be. So before we go into 1335 00:46:30,800 --> 00:46:33,109 that, let's just think about 1336 00:46:33,110 --> 00:46:34,969 what curves are supported and tell us 1337 00:46:34,970 --> 00:46:36,949 there's there's some curves here called 1338 00:46:36,950 --> 00:46:38,779 the curves, and this is 1339 00:46:39,950 --> 00:46:42,170 one hundred and sixty three bit curve. 1340 00:46:43,620 --> 00:46:45,899 Over, it's a binary curve, this is 1341 00:46:45,900 --> 00:46:47,789 this is this is not the type of curve 1342 00:46:47,790 --> 00:46:49,739 that we typically use, but when elliptic 1343 00:46:49,740 --> 00:46:51,089 curves were originally standardized for 1344 00:46:51,090 --> 00:46:52,709 class, it was all the rage. 1345 00:46:52,710 --> 00:46:54,269 We had prime curves, we had binary 1346 00:46:54,270 --> 00:46:56,069 curves. They were both kind of 1347 00:46:56,070 --> 00:46:58,169 equivalent. And if you look 1348 00:46:58,170 --> 00:47:00,569 at the data and I did a survey of 1349 00:47:00,570 --> 00:47:02,879 a lot of client hello's, 1350 00:47:02,880 --> 00:47:04,659 four point three percent of client 1351 00:47:04,660 --> 00:47:06,719 support this kind 1352 00:47:06,720 --> 00:47:07,739 of week curve. 1353 00:47:07,740 --> 00:47:09,869 And this is this is about as strong 1354 00:47:09,870 --> 00:47:12,539 as I think equivalent to RSA 1355 00:47:12,540 --> 00:47:13,540 10 24. 1356 00:47:14,780 --> 00:47:17,209 So even though 1357 00:47:17,210 --> 00:47:19,279 when you're doing a negotiation, you 1358 00:47:19,280 --> 00:47:20,719 expect to be using a really strong 1359 00:47:20,720 --> 00:47:22,909 elliptic curve, like a 256 bit one 1360 00:47:22,910 --> 00:47:24,979 for their key exchange, the men 1361 00:47:24,980 --> 00:47:26,510 in the middle can downgrade you to 1362 00:47:28,310 --> 00:47:30,499 this nice smaller curve. 1363 00:47:30,500 --> 00:47:32,569 And if as an attacker, you 1364 00:47:32,570 --> 00:47:34,669 can break the discrete logarithm problem 1365 00:47:34,670 --> 00:47:37,009 on this curve, then for 1366 00:47:37,010 --> 00:47:39,149 the Aleksa top 100, one point two 1367 00:47:39,150 --> 00:47:41,069 point one three percent of sites. 1368 00:47:41,070 --> 00:47:43,309 Yeah, you can you can make 1369 00:47:43,310 --> 00:47:45,469 them both use this really 1370 00:47:45,470 --> 00:47:47,689 kind of crappy curve for key 1371 00:47:47,690 --> 00:47:48,589 establishment. 1372 00:47:48,590 --> 00:47:50,689 But as I sort of as you guys 1373 00:47:50,690 --> 00:47:53,299 have alluded to and you're chuckling, 1374 00:47:53,300 --> 00:47:55,459 nobody's really broken DLP for any curves 1375 00:47:55,460 --> 00:47:56,809 around the size. 1376 00:47:56,810 --> 00:47:58,249 The sort of largest curve that's been 1377 00:47:58,250 --> 00:48:01,009 broken is 110 bits or so. 1378 00:48:01,010 --> 00:48:03,139 But there's a reason we don't 1379 00:48:03,140 --> 00:48:04,309 use binary curves anymore. 1380 00:48:04,310 --> 00:48:05,599 They've kind of gone out of style. 1381 00:48:06,860 --> 00:48:09,079 There are index calculus 1382 00:48:09,080 --> 00:48:11,239 techniques that are supposedly better 1383 00:48:11,240 --> 00:48:13,309 than brute brute force 1384 00:48:13,310 --> 00:48:14,479 on these on binary curves. 1385 00:48:14,480 --> 00:48:16,249 So people consider them weak. 1386 00:48:16,250 --> 00:48:18,379 And we're not sure what kind of 1387 00:48:18,380 --> 00:48:20,629 research has been done in private 1388 00:48:20,630 --> 00:48:22,759 about, say, binary curves. 1389 00:48:22,760 --> 00:48:23,760 So just. 1390 00:48:25,400 --> 00:48:27,469 The good news about this is 1391 00:48:27,470 --> 00:48:29,629 that in twenty one point 1392 00:48:29,630 --> 00:48:31,579 three, the new standard, all these curves 1393 00:48:31,580 --> 00:48:33,679 have been excised. So and there's 1394 00:48:33,680 --> 00:48:35,389 a lot of these bugs have been kind of 1395 00:48:35,390 --> 00:48:37,549 removed from the protocol itself. 1396 00:48:37,550 --> 00:48:39,739 But it's been a long and rocky 1397 00:48:39,740 --> 00:48:42,649 road for transport layer security, 1398 00:48:42,650 --> 00:48:43,650 and that's the end. 1399 00:48:55,130 --> 00:48:57,289 And before we start the Q&A, just a quick 1400 00:48:57,290 --> 00:48:59,149 announcement, if you hear from me today 1401 00:48:59,150 --> 00:49:00,139 is incorrect. 1402 00:49:00,140 --> 00:49:01,999 It switched to astrology. 1403 00:49:02,000 --> 00:49:03,769 So you should go there if you want to see 1404 00:49:03,770 --> 00:49:05,899 if there's going to be a stream in 1405 00:49:05,900 --> 00:49:07,759 this room. But if you want to be there in 1406 00:49:07,760 --> 00:49:10,339 person, you should go there. 1407 00:49:10,340 --> 00:49:12,649 I will give you, let's say, 30 1408 00:49:12,650 --> 00:49:13,650 seconds to leave 1409 00:49:15,440 --> 00:49:17,149 and then please be quiet because we want 1410 00:49:17,150 --> 00:49:18,320 to do Q&A properly. 1411 00:49:19,640 --> 00:49:20,809 You can use the time to think of 1412 00:49:20,810 --> 00:49:23,689 questions. We have lots of mikes 1413 00:49:23,690 --> 00:49:25,759 to two there, one there, 1414 00:49:25,760 --> 00:49:28,159 one on top and on the other side, too. 1415 00:49:28,160 --> 00:49:30,949 And also for you on the ISC, on Twitter, 1416 00:49:30,950 --> 00:49:31,939 ask questions. 1417 00:49:31,940 --> 00:49:33,919 We have a signal angel that will read out 1418 00:49:33,920 --> 00:49:35,389 your questions for us. 1419 00:49:41,500 --> 00:49:43,689 OK, let's start at number one, 1420 00:49:43,690 --> 00:49:45,309 please, I 1421 00:49:46,360 --> 00:49:48,669 could you say something about 1422 00:49:48,670 --> 00:49:51,189 CloudFlare secretary 1423 00:49:51,190 --> 00:49:53,889 to not face or 1424 00:49:53,890 --> 00:49:56,229 Wharton School 1425 00:49:56,230 --> 00:49:57,429 and the others? 1426 00:49:59,230 --> 00:50:00,230 Yeah, I'd love to. 1427 00:50:01,100 --> 00:50:02,100 So. 1428 00:50:04,240 --> 00:50:07,509 As with any one of these protocols or 1429 00:50:07,510 --> 00:50:10,449 types of crypto that 1430 00:50:10,450 --> 00:50:12,789 are broken or old, 1431 00:50:12,790 --> 00:50:15,159 once they're definitively broken or old, 1432 00:50:15,160 --> 00:50:16,669 they should be completely excised. 1433 00:50:16,670 --> 00:50:18,849 So there's been a plan to 1434 00:50:18,850 --> 00:50:20,949 sunset SHA one, let's 1435 00:50:20,950 --> 00:50:23,169 say, by the end of 2000, by the 1436 00:50:23,170 --> 00:50:24,399 beginning of twenty seventeen. 1437 00:50:24,400 --> 00:50:25,869 So the end of next year. 1438 00:50:25,870 --> 00:50:28,209 And the timing 1439 00:50:28,210 --> 00:50:30,369 on which this this is to happen 1440 00:50:30,370 --> 00:50:32,769 is, is sort of debatable. 1441 00:50:32,770 --> 00:50:33,770 And 1442 00:50:35,180 --> 00:50:37,929 there's there's really question about 1443 00:50:37,930 --> 00:50:40,179 whether or not short 1444 00:50:40,180 --> 00:50:42,549 one is something that 1445 00:50:42,550 --> 00:50:44,709 is a credible threat 1446 00:50:44,710 --> 00:50:46,929 to happen within the next year or not, 1447 00:50:46,930 --> 00:50:48,819 or whether it's a credible threat to 1448 00:50:48,820 --> 00:50:50,499 happen within the next five years in 1449 00:50:50,500 --> 00:50:52,299 terms of forging a certificate. 1450 00:50:52,300 --> 00:50:53,300 So. 1451 00:50:54,420 --> 00:50:56,489 Whether or not you should continue to 1452 00:50:56,490 --> 00:50:59,399 issue Shaalan certificates or not, it's 1453 00:50:59,400 --> 00:51:01,649 really something that. 1454 00:51:03,260 --> 00:51:05,269 It's a big debate that's going on right 1455 00:51:05,270 --> 00:51:06,270 now. 1456 00:51:10,560 --> 00:51:12,929 But if you compare to MI 1457 00:51:12,930 --> 00:51:14,999 five now we 1458 00:51:15,000 --> 00:51:17,609 have precent collisions, 1459 00:51:17,610 --> 00:51:19,949 right? And it took 1460 00:51:19,950 --> 00:51:20,950 two years. 1461 00:51:24,270 --> 00:51:25,649 So one thing to keep in mind in this 1462 00:51:25,650 --> 00:51:27,959 case, and I can go back to the slide 1463 00:51:27,960 --> 00:51:30,329 about the 2005 collision, is that 1464 00:51:30,330 --> 00:51:32,339 having a collision in Szechwan is not 1465 00:51:32,340 --> 00:51:34,559 enough to forge a certificate. 1466 00:51:34,560 --> 00:51:36,629 Where you have to do is actually get the 1467 00:51:36,630 --> 00:51:39,689 CI itself to to predict 1468 00:51:39,690 --> 00:51:42,029 a certificate that's created by the CIA 1469 00:51:42,030 --> 00:51:43,559 that aligns perfectly with the 1470 00:51:43,560 --> 00:51:45,369 certificate that you want to forge. 1471 00:51:45,370 --> 00:51:47,189 And there are some techniques like 1472 00:51:47,190 --> 00:51:49,439 putting randomness entropy into 1473 00:51:49,440 --> 00:51:51,149 the serial number that can help defend 1474 00:51:51,150 --> 00:51:52,290 against that. But 1475 00:51:53,370 --> 00:51:55,049 yes, there's a Freestar collision. 1476 00:51:55,050 --> 00:51:56,699 I don't know. It could be it could be 1477 00:51:56,700 --> 00:51:58,439 within the next month that we see a real 1478 00:51:58,440 --> 00:51:59,669 Shomron collision. 1479 00:51:59,670 --> 00:52:01,829 But in terms of colliding certificates, 1480 00:52:01,830 --> 00:52:03,539 that's somewhat of a different story. 1481 00:52:05,340 --> 00:52:06,619 Internet, please. 1482 00:52:07,680 --> 00:52:09,779 Thank you. Do you think we would be in 1483 00:52:09,780 --> 00:52:12,209 a better shape today if we 1484 00:52:12,210 --> 00:52:15,179 had won the race over https? 1485 00:52:15,180 --> 00:52:17,009 And why have we not moved to something 1486 00:52:17,010 --> 00:52:19,109 like Specky 1487 00:52:19,110 --> 00:52:21,719 SDI or any other alternative 1488 00:52:21,720 --> 00:52:22,720 to Picardie? 1489 00:52:24,030 --> 00:52:26,519 Well, as 1490 00:52:26,520 --> 00:52:28,589 speaking as as part of CloudFlare, 1491 00:52:28,590 --> 00:52:30,659 we control one side of the equation. 1492 00:52:30,660 --> 00:52:32,939 And as with any secure security 1493 00:52:32,940 --> 00:52:34,799 protocol, you need both the client and 1494 00:52:34,800 --> 00:52:36,869 the server to agree 1495 00:52:36,870 --> 00:52:38,129 on what they're going to use. 1496 00:52:38,130 --> 00:52:40,169 So the evolution of the entire 1497 00:52:40,170 --> 00:52:41,489 marketplace determines 1498 00:52:42,630 --> 00:52:44,639 which algorithms or which protocols 1499 00:52:44,640 --> 00:52:47,309 you're going to use and ended up winning 1500 00:52:47,310 --> 00:52:49,019 over the long term because it was most 1501 00:52:49,020 --> 00:52:50,129 widely supported. 1502 00:52:50,130 --> 00:52:52,229 And as with any of 1503 00:52:52,230 --> 00:52:53,729 these things, it's kind of a winner take 1504 00:52:53,730 --> 00:52:54,730 all. 1505 00:52:57,500 --> 00:52:59,010 Number three, please. 1506 00:53:00,110 --> 00:53:01,110 Yes, hi. 1507 00:53:01,850 --> 00:53:04,609 We clearly suck at implementing 1508 00:53:04,610 --> 00:53:07,549 protocols, right, so we need to 1509 00:53:07,550 --> 00:53:10,669 be able to upgrade stuff relatively 1510 00:53:10,670 --> 00:53:12,799 relatively rapidly because we will break 1511 00:53:12,800 --> 00:53:13,999 it again and again and again. 1512 00:53:14,000 --> 00:53:15,469 We'll need to upgrade. 1513 00:53:15,470 --> 00:53:17,659 Upgrading browsers is hard, like I 1514 00:53:17,660 --> 00:53:18,859 actually have to take. And that would be 1515 00:53:18,860 --> 00:53:20,779 a snapshot before the upgrade my browser, 1516 00:53:20,780 --> 00:53:21,919 because I really don't know what's going 1517 00:53:21,920 --> 00:53:22,920 to break. 1518 00:53:23,300 --> 00:53:25,489 Why isn't any 1519 00:53:25,490 --> 00:53:28,109 of the browsers going there out of 1520 00:53:28,110 --> 00:53:30,229 OPG where basically data is 1521 00:53:30,230 --> 00:53:32,179 a completely separate piece of software 1522 00:53:32,180 --> 00:53:33,409 running in a separate process, 1523 00:53:33,410 --> 00:53:35,359 communicating over the sender and send it 1524 00:53:35,360 --> 00:53:37,429 out and it's upgradable without touching 1525 00:53:37,430 --> 00:53:38,599 any of the other system? 1526 00:53:38,600 --> 00:53:39,600 Thank you. 1527 00:53:40,190 --> 00:53:42,629 So the question is extracting 1528 00:53:42,630 --> 00:53:44,719 Tlas from the browser itself and putting 1529 00:53:44,720 --> 00:53:46,039 it somewhere else. 1530 00:53:46,040 --> 00:53:48,259 So one of the interesting 1531 00:53:48,260 --> 00:53:50,449 things that has happened 1532 00:53:50,450 --> 00:53:52,819 in the US, the ecosystem, 1533 00:53:52,820 --> 00:53:54,949 is that many of the browsers are 1534 00:53:54,950 --> 00:53:56,839 actually doing that for the cert 1535 00:53:56,840 --> 00:53:58,399 validation. They're outsourcing that to 1536 00:53:58,400 --> 00:53:59,909 the operating system itself. 1537 00:53:59,910 --> 00:54:01,909 Firefox is one of the lone exceptions 1538 00:54:01,910 --> 00:54:04,340 that has their entire PCI stack. 1539 00:54:07,550 --> 00:54:09,679 I think it's historical reasons, 1540 00:54:09,680 --> 00:54:11,749 really. I mean, Chrome 1541 00:54:11,750 --> 00:54:13,519 and Firefox auto updates. 1542 00:54:13,520 --> 00:54:15,769 And they do so because 1543 00:54:15,770 --> 00:54:17,269 they want to make sure that you have the 1544 00:54:17,270 --> 00:54:19,639 latest and greatest things not. 1545 00:54:19,640 --> 00:54:22,099 They have kind of taken the approach that 1546 00:54:22,100 --> 00:54:24,859 if your browser upgrades and it breaks 1547 00:54:24,860 --> 00:54:27,109 too bad for you, it's we know better. 1548 00:54:27,110 --> 00:54:28,669 And that's that's sort of that's their 1549 00:54:28,670 --> 00:54:29,670 strategy. So 1550 00:54:31,640 --> 00:54:34,219 I'm not a browser vendor. 1551 00:54:34,220 --> 00:54:35,569 I don't work for one of those companies, 1552 00:54:35,570 --> 00:54:37,639 so I can't really speak to what 1553 00:54:37,640 --> 00:54:38,640 they want to do. 1554 00:54:40,210 --> 00:54:42,459 Number two, thank 1555 00:54:42,460 --> 00:54:43,539 you. 1556 00:54:43,540 --> 00:54:45,579 You mentioned the defense in depth 1557 00:54:45,580 --> 00:54:47,649 approach of separating the private 1558 00:54:47,650 --> 00:54:49,089 key from the Web server. 1559 00:54:49,090 --> 00:54:50,739 Now, I know that CloudFlare offers key 1560 00:54:50,740 --> 00:54:53,679 lessons as well, which I really like. 1561 00:54:53,680 --> 00:54:55,719 Do you think that instead of just being a 1562 00:54:55,720 --> 00:54:57,489 business advantage to you, this could be 1563 00:54:57,490 --> 00:54:59,619 a realistic security 1564 00:54:59,620 --> 00:55:01,839 measure for many websites that they 1565 00:55:01,840 --> 00:55:03,789 separate their private key to something 1566 00:55:03,790 --> 00:55:06,159 behind a separate layer 1567 00:55:06,160 --> 00:55:07,160 of classicism? 1568 00:55:08,500 --> 00:55:10,089 Yeah, I think this is this is something 1569 00:55:10,090 --> 00:55:12,909 that could be more generally applicable. 1570 00:55:12,910 --> 00:55:14,739 And this is something that in the last 1571 00:55:14,740 --> 00:55:15,969 IETF meeting they brought up. 1572 00:55:15,970 --> 00:55:18,729 So there's a proposal for separating 1573 00:55:18,730 --> 00:55:20,889 private key operations from 1574 00:55:20,890 --> 00:55:22,359 the TSA itself. 1575 00:55:23,620 --> 00:55:25,779 It was brought up as a see the last 1576 00:55:25,780 --> 00:55:27,699 item. So I would encourage you to check 1577 00:55:27,700 --> 00:55:28,700 that out. 1578 00:55:30,280 --> 00:55:32,289 Signal angel, please. 1579 00:55:32,290 --> 00:55:34,209 Frank, you, too, wants to know whether IP 1580 00:55:34,210 --> 00:55:36,099 Version six encryption could replace, 1581 00:55:36,100 --> 00:55:38,289 tearless or mitigate at least some 1582 00:55:38,290 --> 00:55:39,290 of these issues. 1583 00:55:40,940 --> 00:55:43,009 So IPV six 1584 00:55:43,010 --> 00:55:45,289 encryption, yeah, I think. 1585 00:55:47,930 --> 00:55:49,559 I don't see that as a replacement for 1586 00:55:49,560 --> 00:55:50,779 TLC. 1587 00:55:50,780 --> 00:55:53,299 I see different layers of encryption, 1588 00:55:53,300 --> 00:55:55,909 whether it's TCP Creped or 1589 00:55:55,910 --> 00:55:58,129 anywhere lower down on the 1590 00:55:58,130 --> 00:56:00,499 on the stack as 1591 00:56:00,500 --> 00:56:02,959 additional layers of defense in depth. 1592 00:56:02,960 --> 00:56:05,119 So the 1593 00:56:05,120 --> 00:56:07,069 good thing about classes is that it 1594 00:56:07,070 --> 00:56:09,319 encapsulates your 1595 00:56:09,320 --> 00:56:11,269 messages and it's really just point to 1596 00:56:11,270 --> 00:56:12,769 point on that on that side. 1597 00:56:12,770 --> 00:56:13,770 So 1598 00:56:15,170 --> 00:56:17,479 it allows you to really trust 1599 00:56:17,480 --> 00:56:19,609 the server itself, whereas 1600 00:56:19,610 --> 00:56:20,779 something like encryption at lower 1601 00:56:20,780 --> 00:56:22,549 levels. Yes, this is great. 1602 00:56:22,550 --> 00:56:24,229 I mean, we have encryption on many 1603 00:56:24,230 --> 00:56:25,669 different protocols. 1604 00:56:25,670 --> 00:56:27,739 Wireless, you know, Wi-Fi 1605 00:56:27,740 --> 00:56:28,639 is encrypted. 1606 00:56:28,640 --> 00:56:30,739 All of your sort of 3G, 4G 1607 00:56:30,740 --> 00:56:32,539 signals are encrypted. 1608 00:56:32,540 --> 00:56:33,769 More encryption is better. 1609 00:56:33,770 --> 00:56:35,509 And I don't think that having one 1610 00:56:35,510 --> 00:56:37,429 encryption on a lower layer should stop 1611 00:56:37,430 --> 00:56:38,929 you from adding encryption on a higher 1612 00:56:38,930 --> 00:56:39,930 layer. 1613 00:56:40,750 --> 00:56:42,759 Microphone number four, please. 1614 00:56:42,760 --> 00:56:44,979 Hello. So you have shown how 1615 00:56:44,980 --> 00:56:47,859 slowly the standard 1616 00:56:47,860 --> 00:56:50,739 itself is evolving and 1617 00:56:50,740 --> 00:56:53,349 even much slower the adoption 1618 00:56:53,350 --> 00:56:55,479 is evolving, and that would be 1619 00:56:55,480 --> 00:56:57,579 my question. Do you agree that this 1620 00:56:57,580 --> 00:56:59,829 should heavily invest, 1621 00:56:59,830 --> 00:57:02,079 maybe even in the standard, to 1622 00:57:02,080 --> 00:57:04,599 make it easier adoptable 1623 00:57:04,600 --> 00:57:06,849 and do something more there 1624 00:57:06,850 --> 00:57:09,489 and have you concrete plans or proposals 1625 00:57:09,490 --> 00:57:10,630 how this could be achieved? 1626 00:57:12,740 --> 00:57:14,149 I don't have any concrete plans or 1627 00:57:14,150 --> 00:57:15,769 proposals on that, but I think it's a 1628 00:57:15,770 --> 00:57:16,249 good idea. 1629 00:57:16,250 --> 00:57:18,859 I mean, I think upgradeability 1630 00:57:18,860 --> 00:57:20,959 is one of the one of the most difficult 1631 00:57:20,960 --> 00:57:22,579 problems we're facing in terms of these 1632 00:57:22,580 --> 00:57:25,039 protocols, because as 1633 00:57:25,040 --> 00:57:26,539 you saw in all these different versions, 1634 00:57:26,540 --> 00:57:28,009 there were problems and they had to be 1635 00:57:28,010 --> 00:57:29,089 fixed in different ways. 1636 00:57:29,090 --> 00:57:31,219 And we're in, say, the Internet 1637 00:57:31,220 --> 00:57:32,869 of Things, the buzzwords that we're all 1638 00:57:32,870 --> 00:57:34,939 talking about. These are embedded devices 1639 00:57:34,940 --> 00:57:36,349 that are going to have one copy of a 1640 00:57:36,350 --> 00:57:37,219 protocol. 1641 00:57:37,220 --> 00:57:39,439 And it's really 1642 00:57:39,440 --> 00:57:42,829 hard to get firmware 1643 00:57:42,830 --> 00:57:45,289 to be able to, 1644 00:57:45,290 --> 00:57:46,909 you know, have a clean upgrade cycle. 1645 00:57:46,910 --> 00:57:47,910 So 1646 00:57:49,340 --> 00:57:50,749 I don't have any solution there. 1647 00:57:50,750 --> 00:57:51,919 But I see that as one of the biggest 1648 00:57:51,920 --> 00:57:54,079 problems going forward in using 1649 00:57:54,080 --> 00:57:56,119 protocols that are potentially insecure. 1650 00:57:56,120 --> 00:57:57,120 OK, thank you. 1651 00:57:57,970 --> 00:57:59,179 Number six, please. 1652 00:58:00,220 --> 00:58:02,439 Hey, thanks for this nice self 1653 00:58:02,440 --> 00:58:03,529 reminders. 1654 00:58:03,530 --> 00:58:05,409 One thing I'm wondering, when will you 1655 00:58:05,410 --> 00:58:07,689 have any idea when one or three 1656 00:58:07,690 --> 00:58:09,789 would be like finalized and when I 1657 00:58:09,790 --> 00:58:11,559 can finally actually enable it on my Web 1658 00:58:11,560 --> 00:58:12,560 server? 1659 00:58:13,300 --> 00:58:15,429 Not yet. I don't have a concrete date 1660 00:58:15,430 --> 00:58:16,430 on that, but. 1661 00:58:19,700 --> 00:58:22,489 It should happen within the next year, 1662 00:58:22,490 --> 00:58:22,849 hopefully. 1663 00:58:22,850 --> 00:58:25,339 Thanks, Internet, please. 1664 00:58:25,340 --> 00:58:28,219 Why is CloudFlare using elliptic FDA, 1665 00:58:28,220 --> 00:58:29,989 even though it is also relying on a very 1666 00:58:29,990 --> 00:58:32,269 high quality entropy ifop pseudo 1667 00:58:32,270 --> 00:58:33,499 orangy? 1668 00:58:33,500 --> 00:58:35,900 So that's a good question. 1669 00:58:37,060 --> 00:58:39,319 As I mentioned, random number 1670 00:58:39,320 --> 00:58:41,809 generation is very important for 1671 00:58:41,810 --> 00:58:43,159 having secure cryptography. 1672 00:58:43,160 --> 00:58:45,289 And TSA or any sort 1673 00:58:45,290 --> 00:58:47,839 of DNA based algorithm requires 1674 00:58:47,840 --> 00:58:49,759 entropy for every signature, or at least 1675 00:58:49,760 --> 00:58:51,989 it did. Originally, there 1676 00:58:51,990 --> 00:58:54,079 have been more recent RFID on how 1677 00:58:54,080 --> 00:58:56,689 to use RSA in a deterministic 1678 00:58:56,690 --> 00:58:58,069 sense where you don't need a lot of 1679 00:58:58,070 --> 00:59:00,469 entropy and CloudFlare has implemented 1680 00:59:00,470 --> 00:59:01,519 that for you. 1681 00:59:01,520 --> 00:59:03,769 So our Codesa is not using pure 1682 00:59:03,770 --> 00:59:05,899 random numbers. It's using 1683 00:59:05,900 --> 00:59:07,129 a deterministic algorithm. 1684 00:59:07,130 --> 00:59:10,129 So if we have an orange collision, 1685 00:59:10,130 --> 00:59:11,239 it's not a big deal for us. 1686 00:59:12,820 --> 00:59:15,729 No one plays hi. 1687 00:59:15,730 --> 00:59:18,039 So after talking with, like a string 1688 00:59:18,040 --> 00:59:20,199 of calamities and depressing 1689 00:59:20,200 --> 00:59:21,909 stuff, I wonder if there are things that 1690 00:59:21,910 --> 00:59:23,979 make you happy or optimistic about 1691 00:59:23,980 --> 00:59:25,179 the future of. 1692 00:59:25,180 --> 00:59:27,309 Seems like, you know, we 1693 00:59:27,310 --> 00:59:28,869 a lot of those attacks were just after 1694 00:59:28,870 --> 00:59:30,219 Snowden. So people are finally starting 1695 00:59:30,220 --> 00:59:32,439 to pay attention to things 1696 00:59:32,440 --> 00:59:34,209 like the CIA browser baseline 1697 00:59:34,210 --> 00:59:35,559 requirements that were only finalized in 1698 00:59:35,560 --> 00:59:37,749 2012 once XP 1699 00:59:37,750 --> 00:59:38,889 and Android two are dead, will have a 1700 00:59:38,890 --> 00:59:40,989 shorter longtail like other things 1701 00:59:40,990 --> 00:59:42,429 that you're looking forward to or that 1702 00:59:42,430 --> 00:59:44,109 are awesome about deals. 1703 00:59:44,110 --> 00:59:46,089 Yeah, I think some some of the things 1704 00:59:46,090 --> 00:59:48,249 that interest me and I'm 1705 00:59:48,250 --> 00:59:50,769 excited by are, say, 1706 00:59:50,770 --> 00:59:53,139 the MIT project, which is formal, 1707 00:59:53,140 --> 00:59:55,299 formally verified to us 1708 00:59:55,300 --> 00:59:57,369 that I'm one that I 1709 00:59:57,370 --> 00:59:58,809 sort of glossed over was the triple 1710 00:59:58,810 --> 01:00:00,789 handshake, handshake, vulnerability, and 1711 01:00:00,790 --> 01:00:02,949 that was discovered by formal analysis 1712 01:00:02,950 --> 01:00:04,329 of it. I think 1713 01:00:05,440 --> 01:00:07,119 the work that's happening in us, one 1714 01:00:07,120 --> 01:00:09,189 point three to just eliminate, 1715 01:00:09,190 --> 01:00:11,499 say, bad curves or the RSA 1716 01:00:11,500 --> 01:00:13,659 handshake all together are, you know, 1717 01:00:13,660 --> 01:00:15,219 promising steps. 1718 01:00:15,220 --> 01:00:17,469 But I think they could go a lot farther 1719 01:00:17,470 --> 01:00:19,929 in terms of removing things 1720 01:00:19,930 --> 01:00:21,429 having to do with X five or nine and 1721 01:00:21,430 --> 01:00:23,679 Ascencion one and all these very old 1722 01:00:23,680 --> 01:00:25,509 legacy technologies that we're carrying 1723 01:00:25,510 --> 01:00:26,510 along with us. 1724 01:00:29,370 --> 01:00:31,369 My staff that wasn't too optimistic. 1725 01:00:33,230 --> 01:00:34,230 Number two, please. 1726 01:00:35,850 --> 01:00:39,009 Yeah, what's your opinion, 1727 01:00:39,010 --> 01:00:40,509 just out of curiosity, what's your 1728 01:00:40,510 --> 01:00:43,209 opinion on that script? 1729 01:00:43,210 --> 01:00:45,159 I think let's encrypt as great and as 1730 01:00:45,160 --> 01:00:47,319 much as much as as 1731 01:00:47,320 --> 01:00:49,239 I sort of railed on tirelessness in this 1732 01:00:49,240 --> 01:00:51,489 conversation, having 1733 01:00:51,490 --> 01:00:54,339 an encryption of any sorts is 1734 01:00:54,340 --> 01:00:56,409 preferred to not having encryption at 1735 01:00:56,410 --> 01:00:58,479 all. And the greater percentage of. 1736 01:00:58,480 --> 01:01:00,439 Yeah, I think, you know. 1737 01:01:02,470 --> 01:01:05,049 I think the greater percentage of the web 1738 01:01:05,050 --> 01:01:06,279 that's encrypted, the better. 1739 01:01:06,280 --> 01:01:08,349 And me personally, 1740 01:01:08,350 --> 01:01:10,809 I would be absolutely 1741 01:01:10,810 --> 01:01:13,179 over over overjoyed if we could get 1742 01:01:13,180 --> 01:01:15,249 every site to be only. 1743 01:01:15,250 --> 01:01:17,319 And that's let's encrypt is a 1744 01:01:17,320 --> 01:01:19,419 big part of that. For four websites that 1745 01:01:19,420 --> 01:01:21,549 can't use, say, CloudFlare, we offer SSL 1746 01:01:21,550 --> 01:01:22,659 for free. 1747 01:01:22,660 --> 01:01:25,329 Not everybody can use our services. 1748 01:01:25,330 --> 01:01:27,039 This is a great option for getting a free 1749 01:01:27,040 --> 01:01:28,040 cert. 1750 01:01:30,670 --> 01:01:32,839 Could we please get two more questions 1751 01:01:32,840 --> 01:01:34,869 so there's no point in standing up now, 1752 01:01:34,870 --> 01:01:36,699 we just will finish what we started 1753 01:01:36,700 --> 01:01:39,189 intended to please suppose 1754 01:01:39,190 --> 01:01:41,439 we have a customer that insists on still 1755 01:01:41,440 --> 01:01:43,719 using SSL version three and 1756 01:01:43,720 --> 01:01:45,909 we badly need this customer how 1757 01:01:45,910 --> 01:01:47,320 to convince them to upgrade, 1758 01:01:48,580 --> 01:01:50,109 how to convince them to upgrade. 1759 01:01:50,110 --> 01:01:51,110 That's a good question. 1760 01:01:53,440 --> 01:01:55,899 So there are people who have legacy 1761 01:01:55,900 --> 01:01:56,859 systems, right? 1762 01:01:56,860 --> 01:01:59,079 SSL, V3, as we saw, 1763 01:01:59,080 --> 01:02:01,299 it was 100 percent adoption 1764 01:02:01,300 --> 01:02:03,369 adoption on servers up until 1765 01:02:03,370 --> 01:02:04,599 Poodle came out. 1766 01:02:04,600 --> 01:02:06,909 So there 1767 01:02:06,910 --> 01:02:08,229 are tons of different client libraries 1768 01:02:08,230 --> 01:02:10,509 that only use SSL V3. 1769 01:02:10,510 --> 01:02:12,999 One example is 1770 01:02:13,000 --> 01:02:15,249 Pincham, which is a popular tool 1771 01:02:15,250 --> 01:02:17,499 to check if your website's 1772 01:02:17,500 --> 01:02:20,649 online was using SSL V3. 1773 01:02:20,650 --> 01:02:22,719 It actually upgrades to atleast 1774 01:02:22,720 --> 01:02:24,789 once if the first connection fails, which 1775 01:02:24,790 --> 01:02:26,979 we found out once we disabled SSL three. 1776 01:02:26,980 --> 01:02:29,260 But I would 1777 01:02:30,910 --> 01:02:32,889 I mean, it's a it's a hard sell, right? 1778 01:02:32,890 --> 01:02:33,890 I mean. 1779 01:02:34,450 --> 01:02:36,699 If you have a customer who wants 1780 01:02:36,700 --> 01:02:39,009 to use a legacy protocol and it's 1781 01:02:39,010 --> 01:02:42,159 only in use for specific 1782 01:02:42,160 --> 01:02:44,709 clients that can't be upgraded, then 1783 01:02:44,710 --> 01:02:46,450 it's better than having no encryption. 1784 01:02:47,780 --> 01:02:49,159 So I don't really have a have a strong 1785 01:02:49,160 --> 01:02:51,349 argument microphone number two, 1786 01:02:51,350 --> 01:02:53,089 please, please make it short if you can. 1787 01:02:53,090 --> 01:02:54,259 Sure. 1788 01:02:54,260 --> 01:02:56,389 Clouthier still seems to make 1789 01:02:56,390 --> 01:02:58,189 life harder for Tor users. 1790 01:02:58,190 --> 01:03:00,019 When will this stop? 1791 01:03:05,830 --> 01:03:06,819 Well, there are some people in the front 1792 01:03:06,820 --> 01:03:08,319 row that I think you should talk to. 1793 01:03:10,420 --> 01:03:11,409 We're working on it. 1794 01:03:11,410 --> 01:03:12,410 OK, thanks. 1795 01:03:13,300 --> 01:03:15,340 OK, please. Once again, thank Nick.