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