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:51,400
music
467
00:29:51,400 --> 00:29:57,000
subtitles created by c3subtitles.de
in the year 2016. Join, and help us!