<i>music still playing,
no audio available for speaker</i>

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 …

<i>applause</i>

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. <i>chuckles</i>

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.

<i>applause</i>

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.

<i>applause</i>

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.

<i>applause</i>

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.

<i>applause</i>

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.

<i>slight laughter</i>

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

<i>applause</i>

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!

<i>applause</i>

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.

<i>applause</i>

<i>music</i>

subtitles created by c3subtitles.de
in the year 2016. Join, and help us!