*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!