music still playing,
no audio available for speaker
provide both confidentiality,
integrity, and authenticity
so this means that nobody can see
what you're looking at
nobody can change what you're looking at
and you know that the person
who is sending you this
is a specific person.
They use signed digital certificates.
Each one of these certificates must
be signed by another certificate
and if you want to be trusted,
they have to chain up
to a certificate issued by
a publicly trusted certificate authority.
Who decides, who gets a certificate
and who doesn't?
Why do we have to launch another one?
Well, the Internet is a bad place.
It's extremely easy to modify or to observe
HTTP communication.
There've been a number of attacks
that have demonstrated this over the years
including cookie session re-use and others.
Based on telemetry from the Firefox browser,
we know that only 40% of
initial HTTP requests go over HTTPS.
This is probably because both
getting and installing a certificate
as well as setting up
all the correct TLS parameters
is extremely confusing.
And in part this is because every CA decides,
how it will issue a certificate on its own.
So our solution is
to create another Certificate Authority.
I mean, what can go wrong?
So, because we're the EFF and Mozilla,
we've decided that
it should be completely free.
Cryptography shouldn't be something that
you have to pay for on the Internet.
And unfortunately, right now …
applause
So unfortunately right know there are only
two certificate authorities that are willing
to issue free certificates
except for Let's Encrypt.
And unfortunately, both of them make it
a quite complicated process and
will exclude you from getting a certificate
if you fall into certain groups.
So we decided to make it free
and we also decided to make it open-source.
We did this because it's extremely hard
to tell, what Certificate Authorities
are actually doing
and how they decide
whether or not to issue a certificate.
So we decided
it'd be best to come up
with a standardised protocol
which we've called ACME
so that we can get everybody's input
on what is the most secure way
that we can do this.
Let's Encrypt has already launched
and you can—right now—go and get
a publicly trusted,
free certificate from us.
Unfortunately, this isn't a
cheap thing to do.
So we've been sponsored by a large number
of industry people including
a bunch of hosting providers
Mozilla, Cisco, Akamai,
who is a Content Distribution Network
and the EFF, among others. chuckles
So, the CA and TLS ecosystem is
a pretty strange place.
Before we got there, this is a map of
every single trusted Certificate Authority
that currently exists.
Every single one of these nodes can issue
a certificate that your browser
will completely trust.
And this is ridiculous!
The fact that there are
over 1'600 Certificate Authorities
is very silly.
You can actually see Let's Encrypt is
one of the small magenta nodes
in the bottom left-hand corner.
Unfortunately, we haven't surpassed
some of the other
Certificate Authorities yet,
but that's soon to happen.
There's a group called "The CA Browser Forum"
and these are the people who decide
how the CA and TLS ecosystem works.
Because CAs have a slightly vested interest
in making money over protecting users,
there's often a rift between them
and the browsers
and how rules should be made
that affect publicly trusted certificates
and Certificate Authorities.
Because of this, they decided
to come together
and self-govern themselves in order to have
…
bring order about …
The Browsers generally yield
slightly more power
than the Certificate Authorities.
They require a larger number of …
a larger majority in order to pass a rule.
And this is because, like I said previously,
Certificate Authorities are generally
guided by making money
whereas the browsers are generally
guided by trying to keep users safe.
Unfortunately, Let's Encrypt is
not yet a member of this group
because they have very stringent requirements
for membership, which include
a number of audits we haven't yet completed,
although we're very close to doing so.
Like I said …
The CA/B Forum creates rules
called the "Baseline requirements"
which every Certificate Authority
must comply with
if they wish to be trusted by browsers.
This includes basically documenting
every process that's involved
with issuance of a certificate
and takes a very long time.
So the CA/B also chooses the different
security levels of a certificate
—these are called "validation levels".
There are currently three and
it should be noted that
cryptographically, there is no difference
between each of these "levels of validation".
What they mean is how thoroughly a CA
has validated a person
who is requesting a certificate.
Domain validation is what we're interested
in.
It basically just means that—as a CA—
we can verify that you control
a certain DNS name.
Now there are a few extra steps for
organizational validation.
This means that a CA would have to validate
that you're an owner of a certain business
in a certain country.
And Extended Validation goes even further
and checks other governmental records.
Both OV and EV certificates don't provide
any more security.
All they provide is UI hints in the browser.
So with an EV certificate you'll see
a green box in your URL bar
that says the name of a company.
But cryptographically, these certificates
are exactly the same.
So where does Let's Encrypt fit into this?
Like I said, we're doing
everything completely for free.
This includes issuance, renewal, and revocation
—and any other action you'd do with us
is entirely free.
We're not charging anyone anything.
We're also only going to be issuing
Domain validated certificates.
This is because we don't intend on
hiring a bunch of people to deal with issuance.
Our system is entirely automated.
The only people that we hire are
operations and maintenance people.
We're also only issuing certificates
that are
valid for a maximum of 90 days.
We originally decided on doing this
because in the previous world where certificates
were valid for anywhere from 1–3 years,
it made it really hard to figure out
how to automate renewal of a certificate.
You'd, every once a year,
go to your Certificate Authority
and ask for a new certificate
and then spend the next few hours
trying to figure out
what you had to tell them
and how you'd install it in your server.
By limiting the validity period to 90 days,
we're ensuring that people are forced
to renew often.
And this also comes with a good side-effect
that if their certificate becomes compromised,
it is only compromised for
a maximum of 90 days.
Which makes it slightly safer.
So we're also issuing multiple domain certificates
instead of wildcard certificates.
These use Subject Alternative Names (SAN)
with multiple DNS names inside of a certificate
meaning that a single certificate can be used
to validate up to a hundred domains.
In order to make our certificates actually
publicly trusted
we've applied to the
Mozilla, Apple, Google, and Microsoft root
programmes
but we've also had one of our Intermediate
Certificates
cross-signed by IdenTrust,
which is another Certificate Authority.
This means that every certificate we issue
is already trusted.
So we don't have to worry about old devices
not trusting our certificates.
So, we started a closed beta
in about early September
and this went from …
all the way up to December, 3rd
and during that period we only issued
about 20'000 certificates.
You can see that the first period in september
was just staff issuing certificates to themselves.
And I think we only issued around 100 or 200 certificates.
And then we opened a Closed Beta
and we issued around 20'000 more
and then on December, 3rd, we opened up to
everyone.
You didn't have to apply to join and
we'd issue a certificate as long
as you could prove
that you controlled a domain.
In the first day, we doubled the number of
certificates we issued.
And in a week, I think, we quadrupled it.
I mean, in the first 12 hours we were issuing
a certificate almost every two seconds.
And since then, we've issued
over 200'000 certificates across 440'000 domain
names.
This is … we're still in beta though.
That should be noted.
We don't expect to be …
We expect to do a Google-style Beta
—it will probably take a while.
Using Certificate Transparency Logs
which are a collection that Google has created
of almost all currently valid certificates
we can see that Let's Encrypt is already
the fifth largest Certificate Authority
and we're already larger than both WoSign and StartSSL
the two currently free
public Certificate Authorities.
applause
So our goal is to …
it isn't to be the largest Certificate Authority
but it is to raise the total percentage
of connections on the internet
that go over HTTPS.
applause
So this is a very hard thing to measure.
Unless you're sitting on a backbone,
it's almost impossible to tell what percentage
is going over HTTP
and what percentage is going over HTTPS.
Luckily, Firefox can provide us with
certain TLS telemetry about what
Certificate Authorities
issue certificates that they're seeing
and we can also use Certificate Transparency
to try and figure out how people are
actually using our certificates.
We have a bunch of stats …
There are currently over
a 120'000 individual registrations.
So, we count … a single registration
can issue multiple certificates
and we see that there are currently only
about two certificates per registration
with two DNS names per certificate.
Now this is most likely because people
are just testing the servers
so they will go out and try and find
a certificate for their blog or personal website
and not very many people are using
very large certificates with multiple
Subject Alternate Names yet.
We see that around 33% of the names
that we issued for
have multiple certificates
with that name in them.
This is actually a very common thing
we were expecting to see.
Because we issue a very large number
of certificates to Content Distribution Networks.
And these Networks will have tons of endpoints
that will work for a whole bunch
of different websites.
So they will, you know,
maybe have 15 certificates that'll have
a set of 50 Domain Names
spread out across them.
We also see that 20% of certificates have
the exact same duplicate name sets.
This has probably more to do with
people trying to get used
to our official client
and us having to fix a few bugs in it
—that meant that people would reissue
the same certificate over and over
without noticing that
they already had a valid one.
But we're seeing that slowly decrease.
We've also seen that
80% of the domain names that we've issued for
have never had a certificate before,
according to the Certificate Transparency logs.
So we're actually providing people who
previously wouldn't have got a TLS certificate
with certificates.
applause
And we've had … about 1% of our total issuance
have been revoked so far,
which is a good sign that our
system is actually working.
So, in order to see how people are
actually deploying our certificates,
we've written a very small TLS scanner
that will go through the DNS names
of certificates we've issued
and try to see if they actually use them.
We see that about 75% of the people
that we've issued a certificate for
have actually deployed it on
the domain name we've issued it for.
And only 8% of those names have
a broken TLS configuration.
This means, if you try to connect to them,
your Browser would reject the certificate.
This can be because they're using
a self-signed certificate or
because they aren't presenting the right
chain of certificates, among other things.
And 3% of the names we've issued for
don't serve HTTPS at all.
Now this actually is probably quite small
because we only scan for HTTPS.
People could be using these certificates
for mail servers or IRC servers or XMPP servers
and we wouldn't know.
And we can see that 45% of the certificates
are used by every single
DNS name that they contain.
Which is actually a quite good number.
So, looking at the Firefox telemetry,
we see that only 0.1% of
currently successful TLS handshakes
use a Let's Encrypt certificate.
Now this sounds very low, but
it actually makes a lot of sense.
We don't plan to …
or … our goal is not to make
the largest websites on the Internet
use our certificates.
If that happened, the percentage of
successful TLS handshakes
that we were involved in would be much higher.
But our goal is to issue certificates
to the long tail of people.
People who may not have
hundreds of thousands of visitors
to their website
but should still be able to use
cryptographic protocols.
So, we have an official client
which is called "Let's Encrypt"
but … which is currently used
by about 65% of our users.
This is a very complicated client
and it will do a lot of things for you.
It will manage renewal,
it will manage installing
into your either Apache or nginx server
among other things.
But there've also been,
since we entered public beta,
around 30 unique 3rd party clients
that have popped up.
For pretty much any scenario you
might want to use a certificate for,
including a web server called "Caddy"
that has a built-in ACME client,
which means that as soon as …
you can turn on your web server and if you
don't have an SSL certificate,
it will automatically go out and
fetch one for you.
Another one is a web based client so you
can go in your browser and
generate a certificate without installing
anything on your system at all.
So our main goal is actually to get
Hosting providers and
Content Distribution Networks
to use our certificates.
While most people here might want to
just go out and install a certificate
on the server they run themselves,
the majority of people who are running
smaller websites are using
a hosting provider who will
run all of this for them.
And, generally, these people will
charge for certificates
and our goal is to try and get them to
a) make it free, and
b) make it painless for the users.
So, so far we have Akamai, KeyCDN, DreamHost,
Cyon and Pressjitsu
—these are both hosting providers and
Content Distribution networks
who have already integrated with Let's Encrypt
and will allow you to get a certificate
completely for free.
And we assume that, in the long term,
this will make up the majority of our usage.
Most likely, people issuing
hundreds of thousands of certificates
won't be individuals,
they'll be hosting providers.
So our …
We still have a lot of work to do
on our Certificate Authority.
Currently, you can only do validation
based on either HTTP or HTTPS.
This has made it quite complicated
for people who have very complex set-ups,
that are using load-balancers or other systems
to validate their websites.
One of our solutions for this is the
DNS challenge which will allow anyone
to just add a DNS record and automatically
validate the domain name they want.
We also want to implement a
"Proof of Possession" challenge.
This means that if you asked for
a certificate for a Domain Name
that we know is already using
an SSL certificate,
we'll ask you to prove that you
control the private key of that certificate.
And this is a extra way to verify
that a single person won't control
or can't mis-issue a certificate for
a domain they can't control.
We also want to add Multi-Path Validation.
Currently, we validate from a single point.
And this means that we are susceptible to
network-local attacks.
—but this will change very soon.
Alright, thank you.
applause
Angel: Thank you.
The first few questions are for the Internet.
Signal Angel: Okay, the first question
from the Internet is:
Question: Given the critics on the
official client, wouldn't it have been
better to split the service and the client?
Shoemaker: I think …
The client is a very hard thing to implement
and we, because we're the people who created
the protocol,
I think it makes sense for us to also
work on trying to create the client for it.
If we had just waited
for somebody else to do it,
I don't think we would've been able
to get as far as we have so far.
SigAngQ: The second question is …
that, well, a lot of people are apparently
interested in your t-shirt
and want to know:
1) what's on it and
2) where can they get one.
Shoemaker: Unfortunately,
these aren't for sale … yet.
But they should be very soon.
And you may notice that this is
supposed to be the
contents of a certificate.
You can try and decode it,
but I don't think you'll get very far.
StgMgr: Okay, next question
from microphone #1.
Q: Since I've tried your service and
it works very well,
I was wondering what keeps you from
going into public.
I mean, you're now choosing a Beta type
—what is "Beta" in your service, currently?
Shmk: Well … chuckles our service
hasn't been completely tested.
slight laughter
We wouldn't suggest that
a website like Facebook
that gets millions of requests a day
would deploy one of our certificates
just yet.
Yeah … It is …
Currently, we have a hard limit on
how many certificates we're able to issue
due to our hardware security modules
and because of that, we're kind of
trying to take it slowly for now.
Q: But it works?
Shmk: Yeah. As far as we now. chuckles.
StgMgr: Okay, next question
from microphone #2.
Q: Hi. What are you using for revocation?
Are you using the
standard-defined revocation lists
or do you have your own solution?
We're using OCSP, our plan is to
promote OCSP Stapling
applause
The CRL model is too broken and
we're kind of trying to push
both Apache and nginx to get to
act together with OCSP Stapling
so that it'll actually be a useful
revocation method.
StgMgr: Okay, next question is for
the Internet, and after that microphone 1 again.
SigAngQ: Okay, the question is:
Why is there a limit on
certificate issues per domain?
Because that is especially annoying for
dynamic DNS users.
Shmk: Yes. We agree.
Currently, we use the Public Suffix List
to decide how many certificates
a domain should get.
So if you have, say, roan.com, you'll only
be able to get 5 certificates for that domain.
Currently, this is because we have a
hard limit on how many certificates
we are able to issue, so we don't want
a single user to be able to go out
and take off a
significant percentage of that.
We're trying to figure out a better
rate-limiting solution.
You should notice in the future that you'll
be able to issue a lot more certificates
but we're just not there, yet.
Q: Hi. First, thanks for the talk and for
the great aim I think we all support.
I have a question regarding the audit that
has to be done by Let's Encrypt,
because for new kids on the block, usually
there is this kind of certain audits
where the Mozilla Foundation also was
a part of creating this
and as I know, there is a
three-month grace period
of like handing in all the papers
and whatever afterwards
and if you started in September,
that means, now we're in December,
so what's the status of this
whole audit thing?
And, as I know, maybe you can comment
on this as well:
The cross-validation does not
count for this?!
So I'd be very interested.
Shmk: So, we are not yet in the root
programmes of any of the major Browsers.
We've, I think, just finished our audits.
Unfortunately, a cross-signature doesn't
require any audits.
If you can pay a Certificate Authority
enough money, they will cross-sign
one of your certificates and
allow you to issue.
It's a very silly system.
So, yeah, it means that we can currently
issue completely valid, trusted certificates,
but we are not a member of the organisation
that decides how that works.
It's strange …
StgMgr: Next question from
microphone #5?
Q: Hi. I, first of all, would like to
thank everyone working on this project,
you guys are awesome!
Shoemaker: Thank you!
applause
Q: So, I've got a question regarding nginx.
Do you know when you might have it
completely supported?
Shoemaker: I'm not 100% sure.
We're working on …
—this is kind of our main focus in the
client right now.
We're increasing how well the
Apache and nginx plug-ins work,
nginx has kind of got the short end
of the stick currently
because the majority of people we are
working with are using Apache.
The next few months, this should
improve significantly.
Q: Okay, thank you.
StgMgr: Next question is from microphone #4
and then we'll be go back to the Internet.
Q: So, I have two:
So, let's that that tomorrow SHA-2,
suddenly there's a big attack,
everyone should move to SHA-3,
but unfortunately, as we all know,
many clients would lag.
How would you plan to solve this situation?
Will you push everyone to
migrate instantly to SHA-3?
Will you cater to those of your users that
would like to remain, you know,
as compatible as possible?
And, kind of related to that,
can you give us
—I'm sure, you've been asked this question a lot
—why 90 days? Why not a lot less
and maybe even get rid of the entire
revocation system, why not more?
Can you give us a little glimpse
on how you want to handle these decisions?
Shoemaker: So, the first question:
That decision isn't 100% up to us.
It'd be more up to the CA/B forum
and how they choose to
sunset the algorithm.
Most likely, we'd continue issuing
until the deadline
so that people can switch over
as seamlessly as possible.
But again, that's kind of a
policy question for the governing body.
And then, the 90 days:
We've been considering allowing
less than 90 days, so if you'd like to
issue a 1-day certificate or a
2-day certificate, that should be possible.
We decided that there should
be a hard limit, though,
on how long a certificate
we are willing to issue.
And 90 days is, in part, due to how long
we would think a certificate
that was compromised
is safe to be around,
and that should be as small as possible.
Unfortunately, renewal is still
a hard problem,
so we can't just say "a week" or "two weeks"
and ninety days was kind of what we
came down to is the safest.
Stage Manager: Okay,
last question is for the Internet.
SigAngQ: Okay, then the
last question will be:
What is the stack that you
use to generate the certificates?
Do you have any special optimisation,
like code or hardware to
keep up with the increased demand?
Shoemaker: So … We sign our certificates
using hardware security modules and
there's a library produced by CloudFlare
which they use for their
universal SSL programme,
which is called CFSSL,
but there is no special process involved.
It's just typical X.509 generation.
Stage Manager: Okay, thank you very much.
applause
music
subtitles created by c3subtitles.de
in the year 2016. Join, and help us!