Return to Video

Roland Bracewell Shoemaker: Let's Encrypt -- What launching a free CA looks like

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

more » « less
Video Language:
English
Duration:
29:57

English subtitles

Revisions Compare revisions