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*