1 00:00:00,290 --> 00:00:48,030 *music still playing, no audio available for speaker* 2 00:00:48,030 --> 00:00:51,940 provide both confidentiality, integrity, and authenticity 3 00:00:51,940 --> 00:00:55,470 so this means that nobody can see what you're looking at 4 00:00:55,470 --> 00:00:58,440 nobody can change what you're looking at 5 00:00:58,440 --> 00:01:02,489 and you know that the person who is sending you this 6 00:01:02,489 --> 00:01:04,459 is a specific person. 7 00:01:04,459 --> 00:01:08,830 They use signed digital certificates. 8 00:01:08,830 --> 00:01:12,630 Each one of these certificates must be signed by another certificate 9 00:01:12,630 --> 00:01:16,220 and if you want to be trusted, they have to chain up 10 00:01:16,220 --> 00:01:21,720 to a certificate issued by a publicly trusted certificate authority. 11 00:01:21,720 --> 00:01:26,570 Who decides, who gets a certificate and who doesn't? 12 00:01:26,570 --> 00:01:29,009 Why do we have to launch another one? 13 00:01:29,009 --> 00:01:34,190 Well, the Internet is a bad place. 14 00:01:34,190 --> 00:01:41,080 It's extremely easy to modify or to observe HTTP communication. 15 00:01:41,080 --> 00:01:44,700 There've been a number of attacks that have demonstrated this over the years 16 00:01:44,700 --> 00:01:49,959 including cookie session re-use and others. 17 00:01:49,959 --> 00:01:52,820 Based on telemetry from the Firefox browser, 18 00:01:52,820 --> 00:01:59,900 we know that only 40% of initial HTTP requests go over HTTPS. 19 00:01:59,900 --> 00:02:04,549 This is probably because both getting and installing a certificate 20 00:02:04,549 --> 00:02:08,038 as well as setting up all the correct TLS parameters 21 00:02:08,038 --> 00:02:11,219 is extremely confusing. 22 00:02:11,219 --> 00:02:14,389 And in part this is because every CA decides, 23 00:02:14,389 --> 00:02:19,099 how it will issue a certificate on its own. 24 00:02:19,099 --> 00:02:22,029 So our solution is to create another Certificate Authority. 25 00:02:22,029 --> 00:02:26,419 I mean, what can go wrong? 26 00:02:26,419 --> 00:02:30,999 So, because we're the EFF and Mozilla, 27 00:02:30,999 --> 00:02:34,660 we've decided that it should be completely free. 28 00:02:34,660 --> 00:02:39,120 Cryptography shouldn't be something that you have to pay for on the Internet. 29 00:02:39,120 --> 00:02:40,989 And unfortunately, right now … 30 00:02:40,989 --> 00:02:48,639 *applause* 31 00:02:48,639 --> 00:02:51,189 So unfortunately right know there are only 32 00:02:51,189 --> 00:02:54,829 two certificate authorities that are willing to issue free certificates 33 00:02:54,829 --> 00:02:56,629 except for Let's Encrypt. 34 00:02:56,629 --> 00:02:59,510 And unfortunately, both of them make it 35 00:02:59,510 --> 00:03:01,439 a quite complicated process and 36 00:03:01,439 --> 00:03:03,709 will exclude you from getting a certificate 37 00:03:03,709 --> 00:03:07,329 if you fall into certain groups. 38 00:03:07,329 --> 00:03:08,419 So we decided to make it free 39 00:03:08,419 --> 00:03:11,150 and we also decided to make it open-source. 40 00:03:11,150 --> 00:03:13,760 We did this because it's extremely hard 41 00:03:13,760 --> 00:03:16,389 to tell, what Certificate Authorities are actually doing 42 00:03:16,389 --> 00:03:20,509 and how they decide whether or not to issue a certificate. 43 00:03:20,519 --> 00:03:22,589 So we decided it'd be best to come up 44 00:03:22,589 --> 00:03:27,400 with a standardised protocol which we've called ACME 45 00:03:27,400 --> 00:03:31,839 so that we can get everybody's input 46 00:03:31,839 --> 00:03:35,980 on what is the most secure way that we can do this. 47 00:03:35,980 --> 00:03:37,980 Let's Encrypt has already launched 48 00:03:37,980 --> 00:03:40,079 and you can—right now—go and get 49 00:03:40,079 --> 00:03:43,989 a publicly trusted, free certificate from us. 50 00:03:43,989 --> 00:03:48,299 Unfortunately, this isn't a cheap thing to do. 51 00:03:48,299 --> 00:03:50,719 So we've been sponsored by a large number 52 00:03:50,719 --> 00:03:53,930 of industry people including 53 00:03:53,930 --> 00:03:55,949 a bunch of hosting providers 54 00:03:55,949 --> 00:04:00,169 Mozilla, Cisco, Akamai, who is a Content Distribution Network 55 00:04:00,169 --> 00:04:05,260 and the EFF, among others. *chuckles* 56 00:04:05,260 --> 00:04:11,010 So, the CA and TLS ecosystem is a pretty strange place. 57 00:04:11,010 --> 00:04:15,709 Before we got there, this is a map of 58 00:04:15,709 --> 00:04:20,240 every single trusted Certificate Authority that currently exists. 59 00:04:20,240 --> 00:04:22,540 Every single one of these nodes can issue 60 00:04:22,540 --> 00:04:27,960 a certificate that your browser will completely trust. 61 00:04:27,960 --> 00:04:29,420 And this is ridiculous! 62 00:04:29,420 --> 00:04:34,700 The fact that there are over 1'600 Certificate Authorities 63 00:04:34,700 --> 00:04:37,790 is very silly. 64 00:04:37,790 --> 00:04:42,160 You can actually see Let's Encrypt is one of the small magenta nodes 65 00:04:42,160 --> 00:04:44,710 in the bottom left-hand corner. 66 00:04:44,710 --> 00:04:47,080 Unfortunately, we haven't surpassed 67 00:04:47,080 --> 00:04:49,520 some of the other Certificate Authorities yet, 68 00:04:49,520 --> 00:04:53,720 but that's soon to happen. 69 00:04:53,720 --> 00:04:57,100 There's a group called "The CA Browser Forum" 70 00:04:57,100 --> 00:05:04,060 and these are the people who decide how the CA and TLS ecosystem works. 71 00:05:04,060 --> 00:05:07,820 Because CAs have a slightly vested interest 72 00:05:07,820 --> 00:05:11,690 in making money over protecting users, 73 00:05:11,690 --> 00:05:14,970 there's often a rift between them and the browsers 74 00:05:14,970 --> 00:05:18,200 and how rules should be made 75 00:05:18,200 --> 00:05:23,000 that affect publicly trusted certificates and Certificate Authorities. 76 00:05:23,000 --> 00:05:25,160 Because of this, they decided to come together 77 00:05:25,160 --> 00:05:29,520 and self-govern themselves in order to have … 78 00:05:29,520 --> 00:05:32,340 bring order about … 79 00:05:32,340 --> 00:05:36,700 The Browsers generally yield slightly more power 80 00:05:36,700 --> 00:05:38,860 than the Certificate Authorities. 81 00:05:38,860 --> 00:05:41,000 They require a larger number of … 82 00:05:41,000 --> 00:05:44,560 a larger majority in order to pass a rule. 83 00:05:44,560 --> 00:05:48,420 And this is because, like I said previously, 84 00:05:48,420 --> 00:05:52,420 Certificate Authorities are generally guided by making money 85 00:05:52,420 --> 00:05:56,970 whereas the browsers are generally guided by trying to keep users safe. 86 00:05:56,970 --> 00:06:01,660 Unfortunately, Let's Encrypt is not yet a member of this group 87 00:06:01,660 --> 00:06:04,140 because they have very stringent requirements 88 00:06:04,140 --> 00:06:05,830 for membership, which include 89 00:06:05,830 --> 00:06:08,630 a number of audits we haven't yet completed, 90 00:06:08,630 --> 00:06:12,690 although we're very close to doing so. 91 00:06:12,690 --> 00:06:14,170 Like I said … 92 00:06:14,170 --> 00:06:16,620 The CA/B Forum creates rules 93 00:06:16,620 --> 00:06:18,910 called the "Baseline requirements" 94 00:06:18,910 --> 00:06:22,430 which every Certificate Authority must comply with 95 00:06:22,430 --> 00:06:26,790 if they wish to be trusted by browsers. 96 00:06:26,790 --> 00:06:30,770 This includes basically documenting every process that's involved 97 00:06:30,770 --> 00:06:32,840 with issuance of a certificate 98 00:06:32,840 --> 00:06:36,260 and takes a very long time. 99 00:06:36,260 --> 00:06:40,290 So the CA/B also chooses the different 100 00:06:40,290 --> 00:06:42,450 security levels of a certificate 101 00:06:42,450 --> 00:06:44,770 —these are called "validation levels". 102 00:06:44,770 --> 00:06:47,580 There are currently three and it should be noted that 103 00:06:47,580 --> 00:06:50,170 cryptographically, there is no difference 104 00:06:50,170 --> 00:06:53,800 between each of these "levels of validation". 105 00:06:53,800 --> 00:06:59,800 What they mean is how thoroughly a CA 106 00:06:59,800 --> 00:07:04,180 has validated a person who is requesting a certificate. 107 00:07:04,180 --> 00:07:06,230 Domain validation is what we're interested in. 108 00:07:06,230 --> 00:07:09,430 It basically just means that—as a CA— 109 00:07:09,430 --> 00:07:14,780 we can verify that you control a certain DNS name. 110 00:07:14,780 --> 00:07:21,310 Now there are a few extra steps for organizational validation. 111 00:07:21,310 --> 00:07:24,550 This means that a CA would have to validate 112 00:07:24,550 --> 00:07:29,060 that you're an owner of a certain business in a certain country. 113 00:07:29,060 --> 00:07:31,620 And Extended Validation goes even further 114 00:07:31,620 --> 00:07:35,550 and checks other governmental records. 115 00:07:35,550 --> 00:07:40,389 Both OV and EV certificates don't provide any more security. 116 00:07:40,389 --> 00:07:44,300 All they provide is UI hints in the browser. 117 00:07:44,300 --> 00:07:50,220 So with an EV certificate you'll see a green box in your URL bar 118 00:07:50,220 --> 00:07:52,740 that says the name of a company. 119 00:07:52,740 --> 00:07:57,130 But cryptographically, these certificates are exactly the same. 120 00:07:57,130 --> 00:08:00,150 So where does Let's Encrypt fit into this? 121 00:08:00,150 --> 00:08:03,650 Like I said, we're doing everything completely for free. 122 00:08:03,650 --> 00:08:07,400 This includes issuance, renewal, and revocation 123 00:08:07,400 --> 00:08:12,620 —and any other action you'd do with us is entirely free. 124 00:08:12,620 --> 00:08:15,470 We're not charging anyone anything. 125 00:08:15,470 --> 00:08:22,180 We're also only going to be issuing Domain validated certificates. 126 00:08:22,180 --> 00:08:27,870 This is because we don't intend on hiring a bunch of people to deal with issuance. 127 00:08:27,870 --> 00:08:30,120 Our system is entirely automated. 128 00:08:30,120 --> 00:08:37,058 The only people that we hire are operations and maintenance people. 129 00:08:37,058 --> 00:08:38,928 We're also only issuing certificates that are 130 00:08:38,928 --> 00:08:43,929 valid for a maximum of 90 days. 131 00:08:43,929 --> 00:08:45,240 We originally decided on doing this 132 00:08:45,240 --> 00:08:49,300 because in the previous world where certificates 133 00:08:49,300 --> 00:08:54,480 were valid for anywhere from 1–3 years, 134 00:08:54,480 --> 00:08:59,959 it made it really hard to figure out how to automate renewal of a certificate. 135 00:08:59,959 --> 00:09:04,249 You'd, every once a year, go to your Certificate Authority 136 00:09:04,249 --> 00:09:06,139 and ask for a new certificate 137 00:09:06,139 --> 00:09:07,589 and then spend the next few hours 138 00:09:07,589 --> 00:09:10,480 trying to figure out what you had to tell them 139 00:09:10,480 --> 00:09:14,519 and how you'd install it in your server. 140 00:09:14,519 --> 00:09:19,610 By limiting the validity period to 90 days, 141 00:09:19,610 --> 00:09:24,410 we're ensuring that people are forced to renew often. 142 00:09:24,410 --> 00:09:26,889 And this also comes with a good side-effect 143 00:09:26,889 --> 00:09:29,370 that if their certificate becomes compromised, 144 00:09:29,370 --> 00:09:34,870 it is only compromised for a maximum of 90 days. 145 00:09:34,870 --> 00:09:38,040 Which makes it slightly safer. 146 00:09:38,040 --> 00:09:43,360 So we're also issuing multiple domain certificates instead of wildcard certificates. 147 00:09:43,360 --> 00:09:46,249 These use Subject Alternative Names (SAN) 148 00:09:46,249 --> 00:09:48,970 with multiple DNS names inside of a certificate 149 00:09:48,970 --> 00:09:51,430 meaning that a single certificate can be used 150 00:09:51,430 --> 00:09:56,980 to validate up to a hundred domains. 151 00:09:56,980 --> 00:10:01,730 In order to make our certificates actually publicly trusted 152 00:10:01,730 --> 00:10:06,089 we've applied to the Mozilla, Apple, Google, and Microsoft root 153 00:10:06,089 --> 00:10:07,670 programmes 154 00:10:07,670 --> 00:10:11,480 but we've also had one of our Intermediate Certificates 155 00:10:11,480 --> 00:10:16,350 cross-signed by IdenTrust, which is another Certificate Authority. 156 00:10:16,350 --> 00:10:18,939 This means that every certificate we issue 157 00:10:18,939 --> 00:10:21,350 is already trusted. 158 00:10:21,350 --> 00:10:24,339 So we don't have to worry about old devices 159 00:10:24,339 --> 00:10:28,339 not trusting our certificates. 160 00:10:28,339 --> 00:10:34,920 So, we started a closed beta in about early September 161 00:10:34,920 --> 00:10:38,889 and this went from … all the way up to December, 3rd 162 00:10:38,889 --> 00:10:40,399 and during that period we only issued 163 00:10:40,399 --> 00:10:42,329 about 20'000 certificates. 164 00:10:42,329 --> 00:10:45,589 You can see that the first period in september 165 00:10:45,589 --> 00:10:53,999 was just staff issuing certificates to themselves. And I think we only issued around 100 or 200 certificates. 166 00:10:53,999 --> 00:10:56,249 And then we opened a Closed Beta 167 00:10:56,249 --> 00:10:59,340 and we issued around 20'000 more 168 00:10:59,340 --> 00:11:03,050 and then on December, 3rd, we opened up to everyone. 169 00:11:03,050 --> 00:11:05,449 You didn't have to apply to join and 170 00:11:05,449 --> 00:11:07,160 we'd issue a certificate as long as you could prove 171 00:11:07,160 --> 00:11:09,709 that you controlled a domain. 172 00:11:09,709 --> 00:11:13,639 In the first day, we doubled the number of certificates we issued. 173 00:11:13,639 --> 00:11:16,189 And in a week, I think, we quadrupled it. 174 00:11:16,189 --> 00:11:18,769 I mean, in the first 12 hours we were issuing 175 00:11:18,769 --> 00:11:23,529 a certificate almost every two seconds. 176 00:11:23,529 --> 00:11:24,779 And since then, we've issued 177 00:11:24,779 --> 00:11:32,189 over 200'000 certificates across 440'000 domain names. 178 00:11:32,189 --> 00:11:34,329 This is … we're still in beta though. 179 00:11:34,329 --> 00:11:36,089 That should be noted. 180 00:11:36,089 --> 00:11:41,240 We don't expect to be … 181 00:11:41,240 --> 00:11:43,580 We expect to do a Google-style Beta 182 00:11:43,580 --> 00:11:48,260 —it will probably take a while. 183 00:11:48,260 --> 00:11:52,240 Using Certificate Transparency Logs 184 00:11:52,240 --> 00:11:54,899 which are a collection that Google has created 185 00:11:54,899 --> 00:12:00,019 of almost all currently valid certificates 186 00:12:00,019 --> 00:12:02,509 we can see that Let's Encrypt is already 187 00:12:02,509 --> 00:12:05,309 the fifth largest Certificate Authority 188 00:12:05,309 --> 00:12:09,549 and we're already larger than both WoSign and StartSSL 189 00:12:09,549 --> 00:12:15,270 the two currently free public Certificate Authorities. 190 00:12:15,270 --> 00:12:22,730 *applause* 191 00:12:22,730 --> 00:12:24,699 So our goal is to … 192 00:12:24,699 --> 00:12:27,249 it isn't to be the largest Certificate Authority 193 00:12:27,249 --> 00:12:29,559 but it is to raise the total percentage 194 00:12:29,559 --> 00:12:34,080 of connections on the internet that go over HTTPS. 195 00:12:34,080 --> 00:12:39,910 *applause* 196 00:12:39,910 --> 00:12:42,869 So this is a very hard thing to measure. 197 00:12:42,869 --> 00:12:44,819 Unless you're sitting on a backbone, 198 00:12:44,819 --> 00:12:47,660 it's almost impossible to tell what percentage 199 00:12:47,660 --> 00:12:51,089 is going over HTTP and what percentage is going over HTTPS. 200 00:12:51,089 --> 00:12:54,439 Luckily, Firefox can provide us with 201 00:12:54,439 --> 00:12:59,170 certain TLS telemetry about what Certificate Authorities 202 00:12:59,170 --> 00:13:01,529 issue certificates that they're seeing 203 00:13:01,529 --> 00:13:04,720 and we can also use Certificate Transparency 204 00:13:04,720 --> 00:13:10,350 to try and figure out how people are actually using our certificates. 205 00:13:10,350 --> 00:13:12,179 We have a bunch of stats … 206 00:13:12,179 --> 00:13:16,269 There are currently over a 120'000 individual registrations. 207 00:13:16,269 --> 00:13:20,319 So, we count … a single registration can issue multiple certificates 208 00:13:20,319 --> 00:13:25,110 and we see that there are currently only about two certificates per registration 209 00:13:25,110 --> 00:13:27,999 with two DNS names per certificate. 210 00:13:27,999 --> 00:13:31,249 Now this is most likely because people are just testing the servers 211 00:13:31,249 --> 00:13:37,230 so they will go out and try and find a certificate for their blog or personal website 212 00:13:37,230 --> 00:13:40,459 and not very many people are using 213 00:13:40,459 --> 00:13:47,279 very large certificates with multiple Subject Alternate Names yet. 214 00:13:47,279 --> 00:13:50,889 We see that around 33% of the names that we issued for 215 00:13:50,889 --> 00:13:53,980 have multiple certificates with that name in them. 216 00:13:53,980 --> 00:13:55,779 This is actually a very common thing 217 00:13:55,779 --> 00:13:58,179 we were expecting to see. 218 00:13:58,179 --> 00:14:03,550 Because we issue a very large number of certificates to Content Distribution Networks. 219 00:14:03,550 --> 00:14:07,009 And these Networks will have tons of endpoints 220 00:14:07,009 --> 00:14:09,839 that will work for a whole bunch 221 00:14:09,839 --> 00:14:11,759 of different websites. 222 00:14:11,759 --> 00:14:13,910 So they will, you know, 223 00:14:13,910 --> 00:14:17,639 maybe have 15 certificates that'll have a set of 50 Domain Names 224 00:14:17,639 --> 00:14:21,170 spread out across them. 225 00:14:21,170 --> 00:14:23,480 We also see that 20% of certificates have 226 00:14:23,480 --> 00:14:26,829 the exact same duplicate name sets. 227 00:14:26,829 --> 00:14:29,019 This has probably more to do with 228 00:14:29,019 --> 00:14:31,540 people trying to get used to our official client 229 00:14:31,540 --> 00:14:34,139 and us having to fix a few bugs in it 230 00:14:34,139 --> 00:14:37,269 —that meant that people would reissue 231 00:14:37,269 --> 00:14:39,379 the same certificate over and over 232 00:14:39,379 --> 00:14:44,079 without noticing that they already had a valid one. 233 00:14:44,079 --> 00:14:47,449 But we're seeing that slowly decrease. 234 00:14:47,449 --> 00:14:50,689 We've also seen that 80% of the domain names that we've issued for 235 00:14:50,689 --> 00:14:52,459 have never had a certificate before, 236 00:14:52,459 --> 00:14:55,439 according to the Certificate Transparency logs. 237 00:14:55,439 --> 00:14:57,220 So we're actually providing people who 238 00:14:57,220 --> 00:15:01,009 previously wouldn't have got a TLS certificate 239 00:15:01,009 --> 00:15:03,469 with certificates. 240 00:15:03,469 --> 00:15:10,679 *applause* 241 00:15:10,679 --> 00:15:16,160 And we've had … about 1% of our total issuance have been revoked so far, 242 00:15:16,160 --> 00:15:23,779 which is a good sign that our system is actually working. 243 00:15:23,779 --> 00:15:28,059 So, in order to see how people are actually deploying our certificates, 244 00:15:28,059 --> 00:15:30,809 we've written a very small TLS scanner 245 00:15:30,809 --> 00:15:32,279 that will go through the DNS names 246 00:15:32,279 --> 00:15:33,569 of certificates we've issued 247 00:15:33,569 --> 00:15:36,730 and try to see if they actually use them. 248 00:15:36,730 --> 00:15:38,699 We see that about 75% of the people 249 00:15:38,699 --> 00:15:40,589 that we've issued a certificate for 250 00:15:40,589 --> 00:15:45,259 have actually deployed it on the domain name we've issued it for. 251 00:15:45,259 --> 00:15:49,259 And only 8% of those names have a broken TLS configuration. 252 00:15:49,259 --> 00:15:50,970 This means, if you try to connect to them, 253 00:15:50,970 --> 00:15:53,799 your Browser would reject the certificate. 254 00:15:53,799 --> 00:15:56,139 This can be because they're using 255 00:15:56,139 --> 00:15:58,199 a self-signed certificate or 256 00:15:58,199 --> 00:16:03,389 because they aren't presenting the right chain of certificates, among other things. 257 00:16:03,389 --> 00:16:05,290 And 3% of the names we've issued for 258 00:16:05,290 --> 00:16:07,529 don't serve HTTPS at all. 259 00:16:07,529 --> 00:16:11,220 Now this actually is probably quite small 260 00:16:11,220 --> 00:16:15,139 because we only scan for HTTPS. 261 00:16:15,139 --> 00:16:16,529 People could be using these certificates 262 00:16:16,529 --> 00:16:22,249 for mail servers or IRC servers or XMPP servers and we wouldn't know. 263 00:16:22,249 --> 00:16:25,049 And we can see that 45% of the certificates 264 00:16:25,049 --> 00:16:30,079 are used by every single DNS name that they contain. 265 00:16:30,079 --> 00:16:32,629 Which is actually a quite good number. 266 00:16:32,629 --> 00:16:35,549 So, looking at the Firefox telemetry, 267 00:16:35,549 --> 00:16:41,339 we see that only 0.1% of currently successful TLS handshakes 268 00:16:41,339 --> 00:16:43,829 use a Let's Encrypt certificate. 269 00:16:43,829 --> 00:16:48,519 Now this sounds very low, but it actually makes a lot of sense. 270 00:16:48,519 --> 00:16:49,660 We don't plan to … 271 00:16:49,660 --> 00:16:50,949 or … our goal is not to make 272 00:16:50,949 --> 00:16:54,889 the largest websites on the Internet use our certificates. 273 00:16:54,889 --> 00:16:57,769 If that happened, the percentage of successful TLS handshakes 274 00:16:57,769 --> 00:17:00,889 that we were involved in would be much higher. 275 00:17:00,889 --> 00:17:06,630 But our goal is to issue certificates to the long tail of people. 276 00:17:06,630 --> 00:17:09,829 People who may not have hundreds of thousands of visitors 277 00:17:09,829 --> 00:17:11,160 to their website 278 00:17:11,160 --> 00:17:15,660 but should still be able to use cryptographic protocols. 279 00:17:15,660 --> 00:17:21,069 So, we have an official client which is called "Let's Encrypt" 280 00:17:21,069 --> 00:17:28,870 but … which is currently used by about 65% of our users. 281 00:17:28,870 --> 00:17:32,490 This is a very complicated client 282 00:17:32,490 --> 00:17:34,440 and it will do a lot of things for you. 283 00:17:34,440 --> 00:17:40,090 It will manage renewal, it will manage installing 284 00:17:40,090 --> 00:17:43,530 into your either Apache or nginx server among other things. 285 00:17:43,530 --> 00:17:46,300 But there've also been, since we entered public beta, 286 00:17:46,300 --> 00:17:50,010 around 30 unique 3rd party clients that have popped up. 287 00:17:50,010 --> 00:17:55,700 For pretty much any scenario you might want to use a certificate for, 288 00:17:55,700 --> 00:17:58,810 including a web server called "Caddy" 289 00:17:58,810 --> 00:18:02,750 that has a built-in ACME client, which means that as soon as … 290 00:18:02,750 --> 00:18:06,450 you can turn on your web server and if you don't have an SSL certificate, 291 00:18:06,450 --> 00:18:11,160 it will automatically go out and fetch one for you. 292 00:18:11,160 --> 00:18:16,310 Another one is a web based client so you can go in your browser and 293 00:18:16,310 --> 00:18:22,870 generate a certificate without installing anything on your system at all. 294 00:18:22,870 --> 00:18:25,410 So our main goal is actually to get 295 00:18:25,410 --> 00:18:28,060 Hosting providers and Content Distribution Networks 296 00:18:28,060 --> 00:18:30,360 to use our certificates. 297 00:18:30,360 --> 00:18:34,790 While most people here might want to just go out and install a certificate 298 00:18:34,790 --> 00:18:37,160 on the server they run themselves, 299 00:18:37,160 --> 00:18:41,040 the majority of people who are running smaller websites are using 300 00:18:41,040 --> 00:18:44,830 a hosting provider who will run all of this for them. 301 00:18:44,830 --> 00:18:49,570 And, generally, these people will charge for certificates 302 00:18:49,570 --> 00:18:52,120 and our goal is to try and get them to 303 00:18:52,120 --> 00:18:54,150 a) make it free, and 304 00:18:54,150 --> 00:18:57,490 b) make it painless for the users. 305 00:18:57,490 --> 00:19:02,300 So, so far we have Akamai, KeyCDN, DreamHost, Cyon and Pressjitsu 306 00:19:02,300 --> 00:19:06,090 —these are both hosting providers and Content Distribution networks 307 00:19:06,090 --> 00:19:08,440 who have already integrated with Let's Encrypt 308 00:19:08,440 --> 00:19:13,960 and will allow you to get a certificate completely for free. 309 00:19:13,960 --> 00:19:15,850 And we assume that, in the long term, 310 00:19:15,850 --> 00:19:18,580 this will make up the majority of our usage. 311 00:19:18,580 --> 00:19:22,620 Most likely, people issuing hundreds of thousands of certificates 312 00:19:22,620 --> 00:19:27,770 won't be individuals, they'll be hosting providers. 313 00:19:27,770 --> 00:19:29,530 So our … 314 00:19:29,530 --> 00:19:32,890 We still have a lot of work to do on our Certificate Authority. 315 00:19:32,890 --> 00:19:39,130 Currently, you can only do validation based on either HTTP or HTTPS. 316 00:19:39,130 --> 00:19:44,180 This has made it quite complicated for people who have very complex set-ups, 317 00:19:44,180 --> 00:19:49,620 that are using load-balancers or other systems 318 00:19:49,620 --> 00:19:53,440 to validate their websites. 319 00:19:53,440 --> 00:19:57,760 One of our solutions for this is the DNS challenge which will allow anyone 320 00:19:57,760 --> 00:20:02,810 to just add a DNS record and automatically validate the domain name they want. 321 00:20:02,810 --> 00:20:08,350 We also want to implement a "Proof of Possession" challenge. 322 00:20:08,350 --> 00:20:11,500 This means that if you asked for a certificate for a Domain Name 323 00:20:11,500 --> 00:20:15,640 that we know is already using an SSL certificate, 324 00:20:15,640 --> 00:20:20,770 we'll ask you to prove that you control the private key of that certificate. 325 00:20:20,770 --> 00:20:26,440 And this is a extra way to verify 326 00:20:26,440 --> 00:20:29,610 that a single person won't control 327 00:20:29,610 --> 00:20:34,010 or can't mis-issue a certificate for a domain they can't control. 328 00:20:34,010 --> 00:20:36,980 We also want to add Multi-Path Validation. 329 00:20:36,980 --> 00:20:39,440 Currently, we validate from a single point. 330 00:20:39,440 --> 00:20:44,150 And this means that we are susceptible to network-local attacks. 331 00:20:44,150 --> 00:20:48,220 —but this will change very soon. 332 00:20:48,220 --> 00:20:50,620 Alright, thank you. 333 00:20:50,620 --> 00:21:03,410 *applause* 334 00:21:03,410 --> 00:21:07,480 Angel: Thank you. The first few questions are for the Internet. 335 00:21:07,480 --> 00:21:10,390 Signal Angel: Okay, the first question from the Internet is: 336 00:21:10,390 --> 00:21:15,980 Question: Given the critics on the official client, wouldn't it have been 337 00:21:15,980 --> 00:21:21,590 better to split the service and the client? 338 00:21:21,590 --> 00:21:26,920 Shoemaker: I think … 339 00:21:26,920 --> 00:21:30,570 The client is a very hard thing to implement 340 00:21:30,570 --> 00:21:35,920 and we, because we're the people who created the protocol, 341 00:21:35,920 --> 00:21:40,410 I think it makes sense for us to also work on trying to create the client for it. 342 00:21:40,410 --> 00:21:44,950 If we had just waited for somebody else to do it, 343 00:21:44,950 --> 00:21:50,970 I don't think we would've been able to get as far as we have so far. 344 00:21:50,970 --> 00:21:55,950 SigAngQ: The second question is … 345 00:21:55,950 --> 00:21:58,800 that, well, a lot of people are apparently interested in your t-shirt 346 00:21:58,800 --> 00:22:01,360 and want to know: 1) what's on it and 347 00:22:01,360 --> 00:22:03,810 2) where can they get one. 348 00:22:03,810 --> 00:22:06,400 Shoemaker: Unfortunately, these aren't for sale … yet. 349 00:22:06,400 --> 00:22:09,080 But they should be very soon. 350 00:22:09,080 --> 00:22:11,720 And you may notice that this is supposed to be the 351 00:22:11,720 --> 00:22:14,040 contents of a certificate. 352 00:22:14,040 --> 00:22:17,950 You can try and decode it, but I don't think you'll get very far. 353 00:22:17,950 --> 00:22:22,370 StgMgr: Okay, next question from microphone #1. 354 00:22:22,370 --> 00:22:25,780 Q: Since I've tried your service and it works very well, 355 00:22:25,780 --> 00:22:29,600 I was wondering what keeps you from going into public. 356 00:22:29,600 --> 00:22:36,640 I mean, you're now choosing a Beta type —what is "Beta" in your service, currently? 357 00:22:36,640 --> 00:22:42,240 Shmk: Well … chuckles our service hasn't been completely tested. 358 00:22:42,240 --> 00:22:43,740 *slight laughter* 359 00:22:43,740 --> 00:22:47,260 We wouldn't suggest that a website like Facebook 360 00:22:47,260 --> 00:22:49,860 that gets millions of requests a day 361 00:22:49,860 --> 00:22:53,530 would deploy one of our certificates just yet. 362 00:22:53,530 --> 00:22:59,520 Yeah … It is … Currently, we have a hard limit on 363 00:22:59,520 --> 00:23:02,080 how many certificates we're able to issue 364 00:23:02,080 --> 00:23:05,460 due to our hardware security modules 365 00:23:05,460 --> 00:23:09,710 and because of that, we're kind of trying to take it slowly for now. 366 00:23:09,710 --> 00:23:11,620 Q: But it works? 367 00:23:11,620 --> 00:23:14,350 Shmk: Yeah. As far as we now. chuckles. 368 00:23:14,350 --> 00:23:17,740 StgMgr: Okay, next question from microphone #2. 369 00:23:17,740 --> 00:23:21,580 Q: Hi. What are you using for revocation? Are you using the 370 00:23:21,580 --> 00:23:25,250 standard-defined revocation lists or do you have your own solution? 371 00:23:25,250 --> 00:23:30,560 We're using OCSP, our plan is to promote OCSP Stapling 372 00:23:30,560 --> 00:23:37,450 *applause* 373 00:23:37,450 --> 00:23:44,000 The CRL model is too broken and we're kind of trying to push 374 00:23:44,000 --> 00:23:48,190 both Apache and nginx to get to act together with OCSP Stapling 375 00:23:48,190 --> 00:23:52,490 so that it'll actually be a useful revocation method. 376 00:23:52,490 --> 00:23:57,170 StgMgr: Okay, next question is for the Internet, and after that microphone 1 again. 377 00:23:57,170 --> 00:23:58,440 SigAngQ: Okay, the question is: 378 00:23:58,440 --> 00:24:02,720 Why is there a limit on certificate issues per domain? 379 00:24:02,720 --> 00:24:05,600 Because that is especially annoying for dynamic DNS users. 380 00:24:05,600 --> 00:24:07,550 Shmk: Yes. We agree. 381 00:24:07,550 --> 00:24:12,880 Currently, we use the Public Suffix List to decide how many certificates 382 00:24:12,880 --> 00:24:14,740 a domain should get. 383 00:24:14,740 --> 00:24:21,610 So if you have, say, roan.com, you'll only be able to get 5 certificates for that domain. 384 00:24:21,610 --> 00:24:25,430 Currently, this is because we have a hard limit on how many certificates 385 00:24:25,430 --> 00:24:28,900 we are able to issue, so we don't want a single user to be able to go out 386 00:24:28,900 --> 00:24:34,160 and take off a significant percentage of that. 387 00:24:34,160 --> 00:24:37,570 We're trying to figure out a better rate-limiting solution. 388 00:24:37,570 --> 00:24:41,400 You should notice in the future that you'll be able to issue a lot more certificates 389 00:24:41,400 --> 00:24:45,490 but we're just not there, yet. 390 00:24:45,490 --> 00:24:50,130 Q: Hi. First, thanks for the talk and for the great aim I think we all support. 391 00:24:50,130 --> 00:24:55,160 I have a question regarding the audit that has to be done by Let's Encrypt, 392 00:24:55,160 --> 00:25:00,560 because for new kids on the block, usually there is this kind of certain audits 393 00:25:00,560 --> 00:25:04,140 where the Mozilla Foundation also was a part of creating this 394 00:25:04,140 --> 00:25:07,870 and as I know, there is a three-month grace period 395 00:25:07,870 --> 00:25:10,730 of like handing in all the papers and whatever afterwards 396 00:25:10,730 --> 00:25:13,960 and if you started in September, that means, now we're in December, 397 00:25:13,960 --> 00:25:16,930 so what's the status of this whole audit thing? 398 00:25:16,930 --> 00:25:19,860 And, as I know, maybe you can comment on this as well: 399 00:25:19,860 --> 00:25:22,370 The cross-validation does not count for this?! 400 00:25:22,370 --> 00:25:23,660 So I'd be very interested. 401 00:25:23,660 --> 00:25:29,270 Shmk: So, we are not yet in the root programmes of any of the major Browsers. 402 00:25:29,270 --> 00:25:35,550 We've, I think, just finished our audits. 403 00:25:35,550 --> 00:25:39,270 Unfortunately, a cross-signature doesn't require any audits. 404 00:25:39,270 --> 00:25:42,600 If you can pay a Certificate Authority enough money, they will cross-sign 405 00:25:42,600 --> 00:25:45,760 one of your certificates and allow you to issue. 406 00:25:45,760 --> 00:25:49,650 It's a very silly system. 407 00:25:49,650 --> 00:25:57,100 So, yeah, it means that we can currently issue completely valid, trusted certificates, 408 00:25:57,100 --> 00:26:03,310 but we are not a member of the organisation that decides how that works. 409 00:26:03,310 --> 00:26:06,040 It's strange … 410 00:26:06,040 --> 00:26:07,910 StgMgr: Next question from microphone #5? 411 00:26:07,910 --> 00:26:13,930 Q: Hi. I, first of all, would like to thank everyone working on this project, 412 00:26:13,930 --> 00:26:16,880 you guys are awesome! Shoemaker: Thank you! 413 00:26:16,880 --> 00:26:23,030 *applause* 414 00:26:23,030 --> 00:26:26,700 Q: So, I've got a question regarding nginx. 415 00:26:26,700 --> 00:26:35,200 Do you know when you might have it completely supported? 416 00:26:35,200 --> 00:26:38,910 Shoemaker: I'm not 100% sure. We're working on … 417 00:26:38,910 --> 00:26:42,230 —this is kind of our main focus in the client right now. 418 00:26:42,230 --> 00:26:48,490 We're increasing how well the Apache and nginx plug-ins work, 419 00:26:48,490 --> 00:26:51,150 nginx has kind of got the short end of the stick currently 420 00:26:51,150 --> 00:26:56,530 because the majority of people we are working with are using Apache. 421 00:26:56,530 --> 00:26:59,820 The next few months, this should improve significantly. 422 00:26:59,820 --> 00:27:02,150 Q: Okay, thank you. 423 00:27:02,150 --> 00:27:06,620 StgMgr: Next question is from microphone #4 and then we'll be go back to the Internet. 424 00:27:06,620 --> 00:27:08,340 Q: So, I have two: 425 00:27:08,340 --> 00:27:13,520 So, let's that that tomorrow SHA-2, suddenly there's a big attack, 426 00:27:13,520 --> 00:27:17,370 everyone should move to SHA-3, but unfortunately, as we all know, 427 00:27:17,370 --> 00:27:19,810 many clients would lag. 428 00:27:19,810 --> 00:27:21,320 How would you plan to solve this situation? 429 00:27:21,320 --> 00:27:26,030 Will you push everyone to migrate instantly to SHA-3? 430 00:27:26,030 --> 00:27:31,580 Will you cater to those of your users that would like to remain, you know, 431 00:27:31,580 --> 00:27:33,440 as compatible as possible? 432 00:27:33,440 --> 00:27:35,280 And, kind of related to that, 433 00:27:35,280 --> 00:27:38,440 can you give us —I'm sure, you've been asked this question a lot 434 00:27:38,440 --> 00:27:43,410 —why 90 days? Why not a lot less and maybe even get rid of the entire 435 00:27:43,410 --> 00:27:48,240 revocation system, why not more? Can you give us a little glimpse 436 00:27:48,240 --> 00:27:50,710 on how you want to handle these decisions? 437 00:27:50,710 --> 00:27:54,510 Shoemaker: So, the first question: 438 00:27:54,510 --> 00:27:59,400 That decision isn't 100% up to us. It'd be more up to the CA/B forum 439 00:27:59,400 --> 00:28:02,840 and how they choose to sunset the algorithm. 440 00:28:02,840 --> 00:28:07,210 Most likely, we'd continue issuing until the deadline 441 00:28:07,210 --> 00:28:11,700 so that people can switch over as seamlessly as possible. 442 00:28:11,700 --> 00:28:18,060 But again, that's kind of a policy question for the governing body. 443 00:28:18,060 --> 00:28:21,850 And then, the 90 days: We've been considering allowing 444 00:28:21,850 --> 00:28:24,460 less than 90 days, so if you'd like to 445 00:28:24,460 --> 00:28:29,580 issue a 1-day certificate or a 2-day certificate, that should be possible. 446 00:28:29,580 --> 00:28:31,750 We decided that there should be a hard limit, though, 447 00:28:31,750 --> 00:28:35,240 on how long a certificate we are willing to issue. 448 00:28:35,240 --> 00:28:38,460 And 90 days is, in part, due to how long 449 00:28:38,460 --> 00:28:41,400 we would think a certificate that was compromised 450 00:28:41,400 --> 00:28:47,210 is safe to be around, and that should be as small as possible. 451 00:28:47,210 --> 00:28:49,930 Unfortunately, renewal is still a hard problem, 452 00:28:49,930 --> 00:28:54,330 so we can't just say "a week" or "two weeks" 453 00:28:54,330 --> 00:29:00,860 and ninety days was kind of what we came down to is the safest. 454 00:29:00,860 --> 00:29:02,760 Stage Manager: Okay, last question is for the Internet. 455 00:29:02,760 --> 00:29:05,190 SigAngQ: Okay, then the last question will be: 456 00:29:05,190 --> 00:29:08,060 What is the stack that you use to generate the certificates? 457 00:29:08,060 --> 00:29:11,360 Do you have any special optimisation, like code or hardware to 458 00:29:11,360 --> 00:29:14,330 keep up with the increased demand? 459 00:29:14,330 --> 00:29:19,410 Shoemaker: So … We sign our certificates using hardware security modules and 460 00:29:19,410 --> 00:29:23,640 there's a library produced by CloudFlare which they use for their 461 00:29:23,640 --> 00:29:28,630 universal SSL programme, which is called CFSSL, 462 00:29:28,630 --> 00:29:31,500 but there is no special process involved. 463 00:29:31,500 --> 00:29:37,590 It's just typical X.509 generation. 464 00:29:37,590 --> 00:29:40,030 Stage Manager: Okay, thank you very much. 465 00:29:40,030 --> 00:29:45,440 *applause* 466 00:29:45,440 --> 00:29:55,810 *music*