[00:02.240 --> 00:03.060] Hello, HOPE. [00:04.340 --> 00:06.460] We've got some time yet until the next presentation. [00:06.820 --> 00:12.440] But before then, I just wanted to remind you all of what it was like to watch defrag happen on DAS. [00:12.640 --> 00:18.940] And you would see all the little blocks, and you would see the data moving from all the blocks to the empty spaces, and it would efficiently fill in the empty spaces. [00:19.300 --> 00:20.860] We want to try and do that with the seats. [00:22.260 --> 00:31.700] So, if you're sitting near empty seats, and it's possible for you to maybe move in and fill those and open up other strings of seats for everyone coming in, that would be very much appreciated. [00:32.340 --> 00:35.080] And also, if you are coming in, look around for empty seats. [00:35.400 --> 00:38.660] Don't be afraid to ask people to move out of the way so you can get to the empty seats. [00:40.000 --> 00:43.620] And if any fights break out, that's your own problem. [00:46.040 --> 00:48.280] Okay, we've got a couple of minutes until the next presentation. [00:48.560 --> 00:50.220] But until then, enjoy some more music. [01:45.840 --> 01:46.620] Good crowd here. [01:46.960 --> 01:50.860] Okay, I've got a few brief announcements to make before we get on to our next presentation. [01:51.900 --> 01:55.000] The important one to know right now is that this place is full. [01:55.860 --> 01:57.740] So, if you can find an empty seat, take it. [01:57.860 --> 02:00.440] If you can find some standing room and they're still letting you in, take it. [02:00.580 --> 02:04.900] But if you leave before the end of the presentation, you will not be let back in. [02:05.940 --> 02:08.980] Because we just won't want you here anymore. [02:11.540 --> 02:13.220] A couple other things to know about. [02:13.320 --> 02:14.700] Just some general con stuff. [02:14.700 --> 02:18.880] If you want to stick stuff to the wall around the conference, there are lots of posters of all types around. [02:19.480 --> 02:20.060] That's fine. [02:20.280 --> 02:21.140] We're all for that. [02:21.320 --> 02:22.560] But do not use your own tape. [02:22.700 --> 02:23.820] Use our blue painter's tape. [02:24.200 --> 02:28.080] If you go to our security desks or info desks, they'll have some there and they'll just give you some. [02:28.760 --> 02:32.700] Because that's the kind of tape that we can use on these walls in this hotel. [02:32.700 --> 02:36.760] So, yeah, take care of the walls and we can do this again next time. [02:37.720 --> 02:42.760] Speaking of taking care of things, conferences have what's called the 5-2-1 rule. [02:43.020 --> 02:44.440] If any of you are familiar with that. [02:44.620 --> 02:46.260] And if you're not, I'll explain what it is. [02:46.400 --> 02:52.820] It means every day of a conference, you should get five hours of sleep, two square meals, and one shower or bath. [02:54.260 --> 02:56.760] This is the way you take care of yourselves and those around you. [02:58.920 --> 03:01.980] So, we're, I think, just about a capacity. [03:02.240 --> 03:11.840] So, without much further ado, it's my pleasure to present HTTP Must Die with Parker Higgins and Yang Zhu. [03:12.140 --> 03:12.740] Ladies and gentlemen. [03:30.740 --> 03:32.880] HTTP must die. [03:36.520 --> 03:37.360] Hi, everybody. [03:37.520 --> 03:38.620] I'm Parker and this is Yang. [03:39.280 --> 03:41.180] We work at the Electronic Frontier Foundation. [03:41.180 --> 03:43.100] I'm an activist there and she's a technologist. [03:43.100 --> 03:47.820] And today we're going to be talking about HTTPS and web encryption. [03:48.120 --> 03:52.180] And the many shortcomings of unencrypted web protocols. [03:54.500 --> 03:56.140] So, thank you for coming. [03:56.620 --> 04:03.540] And if, just quickly, do people here know what the Electronic Frontier Foundation is? [04:03.860 --> 04:04.500] Or your work? [04:05.840 --> 04:09.140] We can't actually see you, so it's okay if you don't raise your hands. [04:10.440 --> 04:16.800] So, yeah, EFF, we do a lot of things around preserving people's privacy and anonymity online. [04:16.800 --> 04:27.260] And so, we'll talk a little bit about the things that we do in law and in activism and in code to make people's online and technical experience a little more private. [04:28.880 --> 04:33.500] All right, so how many people here have ever felt insecure? [04:34.560 --> 04:39.620] Because you're lonely, you lost your job, you're not happy with yourself for some reason. [04:41.700 --> 04:49.980] So, I've never actually felt any of those things, but the other day I was visiting Quora, Quora.com, which many people visit. [04:49.980 --> 04:55.300] And I noticed they're serving their login page over plain HTTP. [04:55.880 --> 05:06.360] And that's bad, because even if you're sending things over HTTPS, the attacker can modify the form and then change their target to whatever they want. [05:06.540 --> 05:13.540] So, in their case, it was even worse because they were actually just sending usernames and passwords in plain HTTP. [05:14.640 --> 05:15.620] Shame on them. [05:16.740 --> 05:18.460] And by the way, it's 2014. [05:19.060 --> 05:21.400] This went out of fashion in like 2001. [05:22.720 --> 05:24.680] And they're asking me to use Flash. [05:26.120 --> 05:27.140] You, right. [05:27.700 --> 05:29.940] So, I mean, you guys aren't hope. [05:30.120 --> 05:33.480] I'm pretty sure most people here know why HTTP sucks. [05:33.860 --> 05:36.700] But to go over it again, there's no data confidentiality. [05:37.600 --> 05:44.300] So, the person at the coffee shop or the person sitting next to you right now can read what you're sending over the wire. [05:44.800 --> 05:48.300] No data integrity, so they can tamper with it and you can't detect anything. [05:49.480 --> 05:50.900] And there's no server authentication. [05:51.080 --> 05:55.460] So, if you're visiting HTTP Quora.com, it could be anything. [05:57.600 --> 05:59.080] So, given all of this... [05:59.300 --> 05:59.560] What? [05:59.780 --> 06:00.520] Could be Quora. [06:00.540 --> 06:01.400] Could even be Quora. [06:01.580 --> 06:02.040] Oh, my God. [06:02.600 --> 06:05.540] So, given all of this, why are we still using HTTP? [06:07.480 --> 06:08.120] Okay. [06:08.440 --> 06:10.500] So, people say HTTPS is hard. [06:10.620 --> 06:11.580] It's not actually true. [06:11.860 --> 06:15.080] But people might say, certificate authorities are gross. [06:15.380 --> 06:16.680] They kill elephants. [06:17.000 --> 06:19.340] They are people we don't trust. [06:19.840 --> 06:24.680] They can be corrupted by governments that say issue a certificate for something. [06:25.060 --> 06:27.240] And we've seen evidence of this in the wild. [06:27.520 --> 06:28.700] So, that's a real concern. [06:28.940 --> 06:30.940] Certificate authorities suck a lot. [06:30.940 --> 06:33.600] But mixed content is bad. [06:33.800 --> 06:41.820] So, if you're a news site and you're, you know, you've switched over to HTTPS, you're probably serving ads that don't support HTTPS. [06:42.200 --> 06:51.080] So, you have to support HTTP and then you have HTTP JavaScript on an HTTPS page and then it's not, you know, no security guarantees anymore. [06:52.500 --> 07:01.500] Many advertisers don't yet support HTTPS and that's why news organizations have been slow to transition to HTTPS by default. [07:01.940 --> 07:17.180] And if you're using a CDN, sometimes Alchemai for instance, they can charge extra for HTTPS because they say, oh, you know, Windows XP doesn't support SNI and so we need extra IP addresses and so forth. [07:17.920 --> 07:23.280] And so, because, and you, you know, if you have set up HTTPS, you have to remember to renew a cert. [07:23.580 --> 07:31.700] So, I recently saw a statistic that something like, like 40% of SSL certs in the wild were set to expire within a few months. [07:34.940 --> 07:35.420] Great. [07:35.760 --> 07:36.280] Let's go on. [07:38.080 --> 07:41.320] So, let's start the talk with part one. [07:41.500 --> 07:43.600] Why are we interested in HTTPS? [07:43.720 --> 07:44.640] Why do we start there? [07:44.640 --> 07:49.820] And I think the obvious answer is because we know they are interested in HTTP. [07:51.220 --> 07:54.760] This slide is a Snowden slide. [07:54.760 --> 07:59.700] Of course, it's been in vogue for a year now to have slides that contain images of slides. [08:00.140 --> 08:02.420] And we will not break from that trend. [08:02.860 --> 08:07.660] We know that the NSA is interested in HTTP because they said that. [08:09.000 --> 08:12.680] HTTP, it touches, you know, almost everything that users do. [08:12.680 --> 08:16.480] And, and, and we saw this in the XKEYSCORE leak. [08:16.660 --> 08:23.580] And more, more particularly, we saw that they drill down to, to search terms and news sites. [08:23.860 --> 08:38.540] And here, here, Glenn is quoted as saying, As one slide indicates, the ability to search HTTP activity by keyword permits the analyst access to what the NSA calls nearly everything a typical user does on the Internet. [08:38.540 --> 08:40.900] So, this matters a lot. [08:43.220 --> 08:52.120] And it's important to note that HTTPS and the commitment to HTTPS doesn't stop at the lock on the user's browser. [08:52.680 --> 08:55.660] You have to be encrypting the, the whole way. [08:55.820 --> 08:58.920] This, of course, is, is from the, the muscular leak. [08:59.140 --> 09:04.200] I, I think most people will have seen the, the evil smiley by SSL added and removed here. [09:04.200 --> 09:11.580] Um, and that comes from a failure to be using, uh, HTTPS or encryption along the whole path. [09:11.720 --> 09:13.320] In this case, between data centers. [09:13.540 --> 09:18.540] And when you've got an agency with a footprint as large as the NSA, that, that actually matters. [09:21.380 --> 09:24.960] Uh, so how many of you have seen this article from The Intercept? [09:24.960 --> 09:26.220] So, I know Michael Lee. [09:26.440 --> 09:27.160] Oh, quite a few. [09:27.320 --> 09:30.200] I can't really see anything, but, um, kind of see some hands. [09:30.360 --> 09:33.460] So, Michael Lee, who's in the audience, actually works on The Intercept. [09:33.520 --> 09:35.740] And I'm sure, uh, can tell you all about it. [09:35.840 --> 09:41.080] But anyway, so they published this really, this article that was really shocking to us a few months ago. [09:41.300 --> 09:48.660] That says, NSA has these servers set up to implant, uh, potentially implant millions of devices with malware. [09:49.620 --> 09:52.860] That's pretty scary, and that's a lot of devices. [09:53.580 --> 09:56.580] So, how does HTTP traffic enable this? [09:57.200 --> 10:03.140] Um, so here is a slide, within a slide, from the NSA's Quantum program. [10:03.600 --> 10:16.040] Um, so what you see here is a diagram of the target, which could be, you know, me, or you, or Parker, or anyone here, logging into their Yahoo Mail account, because maybe it's like 2008, uh, and we're still using Yahoo Mail. [10:16.320 --> 10:22.580] Um, and, uh, so they log in, and Yahoo Mail, maybe at that time, isn't HTTPS by default. [10:22.580 --> 10:25.280] Even though it does a 302 redirect or something. [10:26.080 --> 10:32.900] Um, so, um, the NSA server, or, um, yeah, the NSA server can see that they're going to Yahoo. [10:34.080 --> 10:39.760] Um, and they, uh, this sends a signal to what's called a Fox Asset server. [10:39.960 --> 10:49.400] And the Fox Asset server does the work of sending back malicious packets to their users' devices, uh, for, uh, like, spoofed to look like Yahoo packets. [10:49.400 --> 11:03.680] Um, so in essence, um, by putting these, uh, these, like, packet ejection servers at, um, strategic geographic locations, um, they can exploit this race condition and get to the target's computer before the real Yahoo packets. [11:04.500 --> 11:14.540] Um, and this, uh, this, uh, packet ejection will, like, exploit some sort of vulnerability in browsers and, um, and implant the malware. [11:15.220 --> 11:16.440] And this is quite scary. [11:16.720 --> 11:24.480] So you might be asking, so, uh, millions of computers, you know, maybe they're doing sort of targeting, you know, like, targeting people that they think are suspicious. [11:24.480 --> 11:26.600] So what would they be using for targeting? [11:26.900 --> 11:29.720] And it turns out they're using things like cookies. [11:30.160 --> 11:32.520] Like, Google cookies, Yahoo cookies, et cetera. [11:32.980 --> 11:43.240] Um, because many services like Google, even if they're using HTTPS by default, uh, they're leaking your identity all over, uh, because they have not secured cookies. [11:43.240 --> 11:52.520] So, um, if you don't set the secure flag on a cookie, as many of you know, um, another, uh, another, uh, a man-in-the-middle can say, I am Google.com. [11:52.660 --> 11:54.480] Send me all the cookies for Google.com. [11:54.880 --> 11:57.740] And they'll read all your Google cookies, which are really unique. [11:57.940 --> 11:59.680] And they can even set cookies for you. [11:59.800 --> 12:03.620] They can say, um, set this cookie for this, uh, target so I can look at them later. [12:04.420 --> 12:08.800] So, cookies are being used as selectors, in this case. [12:08.980 --> 12:10.140] Plain HTTP cookies. [12:10.360 --> 12:12.940] Um, we also, uh, they also use some browser selector. [12:12.940 --> 12:17.140] We don't know what code name Silly Bunny is, but we've chosen to illustrate it with a Silly Bunny. [12:17.140 --> 12:20.480] Yeah, so we asked, we asked some lawyers, and like, no one knew what Silly Bunny was. [12:20.600 --> 12:23.400] If anyone knows what Silly Bunny is, please tell us. [12:23.800 --> 12:25.020] Uh, we'd really like to know. [12:25.900 --> 12:28.300] Right, so, so let's, let's reiterate that. [12:28.480 --> 12:33.880] So, unencrypted cookies, we used to think cookies are bad because advertisers use them to track us around the web. [12:34.200 --> 12:41.480] Now we know they're also bad because they're used as weapons for NSA to decide who to target with malware. [12:44.540 --> 12:49.560] So, we, we know that there's a, uh, a privacy reason and a security reason. [12:49.560 --> 12:53.420] But there's also another really important reason to be using, uh, HTTPS. [12:53.740 --> 12:55.860] And it's maybe one that doesn't get as much attention. [12:56.080 --> 12:57.880] And it has to do with censorship. [12:57.880 --> 13:03.320] So, when we talk about something like the, the great firewall of China, there's a number of ways in which it works. [13:03.560 --> 13:07.200] But one of the ways it works is by doing, uh, keyword filtering. [13:07.440 --> 13:14.360] By, uh, drilling down on the contents of a particular web page or of a page within a site. [13:14.560 --> 13:18.980] So, you know, you can access a newspaper, but not necessarily the offending article. [13:18.980 --> 13:30.680] Um, and the way that HTTPS addresses this is that, uh, when you, uh, when you make an HTTPS connection, only the host is, uh, is, uh, is available in the, in the clear. [13:31.220 --> 13:39.220] Um, so if you're looking at an article, for example, on the intercept here, uh, a man-in-the-middle can know that you're looking at something on first look. [13:40.140 --> 13:45.840] Uh, but they don't necessarily know which, uh, which part of first look or even which, which article. [13:45.840 --> 13:48.000] And there's a, there's a big asterisk next to that. [13:48.160 --> 13:51.900] So this is, this is true for, uh, for all sorts of sites. [13:52.080 --> 13:53.820] A big example is Wikipedia, of course. [13:54.040 --> 14:01.840] Uh, it means something different to be looking at Wikipedia than to be looking at an article on, you know, something in particular, uh, or inflammatory. [14:02.160 --> 14:08.960] But the big asterisk there is that that, uh, is still vulnerable to things like metadata analysis. [14:09.240 --> 14:19.580] So if each article has a distinct file size, uh, then you can, you can get around this by just, measuring the size of the files that are being transferred and you can know which article people are looking at. [14:19.820 --> 14:21.600] Um, there are ways of avoiding that. [14:21.700 --> 14:24.580] You can do padding, um, but that has pros and cons. [14:24.820 --> 14:32.880] Uh, the important part here is that this kind of, uh, that HTTPS makes that kind of attack much more sophisticated and expensive. [14:32.900 --> 14:39.240] And so even if it's not perfect, uh, it, it does a good job of, of, um, protecting privacy. [14:39.240 --> 14:51.300] But the censorship angle here is that, uh, it forces somebody who wants to block certain keywords to make the decision to block an entire site or not. [14:51.560 --> 14:53.320] And we've actually seen this play out. [14:53.760 --> 14:58.340] So, uh, last year GitHub was, for a little while, blocked in China. [14:58.840 --> 15:07.880] The entirety of GitHub, because it's HTTPS, was blocked because there were, um, the, the, the leading belief is that there were a handful of repositories that had something offensive. [15:08.160 --> 15:12.660] And so the, the only solution, because you can't block those repositories, is to block the entire site. [15:12.980 --> 15:16.960] And, of course, the Chinese developer community was not very happy about this. [15:17.060 --> 15:17.980] And they were very vocal. [15:18.160 --> 15:21.320] And they said, uh, that, that, you know, we can't do our work. [15:21.400 --> 15:23.200] And so, uh, there was a backlash. [15:23.460 --> 15:31.900] And that backlash forced, uh, forced the, the hands of the Chinese censors to say, okay, we'll, we'll let the whole thing go, including, uh, including these repositories we don't like. [15:31.900 --> 15:39.680] And there's a quote from a prominent Chinese developer who said he compared the blocking of GitHub to trying to catch a mouse by burning the entire house down. [15:41.760 --> 15:44.740] Forcing that decision is a good position to be in. [15:44.980 --> 15:49.800] To release the mice into the house and say, well, your only option is to burn the whole house down. [15:49.960 --> 15:53.800] And that puts the blame really squarely where it belongs on the sensors. [15:54.160 --> 15:58.920] So that's an important story with a good conclusion. [15:58.920 --> 16:03.760] There's one that didn't end as well, which is the story of Google Reader. [16:04.800 --> 16:07.960] Similarly, Google Reader was at a path. [16:08.060 --> 16:08.920] It wasn't a subdomain. [16:09.040 --> 16:10.440] So it was google.com slash reader. [16:10.700 --> 16:17.020] And so countries had to choose whether they were going to block all of Google services or allow reader. [16:17.200 --> 16:20.340] And of course, reader could make connections to other sites. [16:20.380 --> 16:27.260] And so people in Iran were able to read the news from around the world by accessing it through reader. [16:27.260 --> 16:31.460] And it made the censors decide, do we want to block everything Google? [16:31.620 --> 16:32.820] And for the most part, they didn't. [16:33.700 --> 16:36.100] There was, you know, one or two weeks where they did that. [16:36.240 --> 16:39.440] But for the most part, reader was a way to access this news. [16:39.580 --> 16:40.620] And this is really important. [16:40.900 --> 16:43.980] In Iran, there's estimates that one in three news sites are blocked. [16:44.220 --> 16:47.440] So this was an easy way for people to get around that censorship. [16:47.940 --> 16:49.060] And, you know, now it's gone. [16:53.910 --> 16:59.930] So here's a quote that I really like from our friend Nicholas Weaver, who I think sums this up really well. [17:00.170 --> 17:09.430] The only self-defense from all of these things above is universal encryption, which is difficult and expensive, but unfortunately necessary. [17:10.670 --> 17:13.250] So, and we know why it's necessary. [17:13.350 --> 17:14.650] There's another great advantage. [17:14.670 --> 17:28.770] If you run a news site and you turn on HTTPS, the ACLU's Chris Segoyan has offered a bottle of whiskey to any admin at a news org that switches websites to HTTPS by default. [17:28.890 --> 17:36.190] So not only are you defending your reader's privacy and security, but also you can get a drink off Chris off of it. [17:36.190 --> 17:40.270] I think Chris might be here right now, by the way, so you could even get it from him. [17:40.290 --> 17:41.170] Let's bankrupt him. [17:41.470 --> 17:41.890] Let's... [17:43.210 --> 17:44.170] Let's go nuts. [17:46.730 --> 17:52.370] Okay, so this talk was actually meant to be a really optimistic, happy one. [17:52.390 --> 17:54.290] And I think it's going to end up being that way. [17:54.530 --> 18:02.190] But I think because it's nice to be cautious, part two is called Not Everything Sucks Sometimes Probably. [18:03.250 --> 18:06.610] Yeah, and we'll see why not everything sucks sometimes probably. [18:08.090 --> 18:13.470] So one way that we look at this, the way that things don't suck, is through the Encrypt the Web Report. [18:13.670 --> 18:16.030] And this is, it's just a sampling. [18:16.330 --> 18:25.650] It's, you know, we look at a handful of websites, services that people use, and we measure how those sites are doing in terms of encrypting user data. [18:25.650 --> 18:33.010] And so you can see the first category is, this is just, by the way, this is a long chart that I've just split up into two. [18:34.270 --> 18:38.430] Encrypts data center links, which we saw matters because of the muscular attack. [18:39.430 --> 18:44.490] Supports HTTPS, and then the next two categories are how well are they doing HTTPS. [18:44.990 --> 18:52.770] And then the last one is start TLS for encrypting user emails in transit, which we'll talk about a little bit later. [18:52.770 --> 19:00.410] And really the exciting thing here is that we started with a lot of, a lot of gray and red. [19:00.790 --> 19:06.490] And it's gotten over the last, we've been running it for about six or seven months, it's gotten a lot more green. [19:06.790 --> 19:14.130] We've gotten a bunch of sites that have started rolling out HTTPS and doing it well and perfect forward secrecy. [19:14.350 --> 19:21.850] And these things, you know, in response to the news cycle, in response to someone pushing on them and saying, you know, your users deserve better. [19:23.530 --> 19:29.670] One major example of this was Facebook in, you probably can't see the date, but it's July 2013. [19:29.710 --> 19:35.250] So this is the month after the Snowden revelation started, switched on HTTPS by default. [19:35.510 --> 19:38.350] It was, most users had it before, but it's by default. [19:38.490 --> 19:42.790] And this is a huge amount of connections that are now encrypted. [19:45.070 --> 19:47.790] We saw Google made an adjustment. [19:48.570 --> 19:59.190] And HTTPS protects not just the contents of the page, but also if you go from an HTTPS site to an HTTP site, there's an extra measure of privacy added by your browser will blank out the referrers. [19:59.510 --> 20:04.210] So in search engine watch, they're just upset that they stopped getting keyword data. [20:04.210 --> 20:07.830] But for users, that's actually an extra level of privacy. [20:08.070 --> 20:12.510] Oh, by the way, the timestamp on this is September 2013? [20:13.010 --> 20:13.990] Yeah, September 2013. [20:14.490 --> 20:15.170] Wow, thank you, Snowden. [20:15.430 --> 20:16.930] Yeah, the Snowden effect. [20:19.870 --> 20:21.790] So it's not just web browsing. [20:22.010 --> 20:22.930] So there's also email. [20:22.930 --> 20:39.930] And email SMTP can optionally use an encryption protocol called StartTLS, which is opportunistic, which means like a server can advertise, I support encryption, and then the other side will upgrade to TLS. [20:40.910 --> 20:42.070] But it's unauthenticated. [20:42.410 --> 20:46.590] And a man-in-the-middle can downgrade by saying the side doesn't support TLS. [20:46.710 --> 20:51.890] And it'll just fall back to plain text because you really want your mail to be delivered usually. [20:52.970 --> 21:00.530] So my colleague Peter made this awesome, although somewhat confusing looking chart from Google's data. [21:00.710 --> 21:03.190] So I don't actually know why there's this like periodicity. [21:04.730 --> 21:10.630] But on the whole, it looks like StartTLS usage is rising pretty well. [21:10.770 --> 21:17.870] So since December 2013, which is when this chart starts, there's been a 33% to 58% increase. [21:18.170 --> 21:20.210] And that's really, really great. [21:20.210 --> 21:25.390] And this has been... similar statistics have been shown by Facebook's data. [21:25.710 --> 21:36.290] So, you know, if you run a mail server, you can actually do an analysis like this yourself because you can look at the percentage of inbound and outbound connections that are using StartTLS. [21:36.670 --> 21:41.310] And if you find out, you should send it to EFF because this data is really hard to get. [21:41.550 --> 21:47.330] Like we can't just scan the web and like see like what mail servers are using inbound and outbound StartTLS. [21:47.330 --> 21:51.490] Yeah, so it was really nice to get this data released by Google and Facebook. [21:51.910 --> 21:53.950] And we always like to hear more. [21:55.750 --> 22:07.170] So after all of this, there was this report recently from Wired, well, reported on Wired that said, encrypted web traffic more than doubles after NSA revelations. [22:07.230 --> 22:08.370] That's pretty dramatic. [22:08.370 --> 22:10.550] But what do I actually mean by that? [22:11.110 --> 22:11.670] Next slide. [22:12.390 --> 22:29.470] So if you read the report, it says that between pre-Snowden and after Snowden, the percentage of overall web traffic in each of these continents that is encrypted has gone from 2.29 to 3.8% in North America. [22:29.650 --> 22:30.510] It's pretty good. [22:30.850 --> 22:33.590] In Europe, it's gone from about 1.5 to 6%. [22:33.590 --> 22:38.850] But in Latin America, it's gone from 1.8 to 10.37% just in one year. [22:40.170 --> 22:41.050] That is... [22:41.050 --> 22:42.590] Yeah, like that deserves applause. [22:42.870 --> 22:42.890] Yeah. [22:42.950 --> 22:43.930] I would applaud for that. [22:45.570 --> 22:51.910] And a lot of that is due to large service providers like Google and Facebook doing their part and starting to encrypt things by default. [22:52.690 --> 22:55.150] But that is super, super significant. [22:58.310 --> 22:59.450] So, part three. [22:59.950 --> 23:01.070] What is next? [23:04.530 --> 23:05.770] We've been doing really well. [23:06.050 --> 23:08.110] But, you know, there's always things we can be doing better. [23:08.470 --> 23:10.150] And part three is supposed to be about... [23:11.090 --> 23:12.350] You know, so you're at HOPE. [23:12.490 --> 23:15.250] You're probably going to go to a lot of talks that are really pessimistic. [23:16.290 --> 23:18.650] Like, whistleblowers are all going to die soon. [23:18.830 --> 23:20.130] That's what HOPE's all about, right? [23:20.210 --> 23:20.270] Yeah. [23:21.150 --> 23:21.930] I don't know... [23:21.930 --> 23:22.590] Yeah, I mean... [23:22.590 --> 23:24.630] They put HOPE in the name because it's not in any of the talks. [23:24.630 --> 23:24.710] Thanks. [23:27.670 --> 23:28.110] Okay. [23:28.410 --> 23:28.550] Yeah. [23:28.830 --> 23:29.230] That's sure. [23:32.130 --> 23:32.790] But, no. [23:33.090 --> 23:33.330] I... [23:33.330 --> 23:34.370] So this is day one. [23:34.590 --> 23:37.270] And it's nice to start on kind of a high note. [23:37.870 --> 23:38.630] So part... [23:39.430 --> 23:39.790] Right. [23:40.010 --> 23:47.950] So whatever you hear in the rest of HOPE, remember that Cloudflare is pledging the double SSL usage on the web in 2014. [23:49.370 --> 23:51.210] Cloudflare, I believe, is getting... [23:51.210 --> 23:55.230] It's man-in-the-middle-ing about 5% of web traffic right now. [23:55.450 --> 23:57.990] So doubling that is going to be really, really important. [23:58.370 --> 24:03.170] And moreover, if Cloudflare does this, perhaps we can get Alchemy to do the same. [24:03.350 --> 24:07.890] And say, Alchemy, you've been using your, like, excuses long enough. [24:08.050 --> 24:11.550] Look, Cloudflare is offering SSL to everyone, even free customers. [24:12.090 --> 24:13.530] Why aren't you going to do the same? [24:13.770 --> 24:18.030] And once we get CDNs on board, that will be really awesome. [24:19.190 --> 24:19.650] Okay. [24:19.970 --> 24:21.170] And then there's the browsers. [24:21.710 --> 24:30.490] So, you know, there's this chart that I really like about browsers and what they're like. [24:31.690 --> 24:32.170] Yeah. [24:33.110 --> 24:34.250] Sorry if you're in the back. [24:34.290 --> 24:35.270] It's very funny. [24:36.410 --> 24:38.170] Yeah, I'm sorry if you can't read it. [24:38.690 --> 24:39.830] But it's really funny. [24:41.010 --> 24:42.950] We'll tell you each individually after. [24:43.070 --> 24:43.890] Just come up after. [24:44.090 --> 24:44.970] If you ask a question about what this says. [24:44.970 --> 24:46.990] Yeah, go up and we'll explain what the cartoon is. [24:46.990 --> 24:47.570] We'll explain what the cartoon is. [24:47.810 --> 24:49.410] I'm sorry, this is so small. [24:49.850 --> 24:52.190] I didn't realize this was going to be a large room. [24:53.330 --> 24:53.770] Yeah. [24:54.370 --> 24:57.270] But, so how many of you know about HSTS? [24:57.970 --> 24:58.410] Yeah. [24:59.110 --> 24:59.270] All right. [24:59.270 --> 25:01.390] Some of the fans, I guess. [25:01.390 --> 25:02.190] I can't really see. [25:03.510 --> 25:07.510] But HSTS prevents against this attack called SSL strip, right? [25:07.770 --> 25:12.030] So, usually you go to a website by typing in gmail.com. [25:12.370 --> 25:17.970] And your browser by default goes, unless you're using HTTPS Everywhere, which is this awesome browser extension. [25:18.310 --> 25:21.670] But usually your browser will go to http://gmail.com. [25:21.830 --> 25:28.590] And if someone's actively monitoring your connection, they can take that and redirect it to a fake site. [25:28.610 --> 25:31.650] And you won't notice that the lock icon is missing, perhaps. [25:31.650 --> 25:45.130] So, HSTS is a header that the server sends to the client that says, I only want you to contact me over HTTPS for the next several months, or however long the server wants you to do that. [25:45.590 --> 25:49.350] And so that prevents against this SSL stripping attack, right? [25:49.590 --> 25:51.550] And it's been around for a few years. [25:51.950 --> 25:53.970] Chrome and Firefox have supported it. [25:54.490 --> 25:56.670] Safari also has for a while. [25:56.670 --> 26:08.030] And now, IE, after EFF asked them, Microsoft has said that they're going to support HSTS in the next release of Internet Explorer. [26:08.330 --> 26:08.990] Browsers! [26:09.470 --> 26:09.530] Yay! [26:09.790 --> 26:10.250] Browsers! [26:10.490 --> 26:11.190] Browsers! [26:14.020 --> 26:14.740] Cool. [26:15.340 --> 26:22.380] Yeah, and also, we've seen large companies like Yahoo say pretty awesome things, like pretty large promises. [26:22.660 --> 26:31.940] And it's up to everyone here to remember that people like Yahoo have said this and hold them to it, because this is how we get things done, right? [26:32.180 --> 26:39.300] So they've said that traffic moving between Yahoo data centers is going to be fully encrypted as of, well, okay, so that's in the past. [26:39.360 --> 26:40.380] It's already fully encrypted. [26:41.320 --> 26:44.100] They made Yahoo Mail more secure, HTTPS by default. [26:45.140 --> 26:48.200] Search queries will also have HTTPS by default. [26:52.040 --> 26:54.540] And at the last one is kind of interesting. [26:54.700 --> 26:59.900] It says there will be a new encrypted version of Yahoo Messenger that will be deployed in the coming months. [27:00.300 --> 27:01.800] So, great. [27:03.160 --> 27:06.980] So, I wanted to talk a little about an initiative that we worked on in this. [27:07.100 --> 27:13.380] This is actually the members of a coalition that worked on a campaign called Reset the Net. [27:13.640 --> 27:17.260] As you can see, it was a pretty large and diverse coalition. [27:18.300 --> 27:21.780] And Reset the Net launched on June 5th, 2014. [27:21.780 --> 27:24.820] It was the one-year anniversary of the Snowden leaks. [27:26.020 --> 27:29.920] And it really showed how far we've come in that year. [27:29.920 --> 27:36.820] And it's an ongoing campaign to try to increase the security across these major platforms. [27:37.080 --> 27:40.160] Many of the sites listed here made improvements. [27:40.460 --> 27:54.020] Perhaps one of the most exciting was WordPress.com announced that they, by the end of this year, they will serve pages only over SSL for all WordPress.com subdomains. [27:54.020 --> 27:56.420] And so, that's, you know, a lot of blogs. [27:56.620 --> 28:01.120] As you can... this is our attempt at an SSL added here, smiley face. [28:03.720 --> 28:08.120] So, you know, WordPress powers between .com and .org powers 15% of the web. [28:08.240 --> 28:10.120] So, this is a really major thing. [28:11.360 --> 28:13.920] And we're seeing this and we're seeing it more and more. [28:15.420 --> 28:19.920] And, of course, there are some other exciting things that don't have... that aren't easily illustrated. [28:20.140 --> 28:20.520] Yeah. [28:20.760 --> 28:23.840] So, to be honest, I made most of these slides at 4 a.m. [28:23.840 --> 28:24.400] this morning. [28:24.900 --> 28:28.540] And I just don't have time to, like, find pictures. [28:28.880 --> 28:31.180] Though I'm sure some can exist. [28:32.760 --> 28:39.320] So, this is kind of a slide about what's new in SSL land, other than people deploying it. [28:39.320 --> 28:42.040] Like, how is SSL inherently going to get better? [28:42.880 --> 28:45.660] So, people yell a lot about SSL. [28:45.780 --> 28:49.120] They say that, you know, you can't trust certificate authorities, right? [28:49.360 --> 28:56.240] Like, if NSA can go to DigiCert and say, issue a cert... issue me a cert for Google, then it's game over, right? [28:56.320 --> 28:58.120] They can decrypt all the traffic, et cetera. [28:58.780 --> 29:01.060] So, how are we going to prevent things like that? [29:01.360 --> 29:03.080] It's not impossible, it turns out. [29:03.220 --> 29:18.000] So, there's a new proposal called Certificate Transparency that will basically make every certificate issued by a CA have to be added to a log that is maintained by Google and other organizations. [29:18.320 --> 29:20.440] Like, possibly EFF will run on one of these logs. [29:20.760 --> 29:24.600] And for the browser to accept the cert, it has to accept... it has to... [29:24.600 --> 29:28.580] the server has to show proof that the cert has made it into one of these logs. [29:28.800 --> 29:33.720] And it uses, like, a cool data structure called a Merkle Tree that makes this lookup process very efficient. [29:33.720 --> 29:35.340] Yes, people really like Merkle Tree's. [29:35.460 --> 29:38.720] I heard someone really, really get excited at that. [29:40.100 --> 29:54.500] So, you know, with Certificate Transparency, at the end of the day, what it means is that if a CA issues a bad certificate, either we can see it in the certificate log, or the client won't accept it. [29:54.980 --> 29:56.200] And that's really, really nice. [29:56.880 --> 30:00.760] And Google is actually... like, you might say, oh, this is, like, some theoretical math thing. [30:00.760 --> 30:03.200] It's, like, not going to be used anytime soon. [30:03.400 --> 30:12.780] Google is actually planning to require certificate transparency for all extended validation certs by the end of the year, if I remember correctly. [30:13.400 --> 30:17.380] I'm not sure if that timeline has changed, but I think that's what they said a few months ago. [30:18.320 --> 30:28.820] And then there's HTTP public key pinning, which solves the problem that anyone can issue a cert for EFF, or any CA can issue a cert for EFF.org. [30:28.960 --> 30:41.640] And HTTP public key pinning lets EFF say, I only want this cert from StartSSL, and this is the cert that you should expect to see every time you connect to EFF.org. [30:41.780 --> 30:47.280] And that will make it harder for people to create fake certificates for EFF or Google and so forth. [30:48.060 --> 30:50.120] HTTP public key pinning is... [30:50.920 --> 30:59.440] I think you can already do it statically through a preloaded list in Chrome, and soon you'll be able to do it dynamically by sending a header, like HSTS. [31:00.980 --> 31:07.000] And on the mail encryption side, EFF has just launched a project called StartTLS Everywhere. [31:07.760 --> 31:09.960] Some of the creators of that are in the audience. [31:10.520 --> 31:12.460] You can't see them, though, because it's really dark. [31:12.460 --> 31:19.120] But StartTLS Everywhere tries to solve the problem of downgrade attacks on SMTP servers. [31:19.740 --> 31:23.900] The problem is SMTP servers don't know each other's TLS policies. [31:24.180 --> 31:28.860] So if you say, like, mx.gmail.com doesn't support TLS. [31:29.440 --> 31:34.800] Like, if you say that from a man-in-the-middle, then the other server has no way of knowing that's a man-in-the-middle. [31:35.140 --> 31:41.680] So StartTLS uses these configuration files to enforce TLS policies between SMTP servers. [31:42.220 --> 31:44.780] And we'll be giving more talks on that in the future. [31:44.800 --> 31:47.340] So I won't tell you everything about it right now. [31:48.340 --> 31:48.540] No spoilers. [31:48.780 --> 31:49.520] Yeah, no spoilers. [31:51.680 --> 32:02.400] And so I heard earlier someone at HOPE said, like, I just overheard someone say, oh, like, you know, like, sys-admins are never all going to deploy TLS by default. [32:02.600 --> 32:03.940] It needs to just be enforced. [32:04.240 --> 32:06.720] Like, the default just needs to be encryption. [32:06.720 --> 32:10.440] We can't make people have to, like, buy cert and set it up and all this work. [32:10.860 --> 32:21.820] So HTTP 2.0 has a proposal to address that called opportunistic encryption, which will make all HTTP traffic encrypted by default. [32:22.480 --> 32:24.840] But then you might say, oh, like, what about CAs? [32:25.000 --> 32:26.100] Like, how do we get authentication? [32:26.860 --> 32:40.480] And the answer is, like, opportunistic encryption might just mean unauthenticated encryption, which means, of course, that, like, NSA can just pretend to be any server and, like, do, like, a attack or a downgrade attack. [32:41.100 --> 32:48.860] So real TLS is... real HTTPS is still better, but opportunistic encryption is on the table for HTTP 2.0. [32:51.120 --> 32:53.120] All right, so... [32:54.400 --> 32:58.480] Sorry, we put these comics up, and then you have to read it, and I didn't say anything funny. [32:59.480 --> 33:12.640] So I hope that we effectively made the point today that HTTP is horribly insecure and that if you're running a website, it's not optional. [33:12.920 --> 33:22.120] It's for your readers and users' privacy and security and for your site to be accessible and to preserve the integrity. [33:22.700 --> 33:26.480] HTTPS is something that you should absolutely be looking into and deploying. [33:27.820 --> 33:37.100] You know, as we like to say, it's too important to leave up to an unencrypted protocol, so if you like it, you should put an S on it. [33:40.480 --> 33:40.860] Sorry. [33:43.240 --> 33:44.520] Jan dared me to do that one. [33:47.300 --> 33:52.260] Yeah, and thank you very much, and we'd like to open the floor to questions. [33:52.900 --> 33:55.020] Yeah, I'm sorry this talk was too short. [33:55.300 --> 33:56.600] We didn't really time it. [33:56.940 --> 33:58.100] So it's half an hour. [33:58.120 --> 33:59.460] You can get a snack or something. [34:00.100 --> 34:02.360] But we can also take questions for a bit. [34:02.640 --> 34:03.600] People have those. [34:04.080 --> 34:04.520] Whoa. [34:05.340 --> 34:06.480] Wow, there's people here. [34:07.100 --> 34:10.340] Thank you. [34:10.640 --> 34:11.450] Thank you. [34:20.810 --> 34:23.810] Can we get the question mic on? [34:27.930 --> 34:30.550] If you yell it at me, I will repeat it. [34:36.690 --> 34:38.030] I'll repeat at the end. [34:39.470 --> 34:41.170] It's another people's mic here. [34:41.970 --> 34:42.570] Yeah, [34:45.610 --> 34:46.170] I'll get PLS. [34:47.090 --> 34:53.310] I'd prefer this if you just said, TCP must die, because that'd be closer to the point. [34:53.490 --> 34:54.990] I mean, like, here [35:00.810 --> 35:06.910] is the content delivery network, and how we get them to turn PLS on. [35:07.710 --> 35:11.670] And I've been told, you know, they've basically got two excuses at the beginning. [35:12.610 --> 35:17.030] Number one is, it takes too much concentration on time. [35:17.830 --> 35:20.650] You know, doing AES is just too much effort for them. [35:20.970 --> 35:24.930] Which, if you look at these figures, is just not just these days. [35:25.510 --> 35:27.690] And the other one is difficult to get in search. [35:28.410 --> 35:33.110] Because if you've got a CDN, you've got to be able to bring servers up and down. [35:33.450 --> 35:34.910] Now, I work for a TA. [35:34.910 --> 35:35.770] I work for Komodo. [35:36.890 --> 35:44.570] And so, I keep trying to say, well, you know, we've got technology that you could deploy to solve that problem. [35:45.330 --> 35:48.770] But then they say, well, we've not got the demand from the customer. [35:49.710 --> 36:01.030] So it's really critical that people who are in this room, who are customers of those CDNs, are telling their sales people, we want to turn on PLS across the whole network. [36:02.170 --> 36:06.550] they're only going to listen to me. [36:06.550 --> 36:07.470] All right. [36:07.610 --> 36:10.070] So I'm going to attempt to repeat as much of that as I can. [36:11.670 --> 36:13.690] We inadvertently threatened to kill this man's baby. [36:18.610 --> 36:19.750] Actually, we didn't threaten. [36:19.850 --> 36:21.110] We just said it has to die. [36:21.410 --> 36:21.710] It wasn't... [36:22.870 --> 36:29.130] And the problem, per the question, or the statement, is better addressed at the CDN level. [36:29.130 --> 36:42.110] And most importantly, that the CDNs need to hear demand from their customers, which are, you know, likely include people in this room, that they want to turn on encryption, you know, across the network. [36:42.470 --> 36:43.070] Is that...? [36:43.070 --> 36:43.330] Yeah. [36:43.790 --> 36:48.670] And so I agree, at least with the conclusion, and probably with most of it, right? [36:48.870 --> 36:49.050] Yeah. [36:50.650 --> 36:54.010] that we ought to be demanding this. [36:54.150 --> 36:57.410] That's how we get companies to start doing those changes. [36:59.210 --> 37:00.910] Could you talk a bit about Dane? [37:01.290 --> 37:03.830] Because you didn't list Dane in your promising... [37:04.830 --> 37:05.850] Do you know what it is? [37:06.050 --> 37:06.370] Yes. [37:06.370 --> 37:06.790] Okay. [37:08.170 --> 37:11.590] I think we can talk more about that afterward. [37:11.930 --> 37:12.690] But I... [37:12.690 --> 37:12.970] Yeah. [37:13.350 --> 37:15.390] I think there's a lot of... [37:15.390 --> 37:27.250] So I'm not an expert on DNSSEC, but we've heard a lot of people say that it's infeasible for them to deploy at the moment, which is part of why we started the Start TLS Everywhere project. [37:27.590 --> 37:27.870] Okay. [37:28.010 --> 37:40.070] But the argument that the CDNs have for not being able to manage their certificates, if they could use self-signed certificates in their own DNS, zone data, then that would circumvent that problem completely. [37:40.310 --> 37:52.370] And moreover, it would circumvent the problem with the crappy, you know, everywhere trusted CAs in every government in the world that you don't want to be able to issue your certs. [37:52.490 --> 37:59.930] So it would actually eliminate a lot of the pinning and transparency problems if Dane were widely adopted. [37:59.990 --> 38:06.870] So I urge you to follow the Dane efforts because I think they're going to be very promising. [38:07.650 --> 38:09.990] Yeah, there are a number of... Dane is one of them. [38:10.090 --> 38:13.910] There are a number of efforts that have... [38:13.910 --> 38:19.730] at varying degrees of technical completion that have yet to be adopted. [38:20.730 --> 38:23.810] And, yeah, many of them are really interesting. [38:25.110 --> 38:28.050] A little bit of what we're talking about is what we have now. [38:28.350 --> 38:33.790] And, you know, we could easily double the number of HTTPS. [38:34.190 --> 38:37.650] I mean, Cloudflare is talking about doubling it just with a switch on their end. [38:37.790 --> 38:41.330] And that would... that does a lot of... on the ground already. [38:46.370 --> 38:54.090] Is there any truth to the rumor that EFF is going to fight untrustworthy CAs by becoming a trustworthy CA? [38:55.770 --> 38:57.510] That's a great question. [38:57.750 --> 38:59.690] I think we don't comment on rumors and speculation. [39:00.110 --> 39:00.870] I don't think we comment on that one. [39:01.290 --> 39:02.690] Well, think about it. [39:03.070 --> 39:05.710] But, yeah, thank you for asking. [39:07.770 --> 39:10.950] Hi, my name is Richard Barnes and I do security stuff with Mozilla. [39:11.850 --> 39:12.430] Thank you. [39:12.530 --> 39:15.610] Which is relevant because I have some bad news and some good news. [39:17.470 --> 39:24.170] The bad news is that if Cloudflare is saying they're going to double the percentage of SSL on the Internet, they're lying because it's impossible. [39:24.970 --> 39:34.310] And I say it's impossible, the good news is that it's impossible because I was just checking the stats from our telemetry and we're seeing like 60% of the web being encrypted right now. [39:34.310 --> 39:38.030] So I think that's largely due to a lot of the efforts of the folks in this room. [39:38.150 --> 39:39.790] And so I wanted to applaud that part of it. [39:46.230 --> 39:46.950] Say again? [39:47.010 --> 39:49.010] You are counting differently from the way they are. [39:49.450 --> 39:50.090] Oh, yeah. [39:50.750 --> 39:51.390] Yes, yes. [39:51.730 --> 39:53.110] I'm having fun with metrics here. [39:53.110 --> 39:54.250] I say let's let them try. [39:55.190 --> 39:58.030] Let's take 120% encryption and we're happy. [39:58.670 --> 39:59.730] That's all we ask for. [39:59.890 --> 40:00.010] Yeah. [40:00.630 --> 40:01.150] That's all. [40:01.450 --> 40:02.090] We're simple. [40:02.850 --> 40:09.430] So one of the things that was on your slides, it's in active flux right now, really active discussion right now, is this idea of opportunistic encryption in HTTP2. [40:09.550 --> 40:12.910] And I'm one of the instigators of that in the HTTP BIS working group. [40:13.390 --> 40:14.850] So if people could take a look at that. [40:14.910 --> 40:16.850] That's something where we have community discussions. [40:17.010 --> 40:17.930] It's in the IETF. [40:18.030 --> 40:20.070] There's a working group around this right now that's discussing it. [40:20.150 --> 40:30.530] So if people have feelings about whether we should allow opportunistic encryption, whether we should require browsers to validate certs in HTTP2, that would be something where community feedback would be really helpful. [40:31.130 --> 40:34.610] I also think this mail encryption you guys are getting involved in is really good. [40:34.850 --> 40:37.550] The web is sort of on a really positive path and there's good momentum. [40:37.910 --> 40:39.730] The mail community, they're much more fractured. [40:39.810 --> 40:41.130] They don't really know how to do authentication. [40:41.310 --> 40:44.350] So whatever you guys can do to help move them forward would be really helpful. [40:44.550 --> 40:44.730] Cool. [40:44.890 --> 40:45.090] Thanks. [40:45.370 --> 40:49.730] Out of curiosity, do you want to offer your opinion on opportunistic encryption? [40:51.650 --> 40:59.030] So those of us who have been sort of our internal security mafia at Mozilla have been talking a lot about this. [40:59.430 --> 40:59.570] Yeah. [41:01.070 --> 41:05.810] You know, we are... obviously HTTPS is the gold standard, as you guys said. [41:07.370 --> 41:11.810] It provides all of... it blocks a whole other... well, it is a standard. [41:12.250 --> 41:12.810] Some color. [41:12.810 --> 41:13.170] Yeah. [41:15.930 --> 41:19.950] It blocks a lot of attacks that we know happen, as you put on your slide. [41:22.550 --> 41:25.470] We've been really supportive of opportunistic encryption. [41:25.830 --> 41:35.890] We're... in the IETF process, we've been putting forward proposals to enable encryption with the possibility of discovering when... [41:36.330 --> 41:39.810] you know, with the possibility for, as you said, unauthenticated. [41:40.070 --> 41:40.310] So... [41:41.970 --> 41:43.370] Spin up your Apache instance. [41:43.530 --> 41:45.470] Have a genuine self-signed certificate. [41:45.650 --> 41:48.770] Don't bother going out to a CA if you don't want to. [41:50.090 --> 41:51.830] And we'll go ahead and do the encryption. [41:52.350 --> 41:57.410] And, you know, we're not... we might not display a lock icon or anything because you're still vulnerable to all this stuff. [41:57.490 --> 41:58.470] Because it's not HTTPS. [41:59.750 --> 42:09.670] But we may go ahead and accept that cert and do the encrypted connection, even if it's... even if it's not a cert from a CA that validates an identity. [42:10.390 --> 42:12.810] And I don't want this to turn into... it's a Mozilla question hour. [42:14.710 --> 42:19.370] So, I can't speak off the top of my head to the development plans in terms of what we're planning to implement. [42:19.790 --> 42:29.790] But in the IETF and the standards discussions, we've been trying to find ways that we can agree on to expand the set of website operators who can do encryption. [42:30.970 --> 42:31.550] Thank you. [42:31.550 --> 42:35.270] And I encourage people to take part in those discussions because they're interesting. [42:35.490 --> 42:37.630] And I think it's a... there are some hard questions raised. [42:37.810 --> 42:39.330] And there's lots of different valid perspectives. [42:39.570 --> 42:45.450] So, I mean, the more mass we can have behind different perspectives, the more we can understand how much the community feels one way or the other. [42:45.670 --> 42:46.110] Thank you. [42:49.390 --> 42:55.550] So, after Heartbleed, OpenSSL was a media darling for a little while and got some security reviews. [42:56.490 --> 42:59.970] And like a couple more flaws have floated around. [43:00.170 --> 43:03.650] But in general, it's maybe in a better... one could argue that it's in a better place. [43:03.650 --> 43:09.430] However, there's also forks of it now, like Libra SSL and Google has their own deployment strategy for SSL now. [43:09.730 --> 43:10.450] Born SSL. [43:10.570 --> 43:10.850] Yep. [43:11.030 --> 43:11.850] What do you guys make of that? [43:14.410 --> 43:15.130] Probably good. [43:17.270 --> 43:21.650] Yeah, I mean, it's nice to have some diversity out there. [43:21.650 --> 43:27.830] It's also nice to have... I think if you don't have diversity, it's nice to have a lot of effort in one place. [43:28.110 --> 43:34.170] And what the media reports after Heartbleed showed is that we had neither. [43:34.410 --> 43:37.050] We had one solution that had, you know, one and a half people working on it. [43:38.690 --> 43:39.990] Two... sorry, two and a half. [43:41.230 --> 43:54.310] And so, yeah, I think that if what we get is more attention on OpenSSL or if what we get is a number of really good solutions, then either way is better off. [43:54.490 --> 43:59.050] And, you know, it's easy to... Heartbleed was... it was a rough week. [43:59.990 --> 44:01.090] I work at Red Hat. [44:01.230 --> 44:01.990] It was a rough week. [44:03.470 --> 44:04.370] It sucked. [44:05.330 --> 44:15.950] But I think it's... you know, we were able to recover and we at least have some sort of infrastructure in place for communicating that this happens. [44:15.950 --> 44:18.970] And it came... I mean, it could have been worse. [44:19.270 --> 44:24.110] And I think that there are things that... steps we took after that that will make it more likely to be better. [44:24.850 --> 44:25.250] Okay. [44:25.370 --> 44:25.630] Thank you. [44:25.810 --> 44:26.170] Thank you. [44:27.930 --> 44:28.410] All right. [44:29.170 --> 44:55.070] One thing... one thing I've been thinking of, and this is something I've actually been thinking of for a while in regards to dealing with the problems of both CAs and DNS, is... I'm not sure if you're familiar with the Namecoin project, but the possibility of using multiple Namecoin server... basically multiple Tor-HIN services as essentially Namecoin blockchain CAs, [44:55.310 --> 45:11.150] connecting to them through Tor and then using something similar to Moxie Marlin Spike's convergence as a means of validating the entries when you receive them, and then just transfer everything over to that rather than going through standard CAs and DNS. [45:11.890 --> 45:12.130] Yeah. [45:12.270 --> 45:13.250] And it's so simple. [45:14.170 --> 45:14.690] Right. [45:14.690 --> 45:15.050] Yeah. [45:15.150 --> 45:23.770] So there... I've seen a number of proposals like that, usually involving some sort of like cryptographically verified, append-only log, like a blockchain. [45:24.570 --> 45:30.050] But I think... I think we've yet to see something that's really complete along those lines. [45:31.350 --> 45:34.450] And if that comes along, I think it'd be interesting to think about. [45:34.450 --> 45:34.990] Yeah. [45:35.410 --> 45:38.810] I mean, I'd love if something like really weird happened. [45:39.150 --> 45:42.190] Like, you know, that's not even... that's pretty weird. [45:42.370 --> 45:48.170] But like, yeah, let's try a bunch of stuff and see, you know, like... it could happen. [45:48.290 --> 45:53.710] And there's been a lot of stories about the development of the web where it wasn't, you know, it was pretty weird along the way. [45:53.850 --> 45:57.010] Just remember, science isn't about why, it's about why not. [45:57.330 --> 45:57.510] Yeah. [45:58.790 --> 45:59.230] Yeah. [45:59.230 --> 45:59.770] Yeah. [46:00.730 --> 46:01.930] Thanks for the talk, guys. [46:03.210 --> 46:03.650] Question. [46:04.030 --> 46:05.370] So, SSL, yay! [46:05.890 --> 46:08.690] Buying an EV cert for 500 bucks, not yay. [46:08.990 --> 46:09.370] No, that's fine. [46:09.610 --> 46:13.510] So, I do some work with, like, non-profits and NGOs. [46:13.950 --> 46:19.470] $500, you know, is trivial to a large corporation, but to some of these smaller orgs, that's serious money. [46:19.470 --> 46:22.890] Or, you know, some, you know, activist blogger in Nepal. [46:23.290 --> 46:28.870] Are there any CAs that offer, you know, free certs, or would such a thing be feasible? [46:29.150 --> 46:29.450] Yes. [46:29.810 --> 46:30.850] So, it depends. [46:31.050 --> 46:42.830] So, if you just have, like, a single page website, or I think just like a single domain website, and you don't need, like, arbitrary sub-domain coverage for SSL, StartCom will give you a free certificate. [46:43.750 --> 46:44.150] And... [46:44.150 --> 46:45.170] Not EVs, I'll post. [46:45.250 --> 46:46.030] But not EV, right. [46:46.110 --> 46:46.430] Not EV. [46:46.430 --> 46:47.130] That's correct. [46:48.370 --> 46:54.870] And, so, Cloudflare has stated that they are planning to offer SSL to free customers, too, in the near future. [46:55.150 --> 46:55.750] Thank you. [46:55.930 --> 47:06.570] Yeah, I think that's a really important point, though, is that this is really important, and that's a good reason to try to make it, to make these prices come down. [47:06.730 --> 47:15.650] And then that's a little bit of pressure, and, you know, hopefully Cloudflare switching it on applies more pressure, but, yeah, that's obviously a burden. [47:15.650 --> 47:25.350] And there's things that, not just the cost, if you're an activist blogger in Nepal, it very well, the complexity of deploying it might be a showstopper. [47:25.590 --> 47:28.550] And, so, you know, there's a lot of places to work on making this easier. [47:29.130 --> 47:29.650] Thank you. [47:31.890 --> 47:32.450] All right. [47:32.670 --> 47:33.750] I think that's all the questions. [47:33.910 --> 47:34.550] Thank you very much. [47:34.550 --> 47:34.950] Yeah. [47:34.950 --> 47:35.350] Thank you all. [47:35.570 --> 47:36.210] It was great. [47:36.210 --> 47:37.090] Thank you.