[00:00.000 --> 00:05.100]  And we're here to talk about the Debian OpenSSL bug that you've probably all heard about.
[00:07.700 --> 00:09.360]  A little Dilbert cartoon for you.
[00:09.700 --> 00:16.880]  Basically, in May of 2006, there was a hopeful Debian developer trying to fix some bugs.
[00:17.120 --> 00:23.020]  And in fixing a bug, he actually introduced probably the worst bug that Debian has ever seen.
[00:23.020 --> 00:29.920]  And it's pretty amazing what widespread effect just a couple comments have created.
[00:30.380 --> 00:39.460]  And so we're going to go into detail about the actual bug and how the bug can be exploited in various different ways, different applications that are affected.
[00:39.800 --> 00:42.960]  And it'll be hopefully interesting to you.
[00:43.960 --> 00:44.600]  Yeah.
[00:45.240 --> 00:52.880]  The Debian bug is probably, as Jake said, the most widely spread cryptographic vulnerability on the Internet at the moment.
[00:53.020 --> 00:56.560]  And certainly has been much wider spread a few weeks ago still.
[00:57.320 --> 01:02.380]  And it really all boils down to cryptographic keys and the entropy.
[01:02.760 --> 01:16.280]  Cryptographic keys are used very widely to secure systems, to authenticate users, to sign data, and pretty much any other application where security is used.
[01:16.420 --> 01:20.980]  So cryptographic keys are very much at the foundation of Internet security.
[01:20.980 --> 01:28.380]  And cryptographic keys are only good if they're hard to guess, much like your password on your computer.
[01:28.380 --> 01:36.380]  If it's easy to guess, then it's no good if somebody can just try all likely passwords and find the one you're using.
[01:36.700 --> 01:41.960]  So the hardness of guessing a password or cryptographic key is measured in entropy.
[01:41.960 --> 01:46.980]  That is, the number of bits at least needed to describe it.
[01:47.140 --> 01:51.580]  And so, with a password, for example, the entropy grows as the password is longer.
[01:51.840 --> 01:55.000]  But it also grows as you use more different characters.
[01:56.180 --> 02:00.220]  Windows passwords have been broken for years.
[02:00.220 --> 02:13.200]  Since there's only 36 bits of entropy, so any rainbow table, any type of that can break it, we'll see that the Debian vulnerability decreases to 15 bits.
[02:13.580 --> 02:18.920]  So where 30 bits is weak, 15 bits is just not any security at all.
[02:18.920 --> 02:23.860]  And for any system to be secure, you need about 80 bits of entropy.
[02:24.780 --> 02:43.920]  Now, these cryptographic keys and all the different applications that are used are typically generated from one packet, the OpenSSL packet, that was started to provide secure communication on the Internet, but now provides all these very useful tools that other programs use to generate their cryptographic keys.
[02:43.920 --> 02:44.480]  Now,
[02:55.980 --> 03:06.660]  to generate cryptographic keys on a computer, the OpenSSL packet has to acquire randomness, basically.
[03:07.000 --> 03:10.840]  So imagine you have to come up with something random in a deterministic program.
[03:11.020 --> 03:11.860]  That's kind of hard.
[03:11.860 --> 03:20.760]  Linux or any UNIX system pretty much already does the work for you mostly by collecting random events such as user input.
[03:21.300 --> 03:27.700]  For example, the speed at which you type, the exact pass through which you move your mouse.
[03:27.840 --> 03:30.400]  All those things are collected and provided in a new random.
[03:30.920 --> 03:39.020]  Now, OpenSSL doesn't consider that sufficient and adds a few other things on top of it.
[03:39.020 --> 03:45.760]  It adds the process ID, which also changes every time you call a program, this key generation program, and a few other things.
[03:46.060 --> 03:56.760]  And one thing it also does is it uses to bootstrap its entropy memory that has never been written to, at least not from this process.
[03:56.760 --> 04:00.700]  So imagine you read some memory cell that you didn't write to.
[04:00.820 --> 04:03.740]  It's basically random, it's content, at least not very predictable.
[04:04.940 --> 04:14.500]  Now, that led some Debian developer to think about why somebody would ever read from memory before writing to it.
[04:14.500 --> 04:23.520]  And that's basically the irony of this vulnerability, is that of those sources of entropy, the uninitialized memory is actually the weakest.
[04:23.800 --> 04:27.920]  Because it's not like you're actually getting the memory from the chip, it's the memory from the address.
[04:28.260 --> 04:32.160]  You know, basically it's initialized memory, so it's basically just leftover stuff from the stack.
[04:32.460 --> 04:35.720]  And so basically knowing the program, knowing the state, you'll know what those values are.
[04:35.720 --> 04:39.060]  So it was kind of a half-baked idea in the beginning.
[04:39.760 --> 04:46.440]  And then Debian developers, you know, is looking to improve the software, and they're using a software called Valgrind.
[04:46.600 --> 04:51.680]  And what Valgrind does is it looks for memory leaks, and it looks for these cases where you're using uninitialized memory.
[04:52.160 --> 04:58.620]  And basically if you're using uninitialized memory before it's initialized, this actually also can be a security vulnerability.
[04:58.820 --> 05:00.760]  And there's a lot of cool bugs this way.
[05:00.880 --> 05:03.020]  But in this case, he was trying to get rid of those vulnerabilities.
[05:03.020 --> 05:06.180]  So he's like, oh, Valgrind complains, let's comment this out.
[05:06.300 --> 05:10.580]  We don't really need to use this uninitialized memory because it's kind of worthless.
[05:11.080 --> 05:12.860]  Valgrind V-A-L-G-R-I-N-D?
[05:12.940 --> 05:13.400]  That's correct.
[05:13.740 --> 05:15.120]  V-A-L-G-R-I-N-D.
[05:15.440 --> 05:16.500]  And actually to...
[05:16.500 --> 05:17.520]  It's a good tool.
[05:17.860 --> 05:18.160]  Yeah.
[05:18.380 --> 05:19.960]  To be fair, there's also...
[05:20.520 --> 05:27.880]  The Debian developer that did this apparently did not see the FAQ about the Valgrind error on the OpenSSL website.
[05:28.780 --> 05:33.660]  That was pretty specific like Valgrind has an error in this, just ignore it.
[05:35.600 --> 05:45.560]  But then there's also the fact that he did ask, the Debian developer did ask on the OpenSSL dev mailing list, which is not the OpenSSL team mailing list.
[05:45.980 --> 05:49.880]  Which means that anyone could answer that, and it's not an authoritative answer.
[05:50.100 --> 05:53.800]  Even though an OpenSSL developer did say if you're trying to have some...
[05:53.800 --> 06:01.740]  Like, you're trying to solve some problems with debugging, you know, or if you want to figure out what's actually going on, it might be useful to, you know, get rid of those errors.
[06:02.040 --> 06:03.840]  But I don't think that...
[06:03.840 --> 06:08.620]  And no one would say that the OpenSSL team blessed that patch and said that was a good idea.
[06:08.620 --> 06:17.900]  Although, there's definitely some dispute about whether or not that that's a reasonable thing that an OpenSSL developer could reply on a dev mailing list saying that.
[06:18.940 --> 06:25.860]  But it seems pretty clear that it wasn't like Ben Lorre signed off on the patch and integrated it upstream in OpenSSL.
[06:25.940 --> 06:29.140]  Yeah, well, importantly, yeah, OpenSSL didn't integrate it upstream.
[06:29.560 --> 06:32.700]  I mean, this was basically a patch that kept... that stayed in the distribution.
[06:32.700 --> 06:40.860]  And one could say that basically the only patches you should make to software, you know, in the distribution, especially with crypto, is, like, where you're going to install the files.
[06:41.120 --> 06:42.700]  You shouldn't change how it works.
[06:42.860 --> 06:47.160]  And what he did is the developer just got overzealous and uncommented out...
[06:47.160 --> 06:52.480]  Or basically commented out the instance where the uninitialized memory was used.
[06:52.720 --> 06:55.680]  And then they went and commented out another instance of it.
[06:55.680 --> 07:05.020]  And that one was basically where the first source of entropy, the view random, the real one, that's where that was seeded into the random number generator for OpenSSL.
[07:05.940 --> 07:06.460]  So...
[07:06.460 --> 07:14.660]  Yeah, so the buck was patched in the worst possible way by also removing a lot of other things that contributed randomness.
[07:14.840 --> 07:19.460]  And one thing that's really beautiful about the patch is it's deceptive in how simple it is.
[07:19.460 --> 07:21.540]  It's a multi-line comment.
[07:21.740 --> 07:29.320]  So you see two insertions, you know, slash, star, a comment, you know, stop making this, have an error.
[07:29.480 --> 07:31.660]  And then the line, which has not changed...
[07:32.140 --> 07:32.920]  Oh, should we look at it?
[07:33.200 --> 07:33.600]  And...
[07:33.600 --> 07:34.680]  Yeah, we should look at this.
[07:34.860 --> 07:38.240]  It's beautiful, because upon first looking at it, you...
[07:44.400 --> 07:45.880]  The screen is much smaller.
[07:47.360 --> 07:48.140]  Do we have it?
[07:48.280 --> 07:48.440]  Yeah.
[07:48.440 --> 07:49.180]  There it is.
[07:49.180 --> 07:49.760]  Yeah, there it is.
[07:50.060 --> 07:55.560]  So if you notice, the MD update and the MD update are both commented out.
[07:55.700 --> 08:03.040]  But it's kind of non-obvious that it's commented out, because you see it's not green, it's not changed.
[08:03.200 --> 08:06.760]  But in fact, it's not in effect anymore.
[08:07.040 --> 08:11.960]  So just looking at that patch, it looks like, at just a quick glance, that it's not really a big deal.
[08:13.260 --> 08:18.320]  I mean, the first time someone recently saw this patch, they were like, oh, they just added a comment, it's not a big deal.
[08:18.320 --> 08:21.280]  But actually, like, whoops, that's the worst bug Debian's ever had.
[08:23.300 --> 08:26.780]  And what's funny about this is you can tell, you know, this page is very popular.
[08:26.960 --> 08:32.700]  If you Google OpenSSL, SVN, and trunk, you get a link to that diff.
[08:33.760 --> 08:36.100]  So that is the most popular search result.
[08:37.240 --> 08:41.160]  And the problem is clearly not limited to a single version of Debian.
[08:41.280 --> 08:54.020]  It has been in the Debian stable for a year, but it has from there been taken into other distributions that build up on Debian, including very popular Ubuntu, which I think is the most popular desktop distribution.
[08:54.020 --> 09:01.260]  So it has spread very widely into many distros and has only, after a year, in May of this year, been patched.
[09:01.380 --> 09:12.260]  And the interesting thing about the patch is in violation of Debian's own policy on the issue, at least from my reading of it, they publicly patched this before they disclosed the bug.
[09:13.080 --> 09:20.820]  And the interesting thing, if any of you are familiar with the deny hosts package, they have a nice little graph.
[09:21.040 --> 09:28.160]  And the graph showed an increase of brute force attempts basically after the patch but before disclosure.
[09:28.700 --> 09:31.980]  Like an incredible, like several orders of magnitude higher.
[09:32.120 --> 09:33.620]  And there are a couple of news articles written about this.
[09:33.700 --> 09:41.640]  Unfortunately, we couldn't get the graph because the deny hosts website doesn't keep, like, aggregate stats that you can get from a specific date.
[09:41.640 --> 09:44.860]  It would be kind of neat to have that if anyone has it.
[09:45.240 --> 09:46.380]  But I couldn't find it.
[09:47.060 --> 09:54.720]  So you're suggesting that people looked at the patch and worked out what the patch was fixed and were trying to attack?
[09:54.940 --> 09:55.340]  Yes.
[09:56.820 --> 09:57.300]  It's...
[09:57.300 --> 10:02.940]  For all security bugs, there's a lot of people watching every Linux kernel, you know, change.
[10:03.240 --> 10:06.440]  Regardless of what the comment says, they check to see if it has security ramifications.
[10:06.860 --> 10:09.740]  People are obviously reverse engineering Microsoft patches.
[10:09.740 --> 10:14.520]  There's no reason to believe that people aren't doing the same for distribution updates as well.
[10:14.780 --> 10:15.280]  Yeah.
[10:15.480 --> 10:17.720]  People even look at binary updates a lot.
[10:17.960 --> 10:22.300]  All Windows patches are reverse engineered to see what vulnerabilities they patch.
[10:22.440 --> 10:25.740]  So having a source code update is so much easier to look at.
[10:25.820 --> 10:25.960]  Yeah.
[10:26.820 --> 10:27.340]  Yeah.
[10:28.040 --> 10:30.100]  So different programs are affected by this.
[10:30.220 --> 10:34.900]  Pretty much any program that generates cryptographic keys using the OpenSSL library.
[10:35.360 --> 10:39.680]  One of which being SSH that's used as a secure lock-in to server.
[10:39.880 --> 10:42.500]  So it's used by a limited number of people.
[10:42.660 --> 10:44.240]  Pretty much everybody in this room probably.
[10:44.460 --> 10:47.140]  But not a large fraction of the Internet population.
[10:47.340 --> 10:55.860]  But it does affect most systems since the system that you get your data from, that you trust, might be affected by some admin having a weak key.
[10:55.860 --> 11:01.260]  And SSH uses a number of different keys and all of them could be affected.
[11:01.500 --> 11:07.940]  So there are the host keys that on first lock-in you tell your SSH, yes, you trust this host.
[11:08.100 --> 11:16.100]  And every time you log in your computer locally will check whether the fingerprint of that machine has changed to prevent men in the middle attacks.
[11:16.100 --> 11:23.380]  So now, given that these keys can be broken, the servers that you trust can be spoofed.
[11:24.520 --> 11:27.440]  Other keys are used for passwordless lock-in.
[11:27.620 --> 11:33.960]  So you tell the server to trust your key and to let you log in without giving any other credentials.
[11:34.200 --> 11:36.020]  And those too can be weak.
[11:36.020 --> 11:41.540]  So if, say, the root account has a weak certificate, these can easily be brute force.
[11:41.740 --> 11:46.880]  There's only 32,000 different ones on any given architecture, 15 bits entropy.
[11:47.220 --> 11:49.060]  And those can all be tried.
[11:49.340 --> 11:52.500]  Nice side effect is that that does not leave a trace in the lock.
[11:52.680 --> 11:57.460]  So if you provide a wrong password, it will create a line in the lock.
[11:57.500 --> 12:00.900]  If you provide a wrong certificate, it will not in most cases.
[12:00.900 --> 12:08.740]  Now, the last keys and the ones that haven't gotten much attention with regards to this bug are the session keys.
[12:08.920 --> 12:11.920]  So to provide forward secrecy, we'll get to that in a minute.
[12:13.640 --> 12:18.380]  Initially, in each session, a new key is generated that both parties agree on.
[12:18.500 --> 12:24.420]  And then those user keys or host keys are used to sign that key to make sure that both parties agree on that.
[12:24.860 --> 12:27.260]  Now, those session keys too can be vulnerable.
[12:27.260 --> 12:40.240]  And since the session keys are generated at the beginning of each session, they can be vulnerable if one of the computers is vulnerable, and not necessarily any key that you can look at.
[12:40.540 --> 12:48.200]  So all the tools that have come out to fix the SSH program, they search on your computer for weak keys.
[12:49.040 --> 13:00.020]  If you, though, without having a weak key, log into another computer who doesn't have weak keys either, but has a broken open SSL library still, those session keys are predictable.
[13:02.060 --> 13:02.700]  All right.
[13:02.880 --> 13:06.720]  So basically, the issue is the Diffie-Hellman key exchange.
[13:07.260 --> 13:17.300]  And there's an interesting... I mean, this particular thing was something that I had thought was theoretically possible, and I was starting to work on a tool.
[13:17.520 --> 13:22.560]  And then in researching the tool, I found that someone else had actually already written the tool and released it.
[13:23.960 --> 13:27.800]  So these guys are badass, from what I can tell.
[13:28.460 --> 13:34.700]  Basically, they wrote... So the three tools that are up here are pretty much self-explanatory.
[13:35.400 --> 13:48.420]  But basically, it can generate... The first key, we haven't tested this, but it seems reasonable from reading the OpenSSH source, and also from understanding a little bit about the protocol and discussing it with people that are more knowledgeable about it than myself.
[13:49.940 --> 13:51.880]  You have a couple of things you can do.
[13:51.880 --> 13:58.500]  Even without the weak keys, the secrecy of the OpenSSH conversation relies on the Diffie-Hellman.
[13:58.720 --> 14:06.060]  And if either of the secrets chosen by either side is weak, then you are screwed.
[14:06.760 --> 14:14.420]  And this tool will take a PCAP file and decrypt those sessions, and it'll also extract the authentication keys from the conversations.
[14:15.380 --> 14:18.520]  So basically, your password can be decoded through that.
[14:18.520 --> 14:22.400]  But if the server you logged into uses a weak OpenSSL.
[14:22.560 --> 14:22.780]  Right.
[14:23.060 --> 14:27.500]  And so they also wrote a tool, BF SSH, which is just over the top.
[14:27.800 --> 14:28.860]  It's ridiculous.
[14:29.160 --> 14:30.120]  They didn't need to write this.
[14:30.220 --> 14:34.140]  SSH already allows you to toss in a number of identity keys.
[14:34.280 --> 14:42.020]  Most people have their server configured, like most Debian people have their server configured, by default, to allow six different tries.
[14:42.280 --> 14:44.220]  So that means you can try six different identities.
[14:45.000 --> 14:50.780]  SSH, just normal, in a loop, in like Bash, you could call six keys at a time and try and log in.
[14:50.940 --> 14:53.700]  And if you have a success, you could narrow it down pretty easily.
[14:53.880 --> 14:55.800]  But they just wrote a tool that tries everything.
[14:56.060 --> 15:03.260]  And in ten minutes, they can get an entire set of keys for a given architecture and get into the machine if there's a weak key.
[15:04.060 --> 15:10.160]  And, like I said, the decoder is... if someone wants to demo this with a...
[15:10.160 --> 15:11.480]  It's cr0.org.
[15:11.880 --> 15:12.260]  Oh, yeah.
[15:12.540 --> 15:12.940]  CR0.
[15:13.080 --> 15:13.280]  Yeah.
[15:13.920 --> 15:14.440]  That's right.
[15:15.020 --> 15:15.420]  Thanks.
[15:15.700 --> 15:15.940]  Thanks.
[15:16.600 --> 15:19.660]  So, I mean, if someone wants to try this out, I'm sure that it would work.
[15:19.740 --> 15:21.420]  It makes perfect sense that it would work.
[15:21.500 --> 15:23.140]  But we didn't have time to do this.
[15:23.220 --> 15:25.260]  We found it at the very last minute, so...
[15:26.960 --> 15:31.660]  Any questions on the SSH box before we move on to some other applications?
[15:31.660 --> 15:37.860]  One thing we should also point out about that is, like, even if you're, say, running, like, Red Hat Enterprise Linux, you're like, oh, this doesn't affect me.
[15:37.980 --> 15:40.180]  I pay good money for it, Enterprise Linux.
[15:43.720 --> 15:48.560]  Then, you know, one of your users is learning how to use Linux, and they're like, I want to run Linux, too.
[15:48.680 --> 15:52.480]  They download Ubuntu, you know, and they figure out this whole SSH thing and upload their key.
[15:52.660 --> 16:00.180]  So even though you think you're not affected, if a user generates their own key on a vulnerable system and places it on your system, your entire server is open to attack.
[16:00.180 --> 16:03.680]  And it's not like there are no local kernel vulnerabilities in Linux.
[16:03.920 --> 16:08.520]  And there's also some really beautiful PAM timing attacks with SSH.
[16:08.640 --> 16:14.260]  It's very easy to find out if a user exists on a given system, completely unrelated to this bug.
[16:14.440 --> 16:22.160]  So if you combine a couple of other OpenSSH issues together, you can probably get pretty far.
[16:22.160 --> 16:26.600]  And as Dino was just mentioning, the Linux kernel is rock solid and has no problems.
[16:27.100 --> 16:32.360]  So, I mean, if someone were to get a user local account, it would be impossible for them to root it, obviously.
[16:32.560 --> 16:32.760]  Yeah.
[16:33.420 --> 16:33.860]  Sarcasm.
[16:33.860 --> 16:38.400]  You guys are limiting yourself to discussing Linux here.
[16:38.580 --> 16:41.080]  But what about, you know, Solaris and other things?
[16:41.240 --> 16:42.480]  It's all the same, actually.
[16:42.860 --> 16:43.420]  Absolutely.
[16:43.760 --> 16:46.760]  The question is whether other UNIX flavors are affected.
[16:47.040 --> 16:51.560]  And they are affected if they do talk to a Debian system.
[16:51.560 --> 16:58.480]  So if somebody from Solaris locks onto a Debian with a weak SSL, then they affect it too, yes.
[16:58.800 --> 17:01.300]  Or if those keys were moved to the Solaris box.
[17:01.380 --> 17:01.780]  Exactly.
[17:01.880 --> 17:05.720]  Or if the keys were generated locally, which is often the case.
[17:05.720 --> 17:12.780]  Users do typically keep the private portion of the key on their home machine or on whatever machine they used to lock in.
[17:12.880 --> 17:14.840]  And so this is where the keys are generated.
[17:15.060 --> 17:18.200]  And often the administrators have no idea where the keys come from.
[17:18.200 --> 17:20.020]  What do you do in the audience?
[17:20.200 --> 17:23.080]  What do we do to protect ourselves?
[17:23.280 --> 17:23.960]  Is there no way?
[17:24.280 --> 17:26.900]  We will get to countermeasures in a minute.
[17:27.340 --> 17:32.000]  If you guys want to ask questions, either use the microphone and line up.
[17:33.120 --> 17:34.080]  That would probably be better.
[17:34.120 --> 17:35.500]  We have two mics with glowing red dots.
[17:35.880 --> 17:36.100]  Yeah, two mics.
[17:36.100 --> 17:37.840]  The nice MC over there.
[17:37.940 --> 17:39.260]  So all the people at home can follow along.
[17:39.420 --> 17:39.660]  Right.
[17:41.880 --> 17:42.540]  Yes, ma'am.
[17:43.260 --> 17:44.060]  Great presentation.
[17:45.340 --> 17:49.220]  The best cryptographic system in the world can be defeated by a keylogger, correct?
[17:50.180 --> 17:50.380]  Yes.
[17:50.380 --> 17:56.280]  And unless you have 100% physical security, it's very easy for a keylogger to pick all this stuff up and break it all.
[17:56.500 --> 18:01.780]  Do you have any thoughts about how you can defeat keyloggers and how you can get around that vulnerability?
[18:02.340 --> 18:07.320]  Well, so in this case, a keylogger is definitely a different problem.
[18:08.340 --> 18:18.760]  The thing here is that we can passively record your traffic without access to either of the systems and at any point in the future, depending on the details of the protocol, decrypt it.
[18:18.960 --> 18:27.740]  So if you're using a Debian system that's vulnerable to this, basically all of the cryptographic operations that you do are totally broken and you might as well not even bother encrypting them.
[18:27.740 --> 18:33.020]  So the keylogger portion is a very different problem entirely.
[18:33.340 --> 18:41.520]  But, I mean, the real issue here is that random numbers can break even the strongest ciphers and the best protocols if they're poorly generated.
[18:41.900 --> 18:45.960]  I didn't mean to be off topic, but I didn't know if you had any thoughts about keyloggers and how to get around them.
[18:46.160 --> 18:48.740]  Keyloggers can be defeated by multi-factor authentication.
[18:48.740 --> 18:53.720]  So beyond something that you know, you should have something in your possession that proves that you are you.
[18:53.980 --> 18:57.500]  And something that you cannot just steal by copying some data off.
[18:57.720 --> 18:58.340]  Thank you very much.
[18:59.420 --> 19:01.500]  So moving on to some other applications.
[19:01.700 --> 19:03.980]  I had just one quick question about the SSH.
[19:04.160 --> 19:11.900]  So we had a joke at work that when this thing was made public, it was like, well, this is Christmas for both the NSA and the bad guys.
[19:11.900 --> 19:19.500]  Because if they had been recording a whole bunch of traffic for the past year, suddenly they got all, you know, all the plain text.
[19:20.280 --> 19:33.020]  So my question is, has there been any, like, implication or, you know, knowledge come forward about, you know, anything bad that's happened because of this?
[19:33.020 --> 19:37.360]  I mean, I know, we know that this is really bad, but has any fallout or aftermath?
[19:37.780 --> 19:43.880]  I mean, I've had some dealings with the DHS asking me to help them with things, which I mentioned yesterday in my cold boot talk.
[19:44.000 --> 19:48.140]  And I don't think you have a lot to worry about from some wings of the government.
[19:49.640 --> 19:51.160]  I mean, sorry.
[19:51.840 --> 19:56.060]  I mean, they're definitely, I mean, if the NSA wants to own you, you're screwed.
[19:56.060 --> 19:57.320]  I mean, you can't beat them.
[19:57.540 --> 20:06.980]  But I think that this is, unfortunately, if you were being, if you were using Debian and you were under surveillance, you're in deep shit.
[20:07.200 --> 20:07.980]  There's no question.
[20:08.740 --> 20:11.780]  I mean, all it takes is some time.
[20:12.040 --> 20:13.160]  I mean, that's the interesting thing.
[20:13.300 --> 20:20.280]  I mean, security is useful for, I mean, you need to evaluate your risks and then determine what you actually have as a threshold.
[20:20.280 --> 20:28.920]  Because in this case, something that a couple of days ago seemed like it would be good for years and years and years, turns out that it's not.
[20:29.380 --> 20:34.120]  So whatever you were doing, if you were trying to hide it, you probably failed miserably.
[20:34.300 --> 20:35.060]  And that's not your fault.
[20:35.320 --> 20:37.880]  And that's kind of the nature of it, I guess.
[20:38.240 --> 20:39.660]  That's why I don't use computers.
[20:42.180 --> 20:45.180]  I just want to live in the forest, take photographs.
[20:45.180 --> 20:59.880]  Now, my question is, has this had any fallout or has there been any change in the Debian procedures and protocols for who gets to work on the crypto packages when they're packaging them for Debian?
[21:00.120 --> 21:07.940]  Or, you know, basically, has Debian put in place any practices or procedures to make sure this kind of thing doesn't happen again?
[21:08.100 --> 21:09.260]  Well, let's ask Micah Anderson.
[21:09.260 --> 21:11.040]  He's a Debian developer on the security team.
[21:12.020 --> 21:12.640]  No.
[21:13.100 --> 21:13.240]  No.
[21:15.180 --> 21:15.580]  Excellent.
[21:15.820 --> 21:16.140]  All right.
[21:16.260 --> 21:18.180]  But good procedures were in place before.
[21:18.200 --> 21:23.760]  They were just violated into places where the patch was not propagated up properly.
[21:24.020 --> 21:27.960]  And the patch was issued before the announcement.
[21:28.320 --> 21:30.180]  So both of which, I think...
[21:30.180 --> 21:30.800]  Well, I just...
[21:30.800 --> 21:33.860]  That's not actually a policy Jake mentioned earlier that...
[21:33.860 --> 21:34.080]  Okay.
[21:34.240 --> 21:34.880]  It should be one.
[21:35.240 --> 21:35.600]  I thought...
[21:35.600 --> 21:36.460]  It's a suggestion.
[21:36.800 --> 21:37.220]  Okay.
[21:37.500 --> 21:38.560]  Suggestion, not a policy.
[21:38.720 --> 21:38.960]  All right.
[21:39.520 --> 21:44.480]  It should probably be a policy to not publicly disclose the patches before security.
[21:44.480 --> 21:45.480]  releases.
[21:46.220 --> 21:52.100]  It is a policy for issues that are embargoed and under vendor sec.
[21:52.340 --> 21:57.500]  But if they are already publicly known on the Internet, there's no point in hiding them.
[21:57.680 --> 21:59.900]  But that bug wasn't publicly known on the Internet.
[22:00.180 --> 22:00.440]  Right.
[22:00.520 --> 22:03.140]  It wasn't actually known as a security bug right away.
[22:03.140 --> 22:08.820]  So the patch was applied to subversion without understanding that there was a...
[22:08.820 --> 22:09.320]  Ah, I see.
[22:09.560 --> 22:09.840]  Right.
[22:10.040 --> 22:11.680]  So it wasn't known as a security bug.
[22:11.760 --> 22:14.180]  So it was already revealed on the Internet before it was...
[22:14.180 --> 22:14.860]  Great.
[22:14.940 --> 22:15.520]  That makes sense.
[22:15.520 --> 22:25.420]  I guess my question was more along the lines of who gets permission, actually, to submit a patch on crypto code?
[22:25.620 --> 22:30.600]  Have they, you know, vetted the people who have the commit privileges there?
[22:31.480 --> 22:33.060]  Just to talk to the vetting issue.
[22:33.280 --> 22:38.040]  I once sat in a room with a bunch of NSA, DOD, FBI types at Cisco.
[22:38.360 --> 22:45.500]  And they were talking about how since everyone in the room was vetted, they could talk freely about their plans to want to control the Internet.
[22:47.500 --> 22:53.740]  And then they talked about a bunch of other stuff that they shouldn't have talked about in front of me because I have next to no respect for them.
[22:53.740 --> 23:15.980]  And basically, I think the vetting process just... and sometimes can lead to something good, but the Debian way of dealing with this, which maybe Micah can speak to, is about as reasonable, I think, as any vetting process can be, which is... well, if you want to mention how every Debian developer can upload any package into the repository and things like that.
[23:17.120 --> 23:20.240]  Yeah, I mean, the question goes further upstream.
[23:20.240 --> 23:26.000]  Who in the OpenSSH development team has access to commit things to that repository?
[23:26.200 --> 23:27.460]  And what's the vetting process there?
[23:27.900 --> 23:29.080]  I mean, you can keep going.
[23:31.060 --> 23:33.460]  I don't know how interesting that really is.
[23:34.280 --> 23:36.300]  Because how do you trust those people?
[23:36.980 --> 23:44.720]  It's like a group of activists that once did a GBG key signing party refused to sign my key because I wouldn't provide government-issued ID.
[23:45.060 --> 23:46.020]  Right, exactly.
[23:46.380 --> 23:47.540]  I was like, are you kidding me?
[23:47.620 --> 23:48.260]  Can you trust them?
[23:48.360 --> 23:49.260]  I mean, here I am.
[23:49.260 --> 23:49.940]  This is me.
[23:50.420 --> 23:52.820]  You're signing my key, and that represents me.
[23:52.980 --> 23:54.220]  Well, we need a driver's license.
[23:55.000 --> 23:55.380]  Right.
[23:55.580 --> 23:56.160]  Right, cool.
[23:56.280 --> 23:57.620]  Well, I don't know why I don't want to talk to you.
[24:00.460 --> 24:00.860]  So...
[24:00.860 --> 24:03.240]  Can I just point out one thing that you were mentioning earlier?
[24:03.520 --> 24:04.180]  Sure, sure.
[24:04.740 --> 24:18.560]  You were mentioning that if you had a Solaris box, for example, and a Debian or Ubuntu user used SSH keys to connect to it, then you might have an issue with this particular problem.
[24:18.940 --> 24:31.540]  But I think it's actually a much larger problem than that because the possible keys that could be generated for a host key or for an SSH authentication key are a limited set.
[24:31.540 --> 24:46.420]  And unless those keys are blacklisted so that your Solaris box can't generate them, there is a set of something like 32,000 keys that could potentially be generated and anyone could use to log into your Solaris box.
[24:46.560 --> 24:55.280]  Whether or not you have a Debian or Ubuntu user, you should have a blacklist of these keys.
[24:55.280 --> 24:56.620]  Otherwise, you're compromised.
[24:56.860 --> 24:57.080]  Right.
[24:57.180 --> 24:58.020]  Because it's a known set.
[24:58.180 --> 25:04.200]  Well, so it's complicated because you have basically a lot more than 2 to the 15th of keys.
[25:04.380 --> 25:13.700]  You have 2 to the 15th of keys per architecture and you have a variable based on algorithm and then you also have something based on key size.
[25:13.920 --> 25:18.360]  So, like, John Gilmore, for example, is a really funny guy and I respect him a lot.
[25:18.360 --> 25:32.200]  So, when he generates SSH keys, he picks a random number above, like, 4098 or something like this that's somewhere between that and, like, some ridiculously high number for his RSA keys.
[25:32.360 --> 25:41.980]  So that if someone builds a pre-computed table of 1024 bit, 2048, 4096 bit keys or whatever, he's not going to fall into the, like, pre-computed table.
[25:42.080 --> 25:43.120]  Because it's off by one or something.
[25:43.120 --> 25:45.280]  Because it's... or off by, like, 1,000.
[25:46.320 --> 25:50.380]  And that doesn't protect him, but it would protect him against the fact that everybody uses...
[25:50.380 --> 25:53.940]  everybody that uses the default is the main person that will be targeted.
[25:54.320 --> 26:02.520]  But it also means generating a blacklist is really difficult because the blacklist is going to potentially give false negatives.
[26:02.980 --> 26:07.720]  Because you could have a weak key that doesn't fit into the nice, neat blacklist.
[26:07.920 --> 26:09.780]  Because it would take a long time to generate...
[26:09.780 --> 26:14.720]  Even with only 2 to the 15th, you would still have a lot of...
[26:14.720 --> 26:19.280]  I mean, if you have a 2,000-bit key, well, now you have to generate 2 to the 15th of those keys.
[26:19.460 --> 26:20.840]  So it's... there's a lot there.
[26:21.160 --> 26:22.240]  Blacklisting is very difficult.
[26:24.900 --> 26:25.340]  Okay.
[26:25.560 --> 26:25.800]  Hi.
[26:25.920 --> 26:27.180]  So I'm also working on Tor.
[26:28.800 --> 26:30.780]  And Tor was affected by this.
[26:31.980 --> 26:34.000]  We got away very luckily.
[26:34.180 --> 26:35.400]  This could have been a lot worse.
[26:37.140 --> 26:40.940]  Basically, there's about 1,500 to 2,000 Tor relays.
[26:40.940 --> 26:42.180]  You should all run one.
[26:44.320 --> 26:45.980]  About 300 of them...
[26:46.920 --> 26:49.900]  Several of them were my machines, actually, which was very disappointing.
[26:51.040 --> 26:52.920]  They had weak keys.
[26:53.460 --> 27:03.360]  And anyone that was using a circuit that consisted entirely of those 300 relays, their traffic could potentially...
[27:03.360 --> 27:05.160]  Basically, if someone were to write a tool...
[27:05.160 --> 27:06.120]  Please don't write a tool.
[27:06.120 --> 27:11.060]  But if someone were to write a tool, it would be possible to decrypt it.
[27:13.180 --> 27:17.130]  We detected all of these machines basically instantaneously.
[27:17.920 --> 27:31.420]  When we learned about the vulnerability, we published the blacklist into the directory authorities so that clients that were using the Tor network would basically not select the 300 servers that had weak keys.
[27:31.420 --> 27:33.360]  So we protected our users right off the bat.
[27:33.540 --> 27:37.240]  And those 300 servers continued to run, but no one was talking to them or using them.
[27:37.560 --> 27:38.720]  Which was good.
[27:41.420 --> 27:47.860]  It's definitely bad to have a lot of servers all on a single platform in this regard.
[27:48.540 --> 27:50.140]  This also affected hidden services.
[27:50.340 --> 28:00.880]  So if you've ever used the .onion address, the identity keys for .onions, those hidden services were also generated in the same way as any other key.
[28:01.340 --> 28:03.600]  And as a result, those could be spoofed.
[28:03.700 --> 28:10.200]  And you could publish a descriptor to the network, and when the introduction was set up, it would be possible to do a man in the middle in theory.
[28:10.880 --> 28:15.020]  The only thing stopping that is the cryptographic key, and it was weak as well.
[28:16.640 --> 28:22.620]  Very bad things could have happened if four of the six directory servers had been vulnerable.
[28:22.620 --> 28:24.500]  This is why I said we got really lucky.
[28:26.460 --> 28:34.520]  So specifically the version three protocol, the directory authorities have to build a majority consensus.
[28:35.060 --> 28:39.620]  So three is bad, but four would have been a lot worse.
[28:39.780 --> 28:51.360]  Three, basically, you could say, like, well, I'm going to spoof these specific directory authorities, and I'm going to have these directory authorities prefer these servers and suggest these recommended versions.
[28:52.100 --> 28:57.460]  There's just things that you can do, because the Tor client does take a queue from the directory authority.
[28:57.780 --> 29:01.480]  And you can override it, obviously, in the config file, but many people don't.
[29:03.260 --> 29:07.020]  Luckily, though, there were only three, so we changed those keys immediately.
[29:07.780 --> 29:14.080]  But we continued to sign the network status with the old keys as well as the new keys until we then remove them.
[29:15.120 --> 29:18.600]  This was pretty much the best case scenario.
[29:18.820 --> 29:21.040]  It could have been a lot worse, and we were very lucky.
[29:21.480 --> 29:31.000]  And as far as Tor users that were using Debian, so previous stuff could be for any platform, but Tor users that were using Debian were affected by all of the above.
[29:31.700 --> 29:35.660]  New package, replace the weak keys, just like move them out of the way.
[29:36.060 --> 29:51.420]  But the worst thing is that it doesn't matter what Tor relays you were using, because basically you have the Diffie-Hellman problem, you have all of the other bugs, all of the entropy issues, and every cryptographic operation you perform that uses random numbers is pretty much broken.
[29:52.040 --> 29:56.680]  So if you were a Debian user using Tor, it was bad news for you.
[29:57.580 --> 30:01.100]  And so, again, please don't write the tool for decrypting that.
[30:01.200 --> 30:02.860]  It wouldn't help anybody that you want to help.
[30:07.620 --> 30:09.620]  So this is where I talk about SSL.
[30:10.200 --> 30:12.740]  So, what does it mean to be able to sniff SSL?
[30:13.000 --> 30:14.780]  You can spoof websites.
[30:15.360 --> 30:20.320]  All you need to do is, you know, see the traffic, and you can do this with DNS spoofing or ARP spoofing.
[30:20.480 --> 30:24.120]  So you can get the traffic either going through you, so you can sniff it, or so you can man in the middle it.
[30:24.620 --> 30:29.560]  And once you can decrypt SSL traffic, you get passwords, credit card numbers.
[30:29.560 --> 30:33.140]  And the best part about it is there's a great signal-to-noise ratio.
[30:33.380 --> 30:40.420]  People don't use SSL for things they don't really want to keep secret, so if you just sniff everything that's SSL, you get the more interesting things.
[30:41.240 --> 30:53.560]  Notable example for this, well, SSL is also used for, just because it's a, you know, a good protocol, and it's pretty easy just to say, well, just wrap SSL or TLS around it, and you have a secure transport.
[30:53.800 --> 30:55.360]  So we use it for various other things.
[30:55.400 --> 30:58.120]  For example, the updates for a German taxpaying software.
[30:58.120 --> 31:03.420]  That are stored in the same, under the same key as whitehouse.gov.
[31:04.180 --> 31:04.700]  Yes.
[31:05.120 --> 31:05.480]  Whoops.
[31:06.160 --> 31:06.520]  Whoops.
[31:08.160 --> 31:12.300]  All this is also used, or was also used with weak keys.
[31:13.540 --> 31:15.680]  So a little identity theft risk there.
[31:16.460 --> 31:17.100]  Could you hit that button?
[31:17.260 --> 31:17.400]  Right.
[31:17.480 --> 31:24.820]  You could push out updates to that software just knowing a weak key, and make the software update to whatever you want it to run.
[31:26.440 --> 31:35.520]  And so, when we're looking at this, you know, everyone is generating the blacklists, and H.D. Moore also created all the keys for SSH.
[31:36.200 --> 31:41.000]  But, you know, we're looking more at SSL because we thought that affected more people's day-to-day lives.
[31:41.200 --> 31:42.840]  And so we needed to generate our own keys.
[31:43.000 --> 31:44.580]  So, how do we do this?
[31:45.700 --> 31:50.340]  Obviously, this is for good and, you know, for exploitation and defense.
[31:50.580 --> 31:53.340]  You need to know what keys are weak so you can fix them.
[31:53.420 --> 31:57.140]  You need to be able to get the key if you want to read the traffic.
[31:57.140 --> 31:59.660]  And so we want it to be as exhaustive as possible.
[31:59.900 --> 32:04.560]  So the full cases were, basically, you have 15 bits for the process identifier.
[32:04.880 --> 32:06.520]  It's 32,000 possible keys.
[32:06.740 --> 32:11.540]  And then we generated them for each possible modulus size.
[32:11.700 --> 32:15.020]  So, 1,024, 2,048, 4,096.
[32:15.200 --> 32:18.340]  Although, in reality, everyone really just uses 1,024.
[32:19.580 --> 32:23.740]  What is it, like 3% use 2,048 bit keys of sites on the Internet?
[32:23.740 --> 32:28.120]  Yeah, and a few really paranoid people, 8,000 bits, but there's really no point in that.
[32:28.820 --> 32:28.960]  Yeah.
[32:29.020 --> 32:30.300]  They're as vulnerable, right?
[32:32.260 --> 32:34.800]  And also, there was, like we mentioned before, some of the entropy was...
[32:35.660 --> 32:39.480]  You know, the little entropy that remained was based on the computing platform.
[32:39.620 --> 32:45.120]  Notably, the ND-ness and the size of long, whether it was 32-bit or 64-bit processor.
[32:46.260 --> 32:48.020]  And so, you know, it takes a little time to generate the key.
[32:48.020 --> 32:54.580]  So, for instance, a 2,048-bit key takes, on average, 1.5 seconds to generate.
[32:55.140 --> 32:57.820]  A 1,024-bit is like 0.15 seconds.
[32:58.480 --> 33:01.840]  And we needed hundreds of thousands of these keys, and we needed them quickly.
[33:02.900 --> 33:04.780]  Also, because, you know, it was impatient.
[33:05.320 --> 33:08.180]  And waiting five days on a single machine kind of sucks.
[33:08.520 --> 33:13.640]  When, you know, news is going on, and you want to find out things immediately, it would be nice to have a lot more machines.
[33:17.140 --> 33:17.700]  So...
[33:19.820 --> 33:21.100]  We turned to Amazon.
[33:22.680 --> 33:23.960]  Amazon Web Services.
[33:26.540 --> 33:27.100]  Revolutionizing...
[33:27.100 --> 33:27.900]  Revolution...
[33:29.520 --> 33:30.540]  Cloud computing.
[33:30.920 --> 33:34.960]  Basically, there's three primary services that we made use of.
[33:35.180 --> 33:36.680]  It was one called S3.
[33:36.860 --> 33:38.900]  This is simple, scalable storage.
[33:39.060 --> 33:42.140]  It's web-addressable buckets of storage.
[33:42.280 --> 33:45.840]  You can store pseudo-files on there, and basically build a file system out of it.
[33:46.160 --> 33:49.740]  It's nice, you basically build for how much storage you use, for how long.
[33:49.980 --> 33:53.520]  So we were using a good amount of storage for not very long, so it was actually really cheap.
[33:54.500 --> 33:55.500]  Elastic Compute Cloud.
[33:55.640 --> 34:00.960]  This is the one that I've been waiting for a good excuse to use, and I saw this and I was like, oh, totally, I'm doing it.
[34:02.500 --> 34:07.320]  This lets you rent, basically, virtual machines in various sizes.
[34:07.320 --> 34:10.480]  You can get a 32-bit machine or a 64-bit AMD server.
[34:10.480 --> 34:16.940]  And depending on the number of cores that the server has, you pay for different amounts per hour.
[34:17.120 --> 34:19.460]  And so you basically are billed by machine hour.
[34:19.680 --> 34:22.520]  And so whenever you're not using them, you're not getting billed.
[34:22.620 --> 34:30.740]  But what this lets us do is, when you want a lot of computing fast, you can take up to 20 instances and just start them running.
[34:31.960 --> 34:37.280]  And to kind of coordinate all this, Amazon has a service called the Simple Queue Service.
[34:37.500 --> 34:45.600]  And this is a simple web service just to basically push a text blob onto the queue, pop a text blob off the queue.
[34:45.800 --> 34:48.000]  And you basically build your protocol off of this.
[34:51.140 --> 35:01.140]  And so generating the keys, how I did this, is one, I mean, I could have used a boot CD to run Ubuntu and get the vulnerable code.
[35:01.260 --> 35:03.840]  Or reinstall on a machine of mine.
[35:04.000 --> 35:10.820]  But when Amazon provides pre-built virtual machines, you can just use the vulnerable machines that they don't patch.
[35:10.980 --> 35:16.860]  They just create the machine once, and it's up to the user to basically bring it up, patch it as they need it, and then use it.
[35:16.860 --> 35:21.860]  And so there's some pre-made vulnerable machines that I could just generate all the keys on.
[35:22.760 --> 35:30.980]  And what I did is, I made this, used a Simple Queue Service, and kind of generated text strings representing units of work.
[35:31.700 --> 35:37.660]  So, how to, yeah, we're short on time, and that's boring.
[35:38.000 --> 35:39.420]  Basically, here's how long it took.
[35:40.840 --> 35:47.680]  Generated half a million keys, generated on the 32-bit machines, took four hours for eight bucks.
[35:49.160 --> 35:53.360]  And then all the 64-bit instances also took four hours for $16.
[35:53.880 --> 36:00.860]  So, you know, a bunch of on-demand CPU time, $24, decrypting your SSL traffic, priceless.
[36:05.030 --> 36:11.010]  So, what we wanted to do with these keys, other than just having them, finding vulnerable websites.
[36:11.330 --> 36:20.810]  So, the counter, or the second part to that experiment was fetching certificates from the Internet, and seeing whether they're vulnerable or not.
[36:21.290 --> 36:27.170]  We did a quick scan when we first learned about this, and found lots and lots of vulnerable sites.
[36:27.170 --> 36:29.570]  Fortunately, lots of them got updated.
[36:30.230 --> 36:37.190]  If you browse today, if you just crawl for certificates, you will see a lot of new certificates, just generated after May.
[36:37.370 --> 36:40.390]  So, that's a good indication that they were patched recently.
[36:40.790 --> 36:48.890]  But we still, even today, crawling, find thousands of weak sites, even big sites.
[36:48.890 --> 36:53.330]  And one of the major German banks had the HTTPS certificate vulnerable, for example.
[36:53.470 --> 36:55.350]  They were among the first to patch it, though.
[36:55.870 --> 37:08.090]  Now, if you want a large-scale fetch certificate, that goes a little bit beyond just web crawling, since the open... the key exchange is a little slow, and you have to paralyze a lot.
[37:09.210 --> 37:17.330]  We got some help on that from Lukas Grunwald, who has basically a small Amazon cloud, from what I understand.
[37:18.070 --> 37:19.290]  Just at home.
[37:19.610 --> 37:21.450]  And a lot of bandwidth, too.
[37:21.930 --> 37:30.810]  So, we got together a couple of lists of popular websites that could be security-related, such as All American Banks.
[37:31.610 --> 37:38.610]  There's an association that checks banks for certain features that they have on their webpages, and they publish a list of all the banks.
[37:38.790 --> 37:44.370]  Also started from, for example, the open directory, and just crawled, trying to find HTTPS links.
[37:44.370 --> 37:50.210]  And we went through millions and millions of websites and found all their wikis.
[37:50.490 --> 37:59.090]  And those, in theory, stay valid until they expire, unless the client now checks for whether they're a week or not.
[37:59.230 --> 38:00.630]  Usually, they expire within a year.
[38:01.390 --> 38:07.630]  Signing certificates, the ones we really wanted, they, unfortunately, only expire after, like, 10 or 20, 30 years.
[38:07.630 --> 38:13.910]  And those are the certificates that you can use to create valid, say, Verisign certificates.
[38:13.970 --> 38:16.870]  So, you could spoof Verisign, given one of these keys.
[38:17.110 --> 38:19.850]  Most of them, though, were generated during the dot-com bubble.
[38:20.050 --> 38:26.270]  And since they're valid for 10, 20 years, they haven't been replaced during the time this was vulnerable.
[38:28.090 --> 38:34.450]  Supposedly, there is a week signing certificate that a few people have, but we couldn't find it anywhere.
[38:34.450 --> 38:34.510]  Yeah.
[38:38.590 --> 38:38.930]  And...
[38:38.930 --> 38:40.610]  So, now we get to the...
[38:40.610 --> 38:47.890]  Putting together our list of wikis and the certificates we have, we put together a little demo.
[38:48.070 --> 38:49.190]  Yeah, we have a little demo here.
[38:49.310 --> 38:50.430]  I have to turn off the lolcat, I'm sorry.
[38:51.250 --> 38:52.010]  Wait, I need that, too.
[38:52.250 --> 38:52.710]  We need that.
[38:52.710 --> 38:52.910]  Oh, yeah.
[38:53.050 --> 38:53.190]  Sorry.
[39:08.810 --> 39:09.470]  All right.
[39:09.870 --> 39:10.210]  Okay.
[39:10.550 --> 39:10.890]  So...
[39:12.250 --> 39:12.770]  Here we go.
[39:13.810 --> 39:18.790]  Here's a site that happens to not really use SSL for anything, but is still vulnerable.
[39:20.530 --> 39:23.170]  So, let's check this out.
[39:23.430 --> 39:28.810]  So, to implement this attack, I took the tool called SSL Dump.
[39:29.030 --> 39:31.830]  Basically, it's like a packet sniffer.
[39:32.030 --> 39:35.910]  And I'll show you the various stages of the SSL protocol negotiation.
[39:36.470 --> 39:40.550]  But, obviously, it can't decrypt the traffic, because it's SSL.
[39:40.670 --> 39:41.230]  That's impossible.
[39:43.950 --> 39:48.650]  However, say you had, I don't know, a directory...
[39:51.690 --> 39:54.010]  Yeah, like, recursive.
[39:55.350 --> 39:55.790]  All right.
[39:55.890 --> 39:59.850]  Well, say you have, like, all these keys and a, you know, a big database full of all the hashes.
[39:59.850 --> 40:02.770]  So, we can basically just...
[40:02.770 --> 40:06.830]  What we do is just monitor the certificate going across.
[40:07.070 --> 40:10.530]  Once it goes across, check if it was generated using one of the weak keys.
[40:10.710 --> 40:12.090]  And if so, decrypt the traffic.
[40:13.310 --> 40:16.310]  So, call my tool Too Many Secrets.
[40:19.770 --> 40:22.950]  All it does is run SSL Dump sniffing for this host.
[40:25.510 --> 40:26.250]  All right.
[40:26.250 --> 40:29.310]  And then, in this window...
[40:33.290 --> 40:36.130]  I have a tool just to connect to it using the OpenSSL command line.
[40:40.000 --> 40:40.480]  All right.
[40:40.620 --> 40:41.200]  So, let's connect.
[40:43.420 --> 40:45.240]  This is really bad to use transparent terminals.
[40:45.760 --> 40:49.680]  But, basically, it shows, you know, a bunch of SSL protocol gobbledygook.
[40:50.160 --> 40:53.040]  Saying it exchange certificates, blah, blah, blah, blah, blah.
[40:53.600 --> 40:56.320]  And now, we're going to do a web request.
[40:57.940 --> 40:59.100]  If I can type today.
[41:00.820 --> 41:01.240]  Okay.
[41:01.460 --> 41:03.200]  So, this is in the OpenSSL window.
[41:04.400 --> 41:06.880]  Obviously, we can see that because we established the SSL connection.
[41:08.140 --> 41:13.500]  However, in the sniffing window, we can see that we have the traffic here as well.
[41:13.920 --> 41:16.800]  And it did this because it just grabbed the key and decrypted it on the fly.
[41:16.800 --> 41:25.080]  And so, with this tool, basically monitoring the network, whether local or doing ARP spoofing and monitoring the, you know, everyone on the network.
[41:25.300 --> 41:29.300]  If they connect to any site that is vulnerable, you have their traffic.
[41:30.620 --> 41:34.200]  And I'll be releasing this once I make the code not horribly embarrassing.
[41:37.850 --> 41:38.450]  Okay.
[41:38.630 --> 41:39.430]  Do you want to plug this thing?
[41:54.500 --> 42:02.840]  Now, getting back to the question of what can you do to defend yourself or your users, your systems against this threat?
[42:03.320 --> 42:10.040]  Well, optimally, SSL on the Internet would have been built to foresee this case.
[42:10.040 --> 42:15.820]  It's that some certificates get owned and then they need to be blocked.
[42:16.340 --> 42:24.700]  And there are countermeasures in the standards, such as revocation lists, just long lists of every certificate that has been owned.
[42:24.820 --> 42:26.420]  But they're not implemented properly.
[42:27.120 --> 42:37.260]  So, I think Internet Explorer 7, but only on Vista, is the only browser that has a half-baked OK implementation of this.
[42:37.340 --> 42:39.260]  Firefox, any of those, does not.
[42:39.260 --> 42:43.460]  So, if there are any Firefox developers here, please fix that.
[42:44.080 --> 42:51.060]  4C cryptographic keys may be being vulnerable and getting owned and help us block those.
[42:51.380 --> 43:06.160]  Now, since the browsers themselves don't have defenses, a lot of people have just generated those blacklists that we have generated on the Amazon Cloud and published those, for example, as a Firefox plugin.
[43:06.420 --> 43:08.560]  Now, Firefox is, I don't know, 20 megabytes.
[43:08.560 --> 43:12.860]  The blacklist, the list of all keys will be almost 500 megabytes.
[43:12.980 --> 43:18.280]  So, that would be a painful update, especially on some more embedded platforms.
[43:18.780 --> 43:20.540]  Is there a question that we need to take?
[43:20.660 --> 43:20.860]  Yes.
[43:21.380 --> 43:26.880]  From what I've heard, Firefox 3 will implement OCSP online certificate status protocol.
[43:26.880 --> 43:29.040]  Will that not help with this issue?
[43:29.240 --> 43:31.880]  That's an interesting protocol, in a bad way.
[43:32.500 --> 43:32.940]  Yeah?
[43:33.160 --> 43:34.500]  I know nothing about it.
[43:34.820 --> 43:41.000]  Every website you go to has to check the OCSP server whether or not the certificate's valid, so you're leaking your website.
[43:41.300 --> 43:52.340]  Yeah, so basically, it has these interesting privacy implications, where if you want to find out whether or not there's an issue with that certificate, you're going to have to report back that you're visiting that website.
[43:52.340 --> 43:57.760]  I mean, maybe if there was some sort of, like, decentralized anonymity network that you could route through, that might change that.
[43:59.740 --> 44:00.100]  Potentially.
[44:00.640 --> 44:01.760]  But, I mean, it doesn't...
[44:01.760 --> 44:05.340]  I mean, it seems like it's a good idea, but I wonder what will happen to...
[44:06.380 --> 44:14.960]  So, when you have this many problems, let's say, it seems like that's going to be asking a lot of questions.
[44:14.960 --> 44:17.020]  I hope the servers can take the load, I guess.
[44:17.560 --> 44:19.340]  You know, I'm sure that it's designed well.
[44:19.560 --> 44:21.960]  Like, software never has problems, so...
[44:22.940 --> 44:28.420]  Well, so, well, there are blacklists for SSL blacklists on the Internet now.
[44:28.640 --> 44:33.320]  So, the Firefox blacklist is condensed to, I think, about 30 megabytes.
[44:33.420 --> 44:37.300]  Still a painful update, but definitely much better than getting the entire key list.
[44:37.300 --> 44:42.120]  There are packets that prevent the SSH problems too, at least some of them.
[44:42.540 --> 44:45.500]  And I think Debian were the first to provide patches there.
[44:46.040 --> 44:48.480]  So, at least to congratulate on that.
[44:49.620 --> 44:55.620]  What these patches do is search your computer for weak keys and then ask you to replace the weak keys.
[44:55.700 --> 44:58.760]  Or even do it automatically if it's the host key, from what I understand.
[44:59.260 --> 45:02.240]  Now, this solves problem with user keys and host keys.
[45:02.440 --> 45:05.980]  But the Diffie-Hellman might still be vulnerable on the other end.
[45:05.980 --> 45:17.040]  So, if you are a Debian user and you patched everything, you replaced all keys, if you connect to another machine that is affected, that hasn't been patched yet, you have those problems.
[45:17.180 --> 45:23.400]  The SSH decoder program will be able to read your password and read everything that goes through the SSH.
[45:23.860 --> 45:26.500]  So, that problem is far from being fixed.
[45:26.600 --> 45:29.140]  It should be possible for someone to write a tool.
[45:29.140 --> 45:38.940]  I haven't seen anyone do this, but it should be possible for someone to write a tool that would connect to a server and do a Diffie-Hellman with that server and do that 32,000 times.
[45:39.340 --> 45:46.280]  Sometime well before 32,000 connections because of the birthday paradox, you should see a collision in the Diffie-Hellman parameters.
[45:46.480 --> 45:49.680]  And then you would know that the remote lib SSL has a problem.
[45:49.680 --> 45:55.780]  It shouldn't be very difficult to write that either because it's just like one or two steps in to the communication with the server.
[45:56.960 --> 45:58.620]  But no one has done that yet.
[45:58.820 --> 46:08.600]  But that's probably one of the last outstanding real big problems here because, as Carson was saying and as we said earlier, that's sort of the weakest link for the whole protocol.
[46:08.860 --> 46:13.260]  Which, to me, was surprising when I started learning a lot more about how the protocol worked.
[46:13.380 --> 46:16.780]  The idea that the Diffie-Hellman could be so, so, so important.
[46:17.140 --> 46:21.280]  When you have all the rest of the keys in play, it was kind of, whoops.
[46:23.820 --> 46:40.600]  Yeah, to conclude, in the grander scheme of things, what we have learned from this once again, I should say, is that open source software should be, not be patched just before it's shipped, but should be patched wherever it's developed.
[46:40.840 --> 46:44.220]  And if you find a bug anywhere, please tell whoever wrote the program.
[46:44.400 --> 46:50.600]  Give them a chance to either patch it, take your insights, or tell you that you're wrong and to please not touch it.
[46:50.600 --> 46:55.240]  And that is particularly true for crypto, where a lot of funny things go on.
[46:55.340 --> 46:59.080]  Who would ever read from a memory that you wouldn't, that you didn't write to?
[46:59.180 --> 47:02.420]  Well, it makes good sense in crypto.
[47:02.880 --> 47:05.140]  And, well, taking that a little further.
[47:05.360 --> 47:13.160]  So, to understand how strong your system is cryptographically, it doesn't suffice to look at what building block you use to make it secure.
[47:13.300 --> 47:23.260]  So, RSA 8000-bit can never be cracked in anybody's lifetime, but it is vulnerable to these exploits that we have shown.
[47:23.740 --> 47:30.480]  So, the security of a cryptographic system is really determined by the weakest link.
[47:30.680 --> 47:35.340]  And cryptographic keys are one of the most important building blocks, and they're often forgotten.
[47:38.820 --> 47:42.880]  As I've said, please implement revocation lists and all that.
[47:43.000 --> 47:51.920]  Key management is too important of an issue to just be ignored, and to always rely on the perfect secrecy of cryptographic keys.
[47:52.040 --> 47:57.100]  Keys get owned beyond this, just by people logging in and stealing the private portion of some keys.
[47:57.100 --> 48:03.380]  So, please help mitigate these problems by implementing the revocation list, at least for SSL.
[48:03.620 --> 48:17.580]  Now, if you do have ideas how to patch the SSH problem, the problems with Diffie-Hellman in the session keys, please contribute that back to the community, too, and help patch that last open big problem, as well.
[48:19.880 --> 48:20.840]  Oh, was that?
[48:21.020 --> 48:21.240]  I think that's...
[48:21.800 --> 48:22.840]  Thank you for attention.
[48:23.080 --> 48:23.420]  And we...
[48:23.420 --> 48:25.260]  I think we have some ten minutes for discussion.
[48:39.550 --> 48:40.250]  Hi there.
[48:40.490 --> 48:41.410]  A quick question.
[48:41.630 --> 48:48.410]  Maybe I was missing something, but is the blacklist the only way...
[48:48.410 --> 48:55.950]  Is that the best way to determine if the host, you know, could be broken over SSL?
[48:56.070 --> 48:57.050]  Isn't there a way to...
[48:57.050 --> 49:02.370]  Would there be a way to scan yourself on your own computer before you initiate a connection?
[49:02.630 --> 49:05.770]  You know, you're trying to connect to your online bank account or something like this.
[49:05.950 --> 49:11.230]  Rather than referencing a blacklist, could you determine that yourself on your own PC?
[49:12.110 --> 49:19.750]  Alternatively to a blacklist, you could have a very, very long list of all hosts that are known to have weak certificates, but the blacklist is probably smaller.
[49:22.590 --> 49:26.150]  So, it is probably the only workable solution.
[49:27.050 --> 49:29.090]  Since keys are more or less random.
[49:29.330 --> 49:31.830]  So, you can't compress them any...
[49:31.830 --> 49:34.310]  Beyond what the hashes already do.
[49:34.490 --> 49:38.550]  To give you an idea, all the uncompressed keys are 2.1 gigabytes.
[49:39.450 --> 49:41.230]  The blacklist of like...
[49:41.230 --> 49:41.270]  What?
[49:41.770 --> 49:42.650]  A handful of megs?
[49:42.810 --> 49:43.410]  Like 9 megs?
[49:43.910 --> 49:44.230]  Yeah.
[49:44.470 --> 49:47.990]  I think 30 by now since they keep adding different flavors of keys.
[49:48.230 --> 49:48.250]  Yeah.
[49:48.570 --> 49:52.110]  To understand what the blacklist actually is, think of it this way.
[49:52.110 --> 49:55.670]  You have the public component and it maps to a private key like a rainbow table.
[49:56.430 --> 50:03.530]  So, you hash the public component so when someone connects to a server, you can take that public key, transform it, and then do a lookup.
[50:03.650 --> 50:09.950]  And if you have a match, then you know that there's a secret key that can be derived by the processes we've described here.
[50:09.950 --> 50:13.430]  So, the blacklist is basically a hash of the public key fingerprints.
[50:13.950 --> 50:15.570]  I mean, depending on implementation.
[50:15.790 --> 50:18.070]  But that's like the simplest way to do it.
[50:18.210 --> 50:23.030]  So, you can't really check your own computer because the thing that you're looking for is the remote computer.
[50:23.150 --> 50:23.710]  I guess.
[50:23.830 --> 50:24.670]  Does that answer your question?
[50:25.050 --> 50:29.050]  I guess the process of generating the blacklist, why couldn't that be done?
[50:29.910 --> 50:41.210]  Well, the reason is because it is non-trivial to know exactly what PID, what architecture, and what NDN-ness the certificate was generated on.
[50:41.330 --> 50:44.950]  And you can't generate the certificate on the fly based on the public key fingerprint.
[50:45.170 --> 50:51.190]  But if you have a list of the public key fingerprints, then what you can do is reference that to the secret key by doing a lookup.
[50:51.190 --> 50:54.550]  And you can also store the parameters that generated that secret key if you want.
[50:54.750 --> 50:55.750]  And you could regenerate it.
[50:55.890 --> 50:59.670]  But it's not possible to take the public key and then know the secret key immediately.
[50:59.850 --> 51:01.350]  That would be a different problem.
[51:04.370 --> 51:05.410]  Could you use the microphone?
[51:06.370 --> 51:07.170]  There's a microphone.
[51:07.390 --> 51:09.070]  Well, we've got a bunch of people in line.
[51:09.330 --> 51:10.190]  So, yeah.
[51:11.610 --> 51:19.570]  Do you know of any resources for tracking down what products have shipped with what trusted root certs?
[51:19.570 --> 51:26.710]  So, there have been multiple root certificate authorities that have gone out of business and they're...
[51:26.710 --> 51:28.270]  Do you want to own a root certificate authority?
[51:28.490 --> 51:30.470]  Well, not necessarily, but I mean...
[51:30.470 --> 51:31.490]  Just cutting to the point.
[51:31.670 --> 51:32.170]  Yeah, kind of.
[51:32.170 --> 51:32.830]  We do too.
[51:33.070 --> 51:33.670]  Yeah, we do too.
[51:33.910 --> 51:34.750]  Yeah, so...
[51:34.750 --> 51:35.910]  We're working on it.
[51:36.570 --> 51:37.030]  Okay.
[51:37.210 --> 51:40.470]  There has to be like the properties got sold off when the companies went under.
[51:40.910 --> 51:44.330]  Does anybody actually track like where those keys went?
[51:44.610 --> 51:45.410]  Good question.
[51:45.610 --> 51:46.710]  Hopefully they got deleted.
[51:46.710 --> 51:49.950]  Have you ever looked at your certificate authority lists that are in web browsers?
[51:50.130 --> 51:51.490]  There's crap in there that you would...
[51:51.490 --> 51:51.590]  Yeah.
[51:51.690 --> 51:52.710]  You don't trust them.
[51:53.070 --> 51:55.150]  Like you look at it and you know that you don't trust them.
[51:55.330 --> 52:05.530]  And I mean, I'm certain that the easiest way to beat all of the PKI that's implemented with regards to SSL in a web browser is just to go and buy a CA that's already in a web browser.
[52:05.530 --> 52:12.990]  I mean, it's like, it can't be that much money for the amount of money that you could get as a return on your investment if you were really shady.
[52:13.170 --> 52:16.490]  And I'm certain that someone else has done that because it just makes sense.
[52:16.630 --> 52:17.890]  It's a perfect attack vector.
[52:17.970 --> 52:20.570]  The SSL trust model just needs like, you know, revision because...
[52:21.130 --> 52:22.610]  So all your browser tells you is someone...
[52:23.310 --> 52:25.050]  I'm not going to really tell you who unless you're really interested.
[52:25.270 --> 52:26.870]  Someone says that Citibank is Citibank.
[52:26.870 --> 52:34.090]  And for instance, I'd like to know if one day VeriSign is saying Citibank is Citibank and the next day it's Jim's bait and tackle on certificate authority.
[52:35.950 --> 52:36.470]  Yeah.
[52:36.670 --> 52:40.490]  I mean, an interesting thing also comes from chaining.
[52:41.030 --> 52:41.670]  SSL chaining.
[52:41.970 --> 52:43.710]  I mean, you could...
[52:43.710 --> 52:49.950]  Do you remember the Microsoft constraints vulnerability that Mike Benaham published some number of years ago?
[52:51.030 --> 52:51.550]  Basically...
[52:51.550 --> 52:51.710]  Yes, he does.
[52:52.010 --> 52:52.890]  Yeah, you do.
[52:53.070 --> 52:53.890]  I'm glad you do.
[52:54.010 --> 52:54.410]  That's great.
[52:55.010 --> 52:59.290]  Essentially, the issue is that you could get a certificate issued to you and then you could sign it.
[52:59.470 --> 53:05.250]  And even though you weren't really authorized to sign it, Microsoft would follow the chain and say you were authorized.
[53:05.550 --> 53:09.790]  So Mike published a demo of, I think it was Amazon.com.
[53:09.930 --> 53:15.970]  You visited like, I think, thoughtcrime.org and on a certain port and it was Amazon.com.
[53:16.870 --> 53:17.310]  Awesome.
[53:17.450 --> 53:22.210]  Because Microsoft's Internet Explorer just followed the chain and it didn't care that that was an invalid chain.
[53:24.510 --> 53:25.090]  Thanks.
[53:25.470 --> 53:26.950]  One more question.
[53:27.690 --> 53:28.690]  Unless you're fast.
[53:29.110 --> 53:34.130]  Are you aware of any disk encryption applications that could be affected by this?
[53:34.250 --> 53:34.390]  Yes.
[53:34.510 --> 53:35.010]  Next question.
[53:38.090 --> 53:38.670]  Seriously.
[53:39.730 --> 53:47.470]  I was wondering what the distribution of the vulnerable entropy is because you're not really going to have many PIDs at a high value.
[53:47.610 --> 53:49.510]  Is the problem actually worse than you'd expect?
[53:49.510 --> 53:49.910]  Yes.
[53:50.170 --> 53:50.930]  Next question.
[53:53.810 --> 53:57.150]  Have you guys written a nice tutorial article like this?
[53:57.310 --> 54:07.470]  Say, in a wiki kind of thing where if you don't know this stuff and you want to learn it, you mentioned some term, you link off to it and I can find out what that is, et cetera.
[54:07.750 --> 54:09.590]  Or has someone else done this?
[54:09.590 --> 54:16.610]  So the Debian wiki, wiki.debian.org slash ssl keys, ssl k in uppercase e y.
[54:16.610 --> 54:17.830]  Can you do that very slowly?
[54:19.530 --> 54:34.910]  Wiki.debian.org slash uppercase s, uppercase s, uppercase l, uppercase k, e, y, s in lowercase.
[54:35.890 --> 54:37.170]  The k is uppercase.
[54:37.330 --> 54:37.690]  Yes.
[54:38.490 --> 54:39.090]  That's correct.
[54:40.070 --> 54:52.490]  If you look at the Debian wiki, you'll see that they, specifically to address the other two questions that I just whizzed through there, it lists basically all the different applications that Debian had issues with.
[54:52.590 --> 54:56.690]  They talk about encrypted file systems, they talk about password safes, they talk about all sorts of stuff.
[54:56.690 --> 55:08.790]  So basically, if you're curious about a specific application on Debian, and you wonder how it will behave off of Debian, because there's possible things that are similar to the way the ssh keys are used, who knows?
[55:08.970 --> 55:12.910]  Like, it's possible, like, there's, the devil's in the details, obviously.
[55:13.110 --> 55:16.530]  So it's www.wiki.debian.org.
[55:16.530 --> 55:16.890]  No w.
[55:17.250 --> 55:19.010]  S-T-F-W.
[55:19.690 --> 55:20.690]  S-T-F-W.
[55:20.890 --> 55:21.690]  Search the f*cking web.
[55:23.610 --> 55:24.070]  Sorry.
[55:24.070 --> 55:24.830]  We gotta go.
[55:24.950 --> 55:25.290]  Thanks.
[55:25.690 --> 55:26.210]  Thank you.
[55:33.200 --> 55:34.760]  That went a lot better than I expected.
[55:35.600 --> 55:36.160]  Yeah, it's fun.
[55:36.680 --> 55:36.800]  Yeah.
[55:37.880 --> 55:38.060]  Sorry?
[55:38.640 --> 55:38.780]  Yeah.
[55:39.200 --> 55:39.940]  That went early this morning.
[55:40.160 --> 55:40.260]  Yeah.
[55:40.680 --> 55:42.040]  But it's definitely here.
[55:42.260 --> 55:42.720]  Thank you.
[55:43.520 --> 55:46.360]  You can just, oh, he worked for this.
[55:46.900 --> 55:48.400]  He works for an SSL company.
[55:48.880 --> 55:49.240]  Awesome.
[55:49.480 --> 55:51.820]  Which, do you guys have a vulnerable root certificate?
[55:52.620 --> 55:53.240]  Are you sure?
[55:53.280 --> 55:53.820]  Give us an email.
[55:54.140 --> 55:55.560]  Can we see you can't admit it?
[55:55.860 --> 55:56.160]  No.
[55:57.560 --> 55:57.740]  Yeah.
[55:57.740 --> 55:57.860]  Yeah.
[55:58.680 --> 55:58.920]  Alright.
[56:00.380 --> 56:01.700]  And we also picked up.
[56:01.760 --> 56:02.660]  We want to take for the cheese.
[56:02.900 --> 56:03.060]  Thank you.