WEBVTT
00:00:00.290 --> 00:00:48.030
music still playing,
no audio available for speaker
00:00:48.030 --> 00:00:51.940
provide both confidentiality,
integrity, and authenticity
00:00:51.940 --> 00:00:55.470
so this means that nobody can see
what you're looking at
00:00:55.470 --> 00:00:58.440
nobody can change what you're looking at
00:00:58.440 --> 00:01:02.489
and you know that the person
who is sending you this
00:01:02.489 --> 00:01:04.459
is a specific person.
00:01:04.459 --> 00:01:08.830
They use signed digital certificates.
00:01:08.830 --> 00:01:12.630
Each one of these certificates must
be signed by another certificate
00:01:12.630 --> 00:01:16.220
and if you want to be trusted,
they have to chain up
00:01:16.220 --> 00:01:21.720
to a certificate issued by
a publicly trusted certificate authority.
00:01:21.720 --> 00:01:26.570
Who decides, who gets a certificate
and who doesn't?
00:01:26.570 --> 00:01:29.009
Why do we have to launch another one?
00:01:29.009 --> 00:01:34.190
Well, the Internet is a bad place.
00:01:34.190 --> 00:01:41.080
It's extremely easy to modify or to observe
HTTP communication.
00:01:41.080 --> 00:01:44.700
There've been a number of attacks
that have demonstrated this over the years
00:01:44.700 --> 00:01:49.959
including cookie session re-use and others.
00:01:49.959 --> 00:01:52.820
Based on telemetry from the Firefox browser,
00:01:52.820 --> 00:01:59.900
we know that only 40% of
initial HTTP requests go over HTTPS.
00:01:59.900 --> 00:02:04.549
This is probably because both
getting and installing a certificate
00:02:04.549 --> 00:02:08.038
as well as setting up
all the correct TLS parameters
00:02:08.038 --> 00:02:11.219
is extremely confusing.
00:02:11.219 --> 00:02:14.389
And in part this is because every CA decides,
00:02:14.389 --> 00:02:19.099
how it will issue a certificate on its own.
00:02:19.099 --> 00:02:22.029
So our solution is
to create another Certificate Authority.
00:02:22.029 --> 00:02:26.419
I mean, what can go wrong?
00:02:26.419 --> 00:02:30.999
So, because we're the EFF and Mozilla,
00:02:30.999 --> 00:02:34.660
we've decided that
it should be completely free.
00:02:34.660 --> 00:02:39.120
Cryptography shouldn't be something that
you have to pay for on the Internet.
00:02:39.120 --> 00:02:40.989
And unfortunately, right now …
00:02:40.989 --> 00:02:48.639
applause
00:02:48.639 --> 00:02:51.189
So unfortunately right know there are only
00:02:51.189 --> 00:02:54.829
two certificate authorities that are willing
to issue free certificates
00:02:54.829 --> 00:02:56.629
except for Let's Encrypt.
00:02:56.629 --> 00:02:59.510
And unfortunately, both of them make it
00:02:59.510 --> 00:03:01.439
a quite complicated process and
00:03:01.439 --> 00:03:03.709
will exclude you from getting a certificate
00:03:03.709 --> 00:03:07.329
if you fall into certain groups.
00:03:07.329 --> 00:03:08.419
So we decided to make it free
00:03:08.419 --> 00:03:11.150
and we also decided to make it open-source.
00:03:11.150 --> 00:03:13.760
We did this because it's extremely hard
00:03:13.760 --> 00:03:16.389
to tell, what Certificate Authorities
are actually doing
00:03:16.389 --> 00:03:20.509
and how they decide
whether or not to issue a certificate.
00:03:20.519 --> 00:03:22.589
So we decided
it'd be best to come up
00:03:22.589 --> 00:03:27.400
with a standardised protocol
which we've called ACME
00:03:27.400 --> 00:03:31.839
so that we can get everybody's input
00:03:31.839 --> 00:03:35.980
on what is the most secure way
that we can do this.
00:03:35.980 --> 00:03:37.980
Let's Encrypt has already launched
00:03:37.980 --> 00:03:40.079
and you can—right now—go and get
00:03:40.079 --> 00:03:43.989
a publicly trusted,
free certificate from us.
00:03:43.989 --> 00:03:48.299
Unfortunately, this isn't a
cheap thing to do.
00:03:48.299 --> 00:03:50.719
So we've been sponsored by a large number
00:03:50.719 --> 00:03:53.930
of industry people including
00:03:53.930 --> 00:03:55.949
a bunch of hosting providers
00:03:55.949 --> 00:04:00.169
Mozilla, Cisco, Akamai,
who is a Content Distribution Network
00:04:00.169 --> 00:04:05.260
and the EFF, among others. chuckles
00:04:05.260 --> 00:04:11.010
So, the CA and TLS ecosystem is
a pretty strange place.
00:04:11.010 --> 00:04:15.709
Before we got there, this is a map of
00:04:15.709 --> 00:04:20.240
every single trusted Certificate Authority
that currently exists.
00:04:20.240 --> 00:04:22.540
Every single one of these nodes can issue
00:04:22.540 --> 00:04:27.960
a certificate that your browser
will completely trust.
00:04:27.960 --> 00:04:29.420
And this is ridiculous!
00:04:29.420 --> 00:04:34.700
The fact that there are
over 1'600 Certificate Authorities
00:04:34.700 --> 00:04:37.790
is very silly.
00:04:37.790 --> 00:04:42.160
You can actually see Let's Encrypt is
one of the small magenta nodes
00:04:42.160 --> 00:04:44.710
in the bottom left-hand corner.
00:04:44.710 --> 00:04:47.080
Unfortunately, we haven't surpassed
00:04:47.080 --> 00:04:49.520
some of the other
Certificate Authorities yet,
00:04:49.520 --> 00:04:53.720
but that's soon to happen.
00:04:53.720 --> 00:04:57.100
There's a group called "The CA Browser Forum"
00:04:57.100 --> 00:05:04.060
and these are the people who decide
how the CA and TLS ecosystem works.
00:05:04.060 --> 00:05:07.820
Because CAs have a slightly vested interest
00:05:07.820 --> 00:05:11.690
in making money over protecting users,
00:05:11.690 --> 00:05:14.970
there's often a rift between them
and the browsers
00:05:14.970 --> 00:05:18.200
and how rules should be made
00:05:18.200 --> 00:05:23.000
that affect publicly trusted certificates
and Certificate Authorities.
00:05:23.000 --> 00:05:25.160
Because of this, they decided
to come together
00:05:25.160 --> 00:05:29.520
and self-govern themselves in order to have
…
00:05:29.520 --> 00:05:32.340
bring order about …
00:05:32.340 --> 00:05:36.700
The Browsers generally yield
slightly more power
00:05:36.700 --> 00:05:38.860
than the Certificate Authorities.
00:05:38.860 --> 00:05:41.000
They require a larger number of …
00:05:41.000 --> 00:05:44.560
a larger majority in order to pass a rule.
00:05:44.560 --> 00:05:48.420
And this is because, like I said previously,
00:05:48.420 --> 00:05:52.420
Certificate Authorities are generally
guided by making money
00:05:52.420 --> 00:05:56.970
whereas the browsers are generally
guided by trying to keep users safe.
00:05:56.970 --> 00:06:01.660
Unfortunately, Let's Encrypt is
not yet a member of this group
00:06:01.660 --> 00:06:04.140
because they have very stringent requirements
00:06:04.140 --> 00:06:05.830
for membership, which include
00:06:05.830 --> 00:06:08.630
a number of audits we haven't yet completed,
00:06:08.630 --> 00:06:12.690
although we're very close to doing so.
00:06:12.690 --> 00:06:14.170
Like I said …
00:06:14.170 --> 00:06:16.620
The CA/B Forum creates rules
00:06:16.620 --> 00:06:18.910
called the "Baseline requirements"
00:06:18.910 --> 00:06:22.430
which every Certificate Authority
must comply with
00:06:22.430 --> 00:06:26.790
if they wish to be trusted by browsers.
00:06:26.790 --> 00:06:30.770
This includes basically documenting
every process that's involved
00:06:30.770 --> 00:06:32.840
with issuance of a certificate
00:06:32.840 --> 00:06:36.260
and takes a very long time.
00:06:36.260 --> 00:06:40.290
So the CA/B also chooses the different
00:06:40.290 --> 00:06:42.450
security levels of a certificate
00:06:42.450 --> 00:06:44.770
—these are called "validation levels".
00:06:44.770 --> 00:06:47.580
There are currently three and
it should be noted that
00:06:47.580 --> 00:06:50.170
cryptographically, there is no difference
00:06:50.170 --> 00:06:53.800
between each of these "levels of validation".
00:06:53.800 --> 00:06:59.800
What they mean is how thoroughly a CA
00:06:59.800 --> 00:07:04.180
has validated a person
who is requesting a certificate.
00:07:04.180 --> 00:07:06.230
Domain validation is what we're interested
in.
00:07:06.230 --> 00:07:09.430
It basically just means that—as a CA—
00:07:09.430 --> 00:07:14.780
we can verify that you control
a certain DNS name.
00:07:14.780 --> 00:07:21.310
Now there are a few extra steps for
organizational validation.
00:07:21.310 --> 00:07:24.550
This means that a CA would have to validate
00:07:24.550 --> 00:07:29.060
that you're an owner of a certain business
in a certain country.
00:07:29.060 --> 00:07:31.620
And Extended Validation goes even further
00:07:31.620 --> 00:07:35.550
and checks other governmental records.
00:07:35.550 --> 00:07:40.389
Both OV and EV certificates don't provide
any more security.
00:07:40.389 --> 00:07:44.300
All they provide is UI hints in the browser.
00:07:44.300 --> 00:07:50.220
So with an EV certificate you'll see
a green box in your URL bar
00:07:50.220 --> 00:07:52.740
that says the name of a company.
00:07:52.740 --> 00:07:57.130
But cryptographically, these certificates
are exactly the same.
00:07:57.130 --> 00:08:00.150
So where does Let's Encrypt fit into this?
00:08:00.150 --> 00:08:03.650
Like I said, we're doing
everything completely for free.
00:08:03.650 --> 00:08:07.400
This includes issuance, renewal, and revocation
00:08:07.400 --> 00:08:12.620
—and any other action you'd do with us
is entirely free.
00:08:12.620 --> 00:08:15.470
We're not charging anyone anything.
00:08:15.470 --> 00:08:22.180
We're also only going to be issuing
Domain validated certificates.
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.
00:08:27.870 --> 00:08:30.120
Our system is entirely automated.
00:08:30.120 --> 00:08:37.058
The only people that we hire are
operations and maintenance people.
00:08:37.058 --> 00:08:38.928
We're also only issuing certificates
that are
00:08:38.928 --> 00:08:43.929
valid for a maximum of 90 days.
00:08:43.929 --> 00:08:45.240
We originally decided on doing this
00:08:45.240 --> 00:08:49.300
because in the previous world where certificates
00:08:49.300 --> 00:08:54.480
were valid for anywhere from 1–3 years,
00:08:54.480 --> 00:08:59.959
it made it really hard to figure out
how to automate renewal of a certificate.
00:08:59.959 --> 00:09:04.249
You'd, every once a year,
go to your Certificate Authority
00:09:04.249 --> 00:09:06.139
and ask for a new certificate
00:09:06.139 --> 00:09:07.589
and then spend the next few hours
00:09:07.589 --> 00:09:10.480
trying to figure out
what you had to tell them
00:09:10.480 --> 00:09:14.519
and how you'd install it in your server.
00:09:14.519 --> 00:09:19.610
By limiting the validity period to 90 days,
00:09:19.610 --> 00:09:24.410
we're ensuring that people are forced
to renew often.
00:09:24.410 --> 00:09:26.889
And this also comes with a good side-effect
00:09:26.889 --> 00:09:29.370
that if their certificate becomes compromised,
00:09:29.370 --> 00:09:34.870
it is only compromised for
a maximum of 90 days.
00:09:34.870 --> 00:09:38.040
Which makes it slightly safer.
00:09:38.040 --> 00:09:43.360
So we're also issuing multiple domain certificates
instead of wildcard certificates.
00:09:43.360 --> 00:09:46.249
These use Subject Alternative Names (SAN)
00:09:46.249 --> 00:09:48.970
with multiple DNS names inside of a certificate
00:09:48.970 --> 00:09:51.430
meaning that a single certificate can be used
00:09:51.430 --> 00:09:56.980
to validate up to a hundred domains.
00:09:56.980 --> 00:10:01.730
In order to make our certificates actually
publicly trusted
00:10:01.730 --> 00:10:06.089
we've applied to the
Mozilla, Apple, Google, and Microsoft root
00:10:06.089 --> 00:10:07.670
programmes
00:10:07.670 --> 00:10:11.480
but we've also had one of our Intermediate
Certificates
00:10:11.480 --> 00:10:16.350
cross-signed by IdenTrust,
which is another Certificate Authority.
00:10:16.350 --> 00:10:18.939
This means that every certificate we issue
00:10:18.939 --> 00:10:21.350
is already trusted.
00:10:21.350 --> 00:10:24.339
So we don't have to worry about old devices
00:10:24.339 --> 00:10:28.339
not trusting our certificates.
00:10:28.339 --> 00:10:34.920
So, we started a closed beta
in about early September
00:10:34.920 --> 00:10:38.889
and this went from …
all the way up to December, 3rd
00:10:38.889 --> 00:10:40.399
and during that period we only issued
00:10:40.399 --> 00:10:42.329
about 20'000 certificates.
00:10:42.329 --> 00:10:45.589
You can see that the first period in september
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.
00:10:53.999 --> 00:10:56.249
And then we opened a Closed Beta
00:10:56.249 --> 00:10:59.340
and we issued around 20'000 more
00:10:59.340 --> 00:11:03.050
and then on December, 3rd, we opened up to
everyone.
00:11:03.050 --> 00:11:05.449
You didn't have to apply to join and
00:11:05.449 --> 00:11:07.160
we'd issue a certificate as long
as you could prove
00:11:07.160 --> 00:11:09.709
that you controlled a domain.
00:11:09.709 --> 00:11:13.639
In the first day, we doubled the number of
certificates we issued.
00:11:13.639 --> 00:11:16.189
And in a week, I think, we quadrupled it.
00:11:16.189 --> 00:11:18.769
I mean, in the first 12 hours we were issuing
00:11:18.769 --> 00:11:23.529
a certificate almost every two seconds.
00:11:23.529 --> 00:11:24.779
And since then, we've issued
00:11:24.779 --> 00:11:32.189
over 200'000 certificates across 440'000 domain
names.
00:11:32.189 --> 00:11:34.329
This is … we're still in beta though.
00:11:34.329 --> 00:11:36.089
That should be noted.
00:11:36.089 --> 00:11:41.240
We don't expect to be …
00:11:41.240 --> 00:11:43.580
We expect to do a Google-style Beta
00:11:43.580 --> 00:11:48.260
—it will probably take a while.
00:11:48.260 --> 00:11:52.240
Using Certificate Transparency Logs
00:11:52.240 --> 00:11:54.899
which are a collection that Google has created
00:11:54.899 --> 00:12:00.019
of almost all currently valid certificates
00:12:00.019 --> 00:12:02.509
we can see that Let's Encrypt is already
00:12:02.509 --> 00:12:05.309
the fifth largest Certificate Authority
00:12:05.309 --> 00:12:09.549
and we're already larger than both WoSign and StartSSL
00:12:09.549 --> 00:12:15.270
the two currently free
public Certificate Authorities.
00:12:15.270 --> 00:12:22.730
applause
00:12:22.730 --> 00:12:24.699
So our goal is to …
00:12:24.699 --> 00:12:27.249
it isn't to be the largest Certificate Authority
00:12:27.249 --> 00:12:29.559
but it is to raise the total percentage
00:12:29.559 --> 00:12:34.080
of connections on the internet
that go over HTTPS.
00:12:34.080 --> 00:12:39.910
applause
00:12:39.910 --> 00:12:42.869
So this is a very hard thing to measure.
00:12:42.869 --> 00:12:44.819
Unless you're sitting on a backbone,
00:12:44.819 --> 00:12:47.660
it's almost impossible to tell what percentage
00:12:47.660 --> 00:12:51.089
is going over HTTP
and what percentage is going over HTTPS.
00:12:51.089 --> 00:12:54.439
Luckily, Firefox can provide us with
00:12:54.439 --> 00:12:59.170
certain TLS telemetry about what
Certificate Authorities
00:12:59.170 --> 00:13:01.529
issue certificates that they're seeing
00:13:01.529 --> 00:13:04.720
and we can also use Certificate Transparency
00:13:04.720 --> 00:13:10.350
to try and figure out how people are
actually using our certificates.
00:13:10.350 --> 00:13:12.179
We have a bunch of stats …
00:13:12.179 --> 00:13:16.269
There are currently over
a 120'000 individual registrations.
00:13:16.269 --> 00:13:20.319
So, we count … a single registration
can issue multiple certificates
00:13:20.319 --> 00:13:25.110
and we see that there are currently only
about two certificates per registration
00:13:25.110 --> 00:13:27.999
with two DNS names per certificate.
00:13:27.999 --> 00:13:31.249
Now this is most likely because people
are just testing the servers
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
00:13:37.230 --> 00:13:40.459
and not very many people are using
00:13:40.459 --> 00:13:47.279
very large certificates with multiple
Subject Alternate Names yet.
00:13:47.279 --> 00:13:50.889
We see that around 33% of the names
that we issued for
00:13:50.889 --> 00:13:53.980
have multiple certificates
with that name in them.
00:13:53.980 --> 00:13:55.779
This is actually a very common thing
00:13:55.779 --> 00:13:58.179
we were expecting to see.
00:13:58.179 --> 00:14:03.550
Because we issue a very large number
of certificates to Content Distribution Networks.
00:14:03.550 --> 00:14:07.009
And these Networks will have tons of endpoints
00:14:07.009 --> 00:14:09.839
that will work for a whole bunch
00:14:09.839 --> 00:14:11.759
of different websites.
00:14:11.759 --> 00:14:13.910
So they will, you know,
00:14:13.910 --> 00:14:17.639
maybe have 15 certificates that'll have
a set of 50 Domain Names
00:14:17.639 --> 00:14:21.170
spread out across them.
00:14:21.170 --> 00:14:23.480
We also see that 20% of certificates have
00:14:23.480 --> 00:14:26.829
the exact same duplicate name sets.
00:14:26.829 --> 00:14:29.019
This has probably more to do with
00:14:29.019 --> 00:14:31.540
people trying to get used
to our official client
00:14:31.540 --> 00:14:34.139
and us having to fix a few bugs in it
00:14:34.139 --> 00:14:37.269
—that meant that people would reissue
00:14:37.269 --> 00:14:39.379
the same certificate over and over
00:14:39.379 --> 00:14:44.079
without noticing that
they already had a valid one.
00:14:44.079 --> 00:14:47.449
But we're seeing that slowly decrease.
00:14:47.449 --> 00:14:50.689
We've also seen that
80% of the domain names that we've issued for
00:14:50.689 --> 00:14:52.459
have never had a certificate before,
00:14:52.459 --> 00:14:55.439
according to the Certificate Transparency logs.
00:14:55.439 --> 00:14:57.220
So we're actually providing people who
00:14:57.220 --> 00:15:01.009
previously wouldn't have got a TLS certificate
00:15:01.009 --> 00:15:03.469
with certificates.
00:15:03.469 --> 00:15:10.679
applause
00:15:10.679 --> 00:15:16.160
And we've had … about 1% of our total issuance
have been revoked so far,
00:15:16.160 --> 00:15:23.779
which is a good sign that our
system is actually working.
00:15:23.779 --> 00:15:28.059
So, in order to see how people are
actually deploying our certificates,
00:15:28.059 --> 00:15:30.809
we've written a very small TLS scanner
00:15:30.809 --> 00:15:32.279
that will go through the DNS names
00:15:32.279 --> 00:15:33.569
of certificates we've issued
00:15:33.569 --> 00:15:36.730
and try to see if they actually use them.
00:15:36.730 --> 00:15:38.699
We see that about 75% of the people
00:15:38.699 --> 00:15:40.589
that we've issued a certificate for
00:15:40.589 --> 00:15:45.259
have actually deployed it on
the domain name we've issued it for.
00:15:45.259 --> 00:15:49.259
And only 8% of those names have
a broken TLS configuration.
00:15:49.259 --> 00:15:50.970
This means, if you try to connect to them,
00:15:50.970 --> 00:15:53.799
your Browser would reject the certificate.
00:15:53.799 --> 00:15:56.139
This can be because they're using
00:15:56.139 --> 00:15:58.199
a self-signed certificate or
00:15:58.199 --> 00:16:03.389
because they aren't presenting the right
chain of certificates, among other things.
00:16:03.389 --> 00:16:05.290
And 3% of the names we've issued for
00:16:05.290 --> 00:16:07.529
don't serve HTTPS at all.
00:16:07.529 --> 00:16:11.220
Now this actually is probably quite small
00:16:11.220 --> 00:16:15.139
because we only scan for HTTPS.
00:16:15.139 --> 00:16:16.529
People could be using these certificates
00:16:16.529 --> 00:16:22.249
for mail servers or IRC servers or XMPP servers
and we wouldn't know.
00:16:22.249 --> 00:16:25.049
And we can see that 45% of the certificates
00:16:25.049 --> 00:16:30.079
are used by every single
DNS name that they contain.
00:16:30.079 --> 00:16:32.629
Which is actually a quite good number.
00:16:32.629 --> 00:16:35.549
So, looking at the Firefox telemetry,
00:16:35.549 --> 00:16:41.339
we see that only 0.1% of
currently successful TLS handshakes
00:16:41.339 --> 00:16:43.829
use a Let's Encrypt certificate.
00:16:43.829 --> 00:16:48.519
Now this sounds very low, but
it actually makes a lot of sense.
00:16:48.519 --> 00:16:49.660
We don't plan to …
00:16:49.660 --> 00:16:50.949
or … our goal is not to make
00:16:50.949 --> 00:16:54.889
the largest websites on the Internet
use our certificates.
00:16:54.889 --> 00:16:57.769
If that happened, the percentage of
successful TLS handshakes
00:16:57.769 --> 00:17:00.889
that we were involved in would be much higher.
00:17:00.889 --> 00:17:06.630
But our goal is to issue certificates
to the long tail of people.
00:17:06.630 --> 00:17:09.829
People who may not have
hundreds of thousands of visitors
00:17:09.829 --> 00:17:11.160
to their website
00:17:11.160 --> 00:17:15.660
but should still be able to use
cryptographic protocols.
00:17:15.660 --> 00:17:21.069
So, we have an official client
which is called "Let's Encrypt"
00:17:21.069 --> 00:17:28.870
but … which is currently used
by about 65% of our users.
00:17:28.870 --> 00:17:32.490
This is a very complicated client
00:17:32.490 --> 00:17:34.440
and it will do a lot of things for you.
00:17:34.440 --> 00:17:40.090
It will manage renewal,
it will manage installing
00:17:40.090 --> 00:17:43.530
into your either Apache or nginx server
among other things.
00:17:43.530 --> 00:17:46.300
But there've also been,
since we entered public beta,
00:17:46.300 --> 00:17:50.010
around 30 unique 3rd party clients
that have popped up.
00:17:50.010 --> 00:17:55.700
For pretty much any scenario you
might want to use a certificate for,
00:17:55.700 --> 00:17:58.810
including a web server called "Caddy"
00:17:58.810 --> 00:18:02.750
that has a built-in ACME client,
which means that as soon as …
00:18:02.750 --> 00:18:06.450
you can turn on your web server and if you
don't have an SSL certificate,
00:18:06.450 --> 00:18:11.160
it will automatically go out and
fetch one for you.
00:18:11.160 --> 00:18:16.310
Another one is a web based client so you
can go in your browser and
00:18:16.310 --> 00:18:22.870
generate a certificate without installing
anything on your system at all.
00:18:22.870 --> 00:18:25.410
So our main goal is actually to get
00:18:25.410 --> 00:18:28.060
Hosting providers and
Content Distribution Networks
00:18:28.060 --> 00:18:30.360
to use our certificates.
00:18:30.360 --> 00:18:34.790
While most people here might want to
just go out and install a certificate
00:18:34.790 --> 00:18:37.160
on the server they run themselves,
00:18:37.160 --> 00:18:41.040
the majority of people who are running
smaller websites are using
00:18:41.040 --> 00:18:44.830
a hosting provider who will
run all of this for them.
00:18:44.830 --> 00:18:49.570
And, generally, these people will
charge for certificates
00:18:49.570 --> 00:18:52.120
and our goal is to try and get them to
00:18:52.120 --> 00:18:54.150
a) make it free, and
00:18:54.150 --> 00:18:57.490
b) make it painless for the users.
00:18:57.490 --> 00:19:02.300
So, so far we have Akamai, KeyCDN, DreamHost,
Cyon and Pressjitsu
00:19:02.300 --> 00:19:06.090
—these are both hosting providers and
Content Distribution networks
00:19:06.090 --> 00:19:08.440
who have already integrated with Let's Encrypt
00:19:08.440 --> 00:19:13.960
and will allow you to get a certificate
completely for free.
00:19:13.960 --> 00:19:15.850
And we assume that, in the long term,
00:19:15.850 --> 00:19:18.580
this will make up the majority of our usage.
00:19:18.580 --> 00:19:22.620
Most likely, people issuing
hundreds of thousands of certificates
00:19:22.620 --> 00:19:27.770
won't be individuals,
they'll be hosting providers.
00:19:27.770 --> 00:19:29.530
So our …
00:19:29.530 --> 00:19:32.890
We still have a lot of work to do
on our Certificate Authority.
00:19:32.890 --> 00:19:39.130
Currently, you can only do validation
based on either HTTP or HTTPS.
00:19:39.130 --> 00:19:44.180
This has made it quite complicated
for people who have very complex set-ups,
00:19:44.180 --> 00:19:49.620
that are using load-balancers or other systems
00:19:49.620 --> 00:19:53.440
to validate their websites.
00:19:53.440 --> 00:19:57.760
One of our solutions for this is the
DNS challenge which will allow anyone
00:19:57.760 --> 00:20:02.810
to just add a DNS record and automatically
validate the domain name they want.
00:20:02.810 --> 00:20:08.350
We also want to implement a
"Proof of Possession" challenge.
00:20:08.350 --> 00:20:11.500
This means that if you asked for
a certificate for a Domain Name
00:20:11.500 --> 00:20:15.640
that we know is already using
an SSL certificate,
00:20:15.640 --> 00:20:20.770
we'll ask you to prove that you
control the private key of that certificate.
00:20:20.770 --> 00:20:26.440
And this is a extra way to verify
00:20:26.440 --> 00:20:29.610
that a single person won't control
00:20:29.610 --> 00:20:34.010
or can't mis-issue a certificate for
a domain they can't control.
00:20:34.010 --> 00:20:36.980
We also want to add Multi-Path Validation.
00:20:36.980 --> 00:20:39.440
Currently, we validate from a single point.
00:20:39.440 --> 00:20:44.150
And this means that we are susceptible to
network-local attacks.
00:20:44.150 --> 00:20:48.220
—but this will change very soon.
00:20:48.220 --> 00:20:50.620
Alright, thank you.
00:20:50.620 --> 00:21:03.410
applause
00:21:03.410 --> 00:21:07.480
Angel: Thank you.
The first few questions are for the Internet.
00:21:07.480 --> 00:21:10.390
Signal Angel: Okay, the first question
from the Internet is:
00:21:10.390 --> 00:21:15.980
Question: Given the critics on the
official client, wouldn't it have been
00:21:15.980 --> 00:21:21.590
better to split the service and the client?
00:21:21.590 --> 00:21:26.920
Shoemaker: I think …
00:21:26.920 --> 00:21:30.570
The client is a very hard thing to implement
00:21:30.570 --> 00:21:35.920
and we, because we're the people who created
the protocol,
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.
00:21:40.410 --> 00:21:44.950
If we had just waited
for somebody else to do it,
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.
00:21:50.970 --> 00:21:55.950
SigAngQ: The second question is …
00:21:55.950 --> 00:21:58.800
that, well, a lot of people are apparently
interested in your t-shirt
00:21:58.800 --> 00:22:01.360
and want to know:
1) what's on it and
00:22:01.360 --> 00:22:03.810
2) where can they get one.
00:22:03.810 --> 00:22:06.400
Shoemaker: Unfortunately,
these aren't for sale … yet.
00:22:06.400 --> 00:22:09.080
But they should be very soon.
00:22:09.080 --> 00:22:11.720
And you may notice that this is
supposed to be the
00:22:11.720 --> 00:22:14.040
contents of a certificate.
00:22:14.040 --> 00:22:17.950
You can try and decode it,
but I don't think you'll get very far.
00:22:17.950 --> 00:22:22.370
StgMgr: Okay, next question
from microphone #1.
00:22:22.370 --> 00:22:25.780
Q: Since I've tried your service and
it works very well,
00:22:25.780 --> 00:22:29.600
I was wondering what keeps you from
going into public.
00:22:29.600 --> 00:22:36.640
I mean, you're now choosing a Beta type
—what is "Beta" in your service, currently?
00:22:36.640 --> 00:22:42.240
Shmk: Well … chuckles our service
hasn't been completely tested.
00:22:42.240 --> 00:22:43.740
slight laughter
00:22:43.740 --> 00:22:47.260
We wouldn't suggest that
a website like Facebook
00:22:47.260 --> 00:22:49.860
that gets millions of requests a day
00:22:49.860 --> 00:22:53.530
would deploy one of our certificates
just yet.
00:22:53.530 --> 00:22:59.520
Yeah … It is …
Currently, we have a hard limit on
00:22:59.520 --> 00:23:02.080
how many certificates we're able to issue
00:23:02.080 --> 00:23:05.460
due to our hardware security modules
00:23:05.460 --> 00:23:09.710
and because of that, we're kind of
trying to take it slowly for now.
00:23:09.710 --> 00:23:11.620
Q: But it works?
00:23:11.620 --> 00:23:14.350
Shmk: Yeah. As far as we now. chuckles.
00:23:14.350 --> 00:23:17.740
StgMgr: Okay, next question
from microphone #2.
00:23:17.740 --> 00:23:21.580
Q: Hi. What are you using for revocation?
Are you using the
00:23:21.580 --> 00:23:25.250
standard-defined revocation lists
or do you have your own solution?
00:23:25.250 --> 00:23:30.560
We're using OCSP, our plan is to
promote OCSP Stapling
00:23:30.560 --> 00:23:37.450
applause
00:23:37.450 --> 00:23:44.000
The CRL model is too broken and
we're kind of trying to push
00:23:44.000 --> 00:23:48.190
both Apache and nginx to get to
act together with OCSP Stapling
00:23:48.190 --> 00:23:52.490
so that it'll actually be a useful
revocation method.
00:23:52.490 --> 00:23:57.170
StgMgr: Okay, next question is for
the Internet, and after that microphone 1 again.
00:23:57.170 --> 00:23:58.440
SigAngQ: Okay, the question is:
00:23:58.440 --> 00:24:02.720
Why is there a limit on
certificate issues per domain?
00:24:02.720 --> 00:24:05.600
Because that is especially annoying for
dynamic DNS users.
00:24:05.600 --> 00:24:07.550
Shmk: Yes. We agree.
00:24:07.550 --> 00:24:12.880
Currently, we use the Public Suffix List
to decide how many certificates
00:24:12.880 --> 00:24:14.740
a domain should get.
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.
00:24:21.610 --> 00:24:25.430
Currently, this is because we have a
hard limit on how many certificates
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
00:24:28.900 --> 00:24:34.160
and take off a
significant percentage of that.
00:24:34.160 --> 00:24:37.570
We're trying to figure out a better
rate-limiting solution.
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
00:24:41.400 --> 00:24:45.490
but we're just not there, yet.
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.
00:24:50.130 --> 00:24:55.160
I have a question regarding the audit that
has to be done by Let's Encrypt,
00:24:55.160 --> 00:25:00.560
because for new kids on the block, usually
there is this kind of certain audits
00:25:00.560 --> 00:25:04.140
where the Mozilla Foundation also was
a part of creating this
00:25:04.140 --> 00:25:07.870
and as I know, there is a
three-month grace period
00:25:07.870 --> 00:25:10.730
of like handing in all the papers
and whatever afterwards
00:25:10.730 --> 00:25:13.960
and if you started in September,
that means, now we're in December,
00:25:13.960 --> 00:25:16.930
so what's the status of this
whole audit thing?
00:25:16.930 --> 00:25:19.860
And, as I know, maybe you can comment
on this as well:
00:25:19.860 --> 00:25:22.370
The cross-validation does not
count for this?!
00:25:22.370 --> 00:25:23.660
So I'd be very interested.
00:25:23.660 --> 00:25:29.270
Shmk: So, we are not yet in the root
programmes of any of the major Browsers.
00:25:29.270 --> 00:25:35.550
We've, I think, just finished our audits.
00:25:35.550 --> 00:25:39.270
Unfortunately, a cross-signature doesn't
require any audits.
00:25:39.270 --> 00:25:42.600
If you can pay a Certificate Authority
enough money, they will cross-sign
00:25:42.600 --> 00:25:45.760
one of your certificates and
allow you to issue.
00:25:45.760 --> 00:25:49.650
It's a very silly system.
00:25:49.650 --> 00:25:57.100
So, yeah, it means that we can currently
issue completely valid, trusted certificates,
00:25:57.100 --> 00:26:03.310
but we are not a member of the organisation
that decides how that works.
00:26:03.310 --> 00:26:06.040
It's strange …
00:26:06.040 --> 00:26:07.910
StgMgr: Next question from
microphone #5?
00:26:07.910 --> 00:26:13.930
Q: Hi. I, first of all, would like to
thank everyone working on this project,
00:26:13.930 --> 00:26:16.880
you guys are awesome!
Shoemaker: Thank you!
00:26:16.880 --> 00:26:23.030
applause
00:26:23.030 --> 00:26:26.700
Q: So, I've got a question regarding nginx.
00:26:26.700 --> 00:26:35.200
Do you know when you might have it
completely supported?
00:26:35.200 --> 00:26:38.910
Shoemaker: I'm not 100% sure.
We're working on …
00:26:38.910 --> 00:26:42.230
—this is kind of our main focus in the
client right now.
00:26:42.230 --> 00:26:48.490
We're increasing how well the
Apache and nginx plug-ins work,
00:26:48.490 --> 00:26:51.150
nginx has kind of got the short end
of the stick currently
00:26:51.150 --> 00:26:56.530
because the majority of people we are
working with are using Apache.
00:26:56.530 --> 00:26:59.820
The next few months, this should
improve significantly.
00:26:59.820 --> 00:27:02.150
Q: Okay, thank you.
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.
00:27:06.620 --> 00:27:08.340
Q: So, I have two:
00:27:08.340 --> 00:27:13.520
So, let's that that tomorrow SHA-2,
suddenly there's a big attack,
00:27:13.520 --> 00:27:17.370
everyone should move to SHA-3,
but unfortunately, as we all know,
00:27:17.370 --> 00:27:19.810
many clients would lag.
00:27:19.810 --> 00:27:21.320
How would you plan to solve this situation?
00:27:21.320 --> 00:27:26.030
Will you push everyone to
migrate instantly to SHA-3?
00:27:26.030 --> 00:27:31.580
Will you cater to those of your users that
would like to remain, you know,
00:27:31.580 --> 00:27:33.440
as compatible as possible?
00:27:33.440 --> 00:27:35.280
And, kind of related to that,
00:27:35.280 --> 00:27:38.440
can you give us
—I'm sure, you've been asked this question a lot
00:27:38.440 --> 00:27:43.410
—why 90 days? Why not a lot less
and maybe even get rid of the entire
00:27:43.410 --> 00:27:48.240
revocation system, why not more?
Can you give us a little glimpse
00:27:48.240 --> 00:27:50.710
on how you want to handle these decisions?
00:27:50.710 --> 00:27:54.510
Shoemaker: So, the first question:
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
00:27:59.400 --> 00:28:02.840
and how they choose to
sunset the algorithm.
00:28:02.840 --> 00:28:07.210
Most likely, we'd continue issuing
until the deadline
00:28:07.210 --> 00:28:11.700
so that people can switch over
as seamlessly as possible.
00:28:11.700 --> 00:28:18.060
But again, that's kind of a
policy question for the governing body.
00:28:18.060 --> 00:28:21.850
And then, the 90 days:
We've been considering allowing
00:28:21.850 --> 00:28:24.460
less than 90 days, so if you'd like to
00:28:24.460 --> 00:28:29.580
issue a 1-day certificate or a
2-day certificate, that should be possible.
00:28:29.580 --> 00:28:31.750
We decided that there should
be a hard limit, though,
00:28:31.750 --> 00:28:35.240
on how long a certificate
we are willing to issue.
00:28:35.240 --> 00:28:38.460
And 90 days is, in part, due to how long
00:28:38.460 --> 00:28:41.400
we would think a certificate
that was compromised
00:28:41.400 --> 00:28:47.210
is safe to be around,
and that should be as small as possible.
00:28:47.210 --> 00:28:49.930
Unfortunately, renewal is still
a hard problem,
00:28:49.930 --> 00:28:54.330
so we can't just say "a week" or "two weeks"
00:28:54.330 --> 00:29:00.860
and ninety days was kind of what we
came down to is the safest.
00:29:00.860 --> 00:29:02.760
Stage Manager: Okay,
last question is for the Internet.
00:29:02.760 --> 00:29:05.190
SigAngQ: Okay, then the
last question will be:
00:29:05.190 --> 00:29:08.060
What is the stack that you
use to generate the certificates?
00:29:08.060 --> 00:29:11.360
Do you have any special optimisation,
like code or hardware to
00:29:11.360 --> 00:29:14.330
keep up with the increased demand?
00:29:14.330 --> 00:29:19.410
Shoemaker: So … We sign our certificates
using hardware security modules and
00:29:19.410 --> 00:29:23.640
there's a library produced by CloudFlare
which they use for their
00:29:23.640 --> 00:29:28.630
universal SSL programme,
which is called CFSSL,
00:29:28.630 --> 00:29:31.500
but there is no special process involved.
00:29:31.500 --> 00:29:37.590
It's just typical X.509 generation.
00:29:37.590 --> 00:29:40.030
Stage Manager: Okay, thank you very much.
00:29:40.030 --> 00:29:45.440
applause
00:29:45.440 --> 00:29:51.400
music
00:29:51.400 --> 00:29:57.000
subtitles created by c3subtitles.de
in the year 2016. Join, and help us!