[00:00.000 --> 00:01.920]  So, my name is Jacob Hoffman-Andrews.
[00:02.060 --> 00:05.500]  I'm a staff technologist at the Electronic Frontier Foundation.
[00:05.900 --> 00:12.120]  If you're at the Ask the EFF panel, Parker was saying, you know, we like to solve problems by suing.
[00:12.300 --> 00:15.580]  We also like to solve problems by writing code and writing blog posts.
[00:15.800 --> 00:17.880]  And that's what I do as a technologist.
[00:18.200 --> 00:26.920]  So, specifically, my biggest project these days is Let's Encrypt, which is part of EFF's ongoing project to encrypt the web.
[00:28.760 --> 00:33.300]  Pardon me, it's going to be a little awkward because I couldn't get my speaker notes on the screen and the slides up there.
[00:33.500 --> 00:35.600]  So, I'll check back to see what page I'm on occasionally.
[00:36.380 --> 00:42.040]  So, to start off with, I'd like to explain a little bit about the project to encrypt the web and why we care so much.
[00:43.940 --> 00:47.340]  So, you're probably familiar with HTTP versus HTTPS.
[00:48.100 --> 00:51.180]  HTTPS is the more secure version of HTTP.
[00:51.920 --> 00:56.200]  It protects your data in transit and ensures that you're talking to the website you think you're talking to.
[00:56.200 --> 01:04.320]  So, the first and most obvious reason why we care about encrypting the web is our friends at the NSA who are hoovering up everything.
[01:04.560 --> 01:07.380]  And especially, they love plain text, which is HTTP.
[01:08.360 --> 01:15.140]  It's plain text and it's easy to look at, interrogate, find selectors in, find data in.
[01:16.540 --> 01:24.700]  We also know that they actually care about SSL, which is the protocol underlying HTTPS because they try to find ways around it.
[01:25.180 --> 01:31.540]  You know, this famous slide from the Snowden leaks shows a little smiley face with SSL added and removed here.
[01:31.540 --> 01:38.940]  So, when they find encryption, when they find SSL, HTTPS, they try to bypass it by going to the inter-data center links.
[01:41.640 --> 01:47.260]  But we've actually started to see a bunch more, you know, kind of commercial level attacks recently.
[01:47.580 --> 01:57.400]  So, for instance, about a year and a half ago, EFF kind of sounded the alarm about Verizon's new tracking program using this UIDH header.
[01:57.400 --> 02:00.360]  And the way they were doing this tracking was actually really novel.
[02:00.600 --> 02:07.500]  They would take HTTP traffic passing through their network, they would modify it, and they would inject a unique header for every user.
[02:07.720 --> 02:16.000]  So, if you were a website that had visitors from Verizon, every one of those visitors would have a unique cookie tag, tagging them.
[02:16.500 --> 02:22.700]  That doesn't respond to their browser's privacy controls or deleting cookies or if you have privacy badger installed, that wouldn't help.
[02:22.700 --> 02:28.860]  The only thing that helps with this type of injection and traffic modification is HTTPS.
[02:30.020 --> 02:41.920]  We've also seen Comcast using HTTP vulnerabilities, like the fact that HTTP is so trivially man-in-the-middle-able, to insert ads into their webpages.
[02:42.080 --> 02:49.440]  And the funny thing is they're doing all this just to insert ads about themselves, telling you, you are on an authentic Comcast Wi-Fi hotspot.
[02:49.700 --> 02:53.700]  We're man-in-the-middle-ing your traffic, but you can be sure you're safe, you're on a Comcast hotspot.
[02:55.940 --> 03:00.280]  The other really important thing with HTTPS is HTTP2.
[03:02.040 --> 03:10.740]  HTTP2 was standardized, I believe, last year, but has already seen a lot of deployment, and it's got a lot of performance improvements over HTTP.
[03:11.860 --> 03:30.180]  But what the authors of the spec found is that in practical deployment, these middle boxes, you know, caching layers, caching proxies, and, of course, blue coat boxes, munch the HTTP so badly that if you tried to change any protocol aspect of HTTP without adding encryption,
[03:30.920 --> 03:33.600]  you would have a bad time.
[03:33.800 --> 03:36.880]  You know, some middle box somewhere would munch it and would break the protocol.
[03:36.880 --> 03:42.860]  So, in practice, if you want HTTP2, you need HTTPS to support it.
[03:44.820 --> 03:49.700]  This was one of the really fascinating attacks of the last year or so, is the Great Cannon.
[03:50.020 --> 03:52.820]  This was due to some great research by Citizen Lab.
[03:53.180 --> 04:05.520]  Basically, what happened here was GitHub was being used to host some content for greatfire.org, and China didn't like that content, so they wanted GitHub to take it down.
[04:05.520 --> 04:06.880]  GitHub wasn't taking it down.
[04:07.480 --> 04:08.980]  So, they started DDoSing GitHub.
[04:09.660 --> 04:14.520]  And this was, you know, one of the biggest DDoSs seen on the Internet, I think.
[04:14.680 --> 04:17.820]  I'm not sure if the full numbers have been released, but it's...
[04:17.820 --> 04:21.800]  It was a really remarkably large DDoS and remarkably hard to counter.
[04:22.140 --> 04:24.280]  And the reason was this unique way it worked.
[04:25.820 --> 04:30.880]  So, China has kind of a man-in-the-middle position on a huge amount of Internet traffic.
[04:31.020 --> 04:34.300]  Not just users inside China, but users outside China.
[04:35.300 --> 04:37.960]  So, Baidu is, of course, a huge Internet company.
[04:38.540 --> 04:42.220]  And they offer a lot of services, including Baidu Analytics.
[04:42.840 --> 04:46.620]  Baidu Analytics is like Google Analytics, but by Baidu.
[04:46.620 --> 04:50.840]  And so, that's included by millions of websites around the world.
[04:51.080 --> 04:52.460]  Not even just Chinese websites.
[04:52.980 --> 04:56.660]  And visitors from all over the world would visit those websites.
[04:57.300 --> 05:01.580]  And normally, you know, their browser makes a request for BaiduAnalytics.js.
[05:01.720 --> 05:04.640]  That request goes to Baidu's servers in China.
[05:04.900 --> 05:06.580]  Comes back with regular JS.
[05:07.340 --> 05:19.940]  During the attack, when China turned on this tool that Citizen Lab deemed the great canon, those bytes for the Baidu Analytics JavaScript would instead come back with an attack payload.
[05:20.140 --> 05:23.880]  Which would basically say, fetch this URL on GitHub over and over and over again.
[05:24.880 --> 05:33.060]  And at the scale, the huge number of people that load web pages that have Baidu Analytics, that added up to a tremendous amount of traffic.
[05:33.360 --> 05:36.880]  And it was very hard to block and filter because it didn't come from any one place.
[05:37.200 --> 05:40.380]  It was essentially an instant botnet made out of browsers.
[05:40.920 --> 05:46.700]  And the thing that made this possible was HTTP rather than HTTPS.
[05:47.240 --> 05:52.680]  So, you know, if we had an all HTTPS Internet, this type of attack would no longer be possible.
[05:54.980 --> 05:57.520]  I mentioned in the slide title, PKI.
[05:57.920 --> 05:59.420]  I realize this is a jargony acronym.
[06:01.020 --> 06:05.320]  And feel free to, you know, raise your hand if I say a jargony acronym and I forget to define it.
[06:05.320 --> 06:08.000]  PKI is public key infrastructure.
[06:08.420 --> 06:10.240]  It's how you know which key goes where.
[06:10.880 --> 06:15.380]  So, for instance, with PGP, you manually verify each other's keys.
[06:16.060 --> 06:24.020]  On the web, we have some help from the web PKI, which is composed of CAs or certificate authorities.
[06:25.340 --> 06:30.440]  So, there's a problem with CAs, which is there's too many of them and they're too big.
[06:30.740 --> 06:33.780]  They're too decentralized and they're too centralized.
[06:34.260 --> 06:42.180]  So, this is a graph from the Berkeley ICSI's scan and evaluation of the CA ecosystem.
[06:42.540 --> 06:46.020]  There's literally hundreds of CAs or certificate authorities.
[06:46.020 --> 06:51.560]  And each one of them is trusted to vouch for any website on the Internet.
[06:51.980 --> 07:00.020]  So, you know, if you run a website and you use HTTPS, there's, you know, hundreds of entities who could sign a valid certificate for you.
[07:00.500 --> 07:07.020]  Now, they're supposed to follow correct procedures to ensure that they only sign certificates for the right entities.
[07:07.480 --> 07:08.980]  But those can fail.
[07:09.720 --> 07:13.120]  There have been a number of examples of CA failures over the last few years.
[07:13.700 --> 07:26.220]  And that brings us to the other problem, which is if you see some of the largest circles here, RapidSSL, GeoTrust, I don't see Symantec on there, but they're definitely somewhere in that graph and they're big.
[07:27.580 --> 07:34.460]  If one of those biggest CAs fails and they mis-issue a cert, you might say, well, forget them.
[07:34.460 --> 07:35.980]  I don't want to trust them anymore.
[07:36.460 --> 07:42.720]  But you can't because, say, for Symantec, some 30% of the websites on the Internet are signed by their certs.
[07:42.720 --> 07:46.440]  So if you turn them off, you know, you would break the Internet for yourself.
[07:47.040 --> 07:52.740]  More importantly, the browsers can't turn them off either because they would break a huge portion of the Internet for their users.
[07:53.520 --> 07:55.920]  And this is sort of an open, unsolved problem.
[07:58.980 --> 08:03.120]  There are a few alternatives people have worked on, especially in the hacker community.
[08:04.840 --> 08:09.520]  DANE, which is DNSSEC something named entities.
[08:10.000 --> 08:10.220]  I forget.
[08:10.400 --> 08:12.640]  DNSSEC authentication for named entities, I believe.
[08:13.860 --> 08:22.680]  This is a protocol based on DNSSEC that allows DNSSEC to deliver the trusted keys for a given website through the DNS system.
[08:22.680 --> 08:26.380]  And it's hierarchically rooted in the trust you have in the root zone.
[08:26.380 --> 08:31.920]  But that's not actually seen any deployment in browsers yet today, so it's not yet a practical alternative.
[08:33.420 --> 08:50.880]  Sovereign keys was a proposal by my colleague at EFF, Peter Eckersley, along with some others, to put identities in an immutable public log that could be used not only for vouching for identities, but also for censorship resistance.
[08:50.880 --> 08:54.660]  But again, you know, we're not seeing practical deployment of this in browsers.
[08:56.180 --> 09:00.200]  Convergence was a proposal by Moxie Marlin Spike to use a concept of notaries.
[09:00.220 --> 09:07.720]  So you would have multiple vantage points across the Internet that could reach out to the site you're trying to visit, tell you what key it should have.
[09:08.760 --> 09:10.400]  Not available in browsers today.
[09:11.820 --> 09:20.700]  TAC was a proposal to use the certificate authority ecosystem to bootstrap trust in your site.
[09:20.700 --> 09:23.260]  And then from there, you would essentially use self-signing.
[09:23.460 --> 09:24.900]  You kind of take care of your own key.
[09:25.200 --> 09:28.440]  This is similar to what is available now, which is called key pinning.
[09:28.600 --> 09:35.180]  So this is a bit of a way to say, I want to trust the CA system minimally, but not available in browsers.
[09:36.260 --> 09:42.840]  And DNS chain is a blockchain Bitcoin based approach to naming and delivering keys.
[09:42.840 --> 09:45.400]  And again, it hasn't seen any practical deployment.
[09:45.880 --> 09:49.320]  Or I should say, it hasn't seen large scale browser based deployment.
[09:51.100 --> 09:54.380]  So what are we left with if we want HTTPS for the whole Internet?
[09:54.940 --> 09:56.200]  We're going to make another CA.
[09:57.860 --> 10:01.900]  You know, they say you don't go to war with the army you want.
[10:02.160 --> 10:03.560]  You go with the one you have.
[10:03.560 --> 10:08.700]  You don't encrypt the Internet with the PKI you want.
[10:08.860 --> 10:10.640]  You encrypt the Internet with the PKI you have.
[10:12.820 --> 10:14.620]  So this was a big project.
[10:15.360 --> 10:24.920]  EFF came together with Mozilla and the University of Michigan and sponsors Cisco and Akamai to create the Internet security research group.
[10:26.380 --> 10:35.040]  So ISRG is an independent nonprofit from each of these entities and runs Let's Encrypt and owns its roots and keys.
[10:35.900 --> 10:37.980]  And ISRG has a small staff.
[10:38.120 --> 10:45.260]  It also gets through volunteer labor from EFF employees and Mozilla employees like myself and some of my colleagues.
[10:47.360 --> 10:51.820]  So the big question when you want to start a CA is how do you get trusted?
[10:51.820 --> 10:55.600]  How do you become one of those hundreds of CA's I showed you in the previous slide?
[10:56.080 --> 11:05.000]  So the decision of which CA's are trusted is to some extent up to the browsers and to some extent up to the operating systems.
[11:05.380 --> 11:08.940]  It's a question of what's called trust stores.
[11:09.280 --> 11:16.920]  So a trust store is a list of CA's where you say these are the CA's that are allowed to sign in my world.
[11:17.520 --> 11:19.340]  So you have essentially three options.
[11:20.420 --> 11:23.900]  You can buy a root from somebody else who's already in one of the trust stores.
[11:24.160 --> 11:25.960]  And this happens all the time in industry.
[11:26.700 --> 11:29.460]  And, you know, there's pluses and minuses to it.
[11:29.560 --> 11:34.100]  And you could say trust isn't necessarily transitive across purchases.
[11:34.540 --> 11:38.600]  Although there is an auditing layer to prevent, you know, terrible malfeasance in theory.
[11:39.980 --> 11:43.140]  Another alternative is you can pursue something called a cross signature.
[11:44.020 --> 11:50.480]  Which is where another CA in that graph of CA's signs your route or signs your intermediate certificate.
[11:51.080 --> 11:57.440]  And essentially delegates that power and says, you know, this entity, ISRG, is trusted to issue certs.
[11:58.880 --> 12:01.160]  And thirdly, you can actually just start from scratch.
[12:01.440 --> 12:02.860]  You can roll your own key.
[12:03.160 --> 12:04.460]  Make sure you store it in an HSM.
[12:05.080 --> 12:08.600]  Apply to the browser and OS root programs.
[12:09.300 --> 12:13.640]  And six months to a year later, the very newest browsers will trust your cert.
[12:14.620 --> 12:21.420]  But we wanted to be trusted by a really wide variety of browsers and other programs right out the door.
[12:21.420 --> 12:23.660]  So that people can start encrypting right away.
[12:25.100 --> 12:27.400]  So, we wind up going with this approach.
[12:27.640 --> 12:31.360]  We're cross signed by another CA called Identrust, who's also one of our sponsors.
[12:34.160 --> 12:37.520]  So, you know, I said, well, we've got this kind of broken ecosystem.
[12:37.580 --> 12:42.480]  And we're participating in it anyhow because we think the win is bigger than the loss.
[12:42.780 --> 12:46.260]  But we are doing some things within that ecosystem to try and improve it.
[12:46.560 --> 12:50.200]  The first is CAA, Certificate Authority Authorization.
[12:50.960 --> 12:54.000]  This is a DNS specification.
[12:54.300 --> 13:05.520]  So, it's a new-ish DNS record type in the last few years where you can request a CAA, Certificate Authority Authorization record, for a given domain.
[13:05.680 --> 13:10.300]  And that says, this is the list of CAs that I want to allow to issue for my domain.
[13:10.560 --> 13:13.880]  You know, so maybe you don't trust, you know, some CAA.
[13:14.040 --> 13:16.380]  You can say, okay, you know, only these three.
[13:16.380 --> 13:17.900]  Or say, only let's encrypt.
[13:18.160 --> 13:19.320]  Or, none at all.
[13:19.360 --> 13:20.900]  I don't want any TLS certificates.
[13:21.240 --> 13:21.540]  Go away.
[13:23.260 --> 13:27.040]  Let's encrypt is actually the first to implement the CAA spec for issuance.
[13:27.240 --> 13:27.520]  Oh, no.
[13:27.520 --> 13:27.960]  Okay.
[13:28.180 --> 13:28.300]  Correct.
[13:28.460 --> 13:29.000]  We have a correction.
[13:29.360 --> 13:31.380]  All right.
[13:32.000 --> 13:32.560]  Sorry about that.
[13:32.680 --> 13:32.920]  Yes.
[13:33.200 --> 13:34.340]  Is that Rob in front?
[13:35.660 --> 13:36.100]  Yeah.
[13:36.260 --> 13:36.380]  Hey.
[13:36.780 --> 13:39.760]  So we have Rob Stradling from Komodo in front and he corrected my...
[13:39.760 --> 13:39.840]  Can I fail?
[13:40.180 --> 13:40.520]  Oh, sorry.
[13:40.640 --> 13:40.740]  Fail.
[13:42.120 --> 13:44.080]  So Komodo actually invented CAA.
[13:44.500 --> 13:48.260]  And is Komodo enforcing CAA for issuances?
[13:48.580 --> 13:49.720]  Oh, that's operations.
[13:50.020 --> 13:50.660]  Okay.
[13:50.820 --> 13:51.320]  That's operations.
[13:51.820 --> 13:57.720]  So anyways, you know, we consider CAA implementation one of our important security fixes.
[13:59.180 --> 14:01.420]  We also implement certificate transparency.
[14:02.340 --> 14:15.100]  Certificate transparency is an attempt to improve the trust of the CAA ecosystem by ensuring that every certificate issued is logged publicly and can be analyzed by the public and by browsers.
[14:15.540 --> 14:21.580]  And so when there's a mistake, when there's a mis-issuance, we can catch it right away and take the appropriate measures.
[14:21.580 --> 14:28.000]  So let's encrypt from day one has been logging voluntarily every certificate we issue to CT.
[14:29.480 --> 14:39.420]  And we plan to take further steps to ensure that the CT proofs are included with either OCSP responses or in the certificates we issue.
[14:39.760 --> 14:50.640]  So sometime in the future, you know, the goal of the CT project is to enforce that every certificate trusted by a browser is present in a CT log.
[14:53.420 --> 14:54.600]  Serial number entropy.
[14:56.600 --> 15:04.700]  So the CAA ecosystem recently went through a transition from the SHA-1 hash to the SHA-2 hash.
[15:04.940 --> 15:08.600]  And the reason for that is SHA-1 is no longer considered strong enough.
[15:08.840 --> 15:11.280]  It's too easy to produce collisions on SHA-1.
[15:11.700 --> 15:18.760]  And if you can produce a collision in the hash used by a certificate, you get to mint your own SHA-1.
[15:18.760 --> 15:21.200]  We saw this before with the MD5 hash.
[15:21.420 --> 15:24.200]  We migrated from MD5 to SHA-1 many years ago.
[15:24.940 --> 15:34.500]  And while MD5 was on its last legs, a group of researchers actually produced a live collision and minted their own fake CAA certs using this collision.
[15:34.500 --> 15:49.260]  So as a response to that, the CA sort of self-regulating organization called the CA Browser Forum added language saying serial numbers should include 20 bits of entropy, which was a great step.
[15:49.280 --> 15:51.280]  And I think most CAs in practice do that now.
[15:51.480 --> 15:56.960]  But there's still this bug in that this critical security feature, entropy in the serial number, isn't required.
[15:56.960 --> 16:03.460]  So one of the nice things about being a CA, we get to participate in the CA Browser Forum.
[16:03.680 --> 16:09.300]  So we recently helped push through a requirement for serial number entropy at a 64-bit level.
[16:09.440 --> 16:11.580]  So now that's a must rather than a should.
[16:13.980 --> 16:20.540]  One of the long-standing problems with certificates in general is, you know, they say revocation doesn't work.
[16:21.200 --> 16:31.100]  Revocation doesn't work because the method we use to deliver revocation information, OCSP, is, you know, not inherently reliable.
[16:31.980 --> 16:36.280]  It fails some percentage of the time that's, you know, unacceptable to end users.
[16:36.560 --> 16:43.860]  So, you know, if you're visiting a website and the website is up but the OCSP responder is down, you know, you generally don't want that to stop you from visiting the website.
[16:44.720 --> 16:56.700]  So what that means in practice is that if a browser fails to get revocation information via OCSP, if it gets a timeout or it's blocked in some way, it'll fail open.
[16:56.880 --> 16:58.560]  It'll say, you know what, it's probably not revoked.
[16:58.640 --> 16:59.660]  I'm not going to worry about it.
[17:00.580 --> 17:04.460]  But you can imagine if you revoked your cert because somebody stole your key,
[17:08.220 --> 17:16.920]  that the attacker using that stolen key with a network position on their victim would just block the OCSP response.
[17:17.640 --> 17:23.120]  So, you know, OCSP in practice as deployed by browsers is this tool that sort of fails when you need it most.
[17:23.580 --> 17:28.620]  So there's a recently standardized spec called OCSP must staple.
[17:28.620 --> 17:30.560]  That's actually called TLS feature.
[17:30.960 --> 17:33.340]  But before that, it was most commonly known as must staple.
[17:33.680 --> 17:45.040]  Which basically says, you know, when I make a handshake with a web server, if it has this extension in the certificate, I should always expect to see a stapled response attached.
[17:45.460 --> 17:59.880]  And if I don't, when I say stapled, that means that the server has gone to the OCSP server, OCSP responder itself, fetched a signed response that's up to date and has a timestamp, and attached that to the handshake.
[18:00.420 --> 18:03.000]  So this actually makes revocation work if you turn it on.
[18:03.580 --> 18:06.120]  And Let's Encrypt deployed it pretty early on.
[18:06.280 --> 18:08.860]  I think, again, Komodo actually beat us to the punch on that.
[18:10.500 --> 18:13.520]  But this is, you know, we're trying to make revocation actually work on the web.
[18:15.640 --> 18:16.360]  So takedowns.
[18:16.480 --> 18:22.620]  You know, one of the things that doesn't get talked about a lot is the power of your CA to take down your website through revocation.
[18:22.620 --> 18:29.300]  You know, I said, you know, OCSP is a tool that fails just when you need it most, but it also works when you don't want it to work.
[18:29.480 --> 18:36.900]  You know, if your CA decides to unilaterally to revoke your certificate, you know, your visitors are going to see a warning that your site is unsafe.
[18:37.800 --> 18:51.680]  Now, you know, I haven't seen this actually happen in practice, but because not all certs are logged to CT yet, it's actually not possible to do the comprehensive research necessary to find out how often revocations are happening.
[18:52.140 --> 19:02.700]  So, when we developed Let's Encrypt's policies, we tried to take a very content-neutral approach and say, you know, we don't want to revoke certificates based on the content of the site.
[19:02.820 --> 19:09.060]  We revoke them if the key is compromised or, you know, a certain number of other requirements that we have.
[19:09.420 --> 19:24.220]  Now, we've had to make some compromises there based on the requirements placed on us by root programs in the cab forum, so we do some amount of phishing check at issuance time where you talk to the Google Safe Browsing API.
[19:24.540 --> 19:34.880]  But we try to keep those as minimal as possible to avoid the temptation to do content-based takedowns of sites, which I think is going to become a bigger issue as HTTPS deploys further.
[19:36.640 --> 19:49.140]  And we have some community forums that, you know, started out as a support tool for Let's Encrypt itself and for our many clients, but I think these are quickly becoming one of the best places to get advice on TLS configuration on the web today.
[19:49.520 --> 19:53.560]  I work pretty hard to keep them a friendly place and always welcome more people.
[19:53.820 --> 19:57.240]  Come check them out and either contribute advice or ask questions.
[19:59.060 --> 20:09.880]  So one of the other really cool things about Let's Encrypt is this new protocol ACME, which is the Automated Certificate Management Environment, which is clearly a backronym.
[20:11.100 --> 20:20.280]  I'd like to say it's named after the Acme Bread Company in San Francisco because certificates should be like bread and that, you know, everybody should have all that they need.
[20:20.560 --> 20:27.200]  But it's actually named after the Acme Company and the Roadrunner cartoons that, you know, produces boulders and anvils.
[20:27.380 --> 20:29.600]  And that's where the name of our server software comes from.
[20:29.740 --> 20:30.220]  It's Boulder.
[20:30.860 --> 20:31.980]  It's an Acme boulder.
[20:33.960 --> 20:36.780]  So here's the URL for the IETF process.
[20:37.020 --> 20:39.740]  It's an IETF standards track document.
[20:39.980 --> 20:42.180]  Would love to get more feedback, more analysis.
[20:44.880 --> 20:52.980]  So right now Let's Encrypt is the only CA implementing Acme, but StartCom, who runs StartSSL, has recently committed to implement Acme.
[20:52.980 --> 21:00.480]  They rolled out their own kind of Acme-like protocol with a custom client in a service called StartEncrypt.
[21:00.820 --> 21:05.780]  Some researchers found that there were vulnerabilities in how that does validation.
[21:06.280 --> 21:10.160]  So they've since decided, you know, let's use the standard Acme.
[21:11.880 --> 21:18.540]  SSLmate is not technically a CA, but is a kind of front end to a number of CAs that has a really convenient tool for setup.
[21:19.800 --> 21:22.940]  Andrew, who runs SSLmate, is also considering implementing Acme.
[21:28.220 --> 21:36.320]  One of the valuable things about Acme relative to previous protocols that try to do the same thing is that it covers both validation and issuance.
[21:36.820 --> 21:46.520]  So Acme includes not only instructions on how to ask a CA for a cert, but how to prove to that CA that you own the domain for the cert...
[21:46.520 --> 21:49.460]  that you own the domain that's listed in the cert that you're asking for.
[21:51.540 --> 21:53.480]  And I said we have Boulder implemented.
[21:53.480 --> 21:58.500]  We also have probably dozens of clients for Let's Encrypt that speak the Acme protocol.
[21:58.820 --> 22:07.580]  And the idea here is that once we have broader deployment in the ecosystem, you can have one client that could potentially interoperate with a number of CAs.
[22:07.840 --> 22:19.160]  And hopefully that will reduce the too-big-to-fail problem by lowering switching costs and making it easier for people to choose a CA that, you know, meets their policy goals and, you know, meets their cost goals.
[22:19.400 --> 22:20.180]  We're free.
[22:23.280 --> 22:25.400]  So this is our server software, Boulder.
[22:26.160 --> 22:27.400]  It's written in Go.
[22:28.760 --> 22:34.400]  You can visit our code on GitHub, take a look, do a security audit if you want.
[22:36.280 --> 22:44.580]  We have paid for a professional security audit and we're about to go through our second one and we've also gotten a volunteer one from the community.
[22:45.520 --> 22:48.400]  We're always interested in making this more secure.
[22:48.840 --> 22:56.740]  CA's are a core part of Internet security and, you know, we do our best to make sure we live up to that very high standard.
[22:59.200 --> 23:02.660]  So, Certbot is the first Acme client developed.
[23:02.840 --> 23:04.380]  It was developed at EFF.
[23:06.700 --> 23:20.280]  And Certbot's goal is not only to solve the issuance problem but to solve what we saw as perhaps the even bigger kind of skills gap, which is that, you know, if you wanted to buy a certificate, you know, the cost is one thing.
[23:20.400 --> 23:20.920]  You know, it's $15.
[23:21.320 --> 23:23.240]  It's not that bad if you're based in the U.S.
[23:23.240 --> 23:26.980]  It's pretty bad if, you know, you have a bad exchange rate on the dollar.
[23:27.740 --> 23:31.440]  But even beyond the monetary cost is the time and skills cost.
[23:31.620 --> 23:35.520]  You know, most people just don't know how to start getting a certificate.
[23:35.860 --> 23:39.260]  You have to create a CSR, certificate signing request.
[23:39.620 --> 23:41.680]  You have to upload it to the CA.
[23:42.060 --> 23:44.660]  You have to follow their instructions to prove you on the domain.
[23:45.000 --> 23:47.620]  You have to download the certificate and you have to install it.
[23:48.120 --> 23:51.300]  You have to remember to install the certificate chain, which is a common mistake.
[23:51.300 --> 23:53.160]  And your site won't work properly without it.
[23:53.600 --> 23:55.080]  There's a number of mistakes you can make.
[23:55.520 --> 24:00.060]  Even professional sysadmins sometimes take hours to set up a cert or renew it.
[24:00.560 --> 24:03.120]  So we wanted a tool that could handle all that for you.
[24:03.260 --> 24:07.340]  It does the proof, it gets the cert, it installs it, and suddenly you have HTTPS.
[24:07.680 --> 24:09.100]  And Certbot does this.
[24:12.480 --> 24:14.720]  It has auto configuration for Apache.
[24:15.040 --> 24:17.520]  We're working right now on adding Nginx support.
[24:17.520 --> 24:20.780]  So if you use Nginx, it can do that automatic install thing.
[24:21.360 --> 24:25.480]  Also, one of the common misconceptions about Certbot is that it requires root.
[24:25.920 --> 24:32.180]  Certainly, kind of the smoothest flow is if you have root and it can write keys with only root privileges.
[24:33.080 --> 24:36.200]  Reconfigure your Apache, write logs with only root privileges.
[24:36.520 --> 24:40.680]  But with a little bit of config, it works just fine as a non-root user.
[24:42.980 --> 24:45.780]  I mentioned we have a broad client ecosystem.
[24:46.060 --> 24:47.980]  This is just a small sampling of the ones we have.
[24:48.680 --> 24:50.220]  Lego is a client in Go.
[24:50.500 --> 24:52.160]  It's, you know, pretty small and straightforward.
[24:53.200 --> 24:55.120]  Caddy is a really unique web server.
[24:55.480 --> 24:59.660]  It acts, you know, either as a file-based web server or as a reverse proxy.
[25:00.120 --> 25:05.060]  And it just handles the Let's Encrypt certificate issuance for you.
[25:05.240 --> 25:08.620]  So you can stand up a Caddy server, tell it what your host name is.
[25:08.820 --> 25:10.160]  And you have HTTPS.
[25:10.440 --> 25:11.680]  You don't even need a separate client.
[25:13.840 --> 25:17.920]  Acme Tiny is designed as a small Python client that doesn't have any...
[25:17.920 --> 25:19.240]  That doesn't have many dependencies.
[25:20.200 --> 25:22.300]  And Acme Sharp is your option for Windows.
[25:22.580 --> 25:25.400]  I haven't tried Acme Sharp out, but, you know, try it out.
[25:25.460 --> 25:26.100]  Let me know what you think.
[25:26.920 --> 25:39.660]  And if you don't like the idea of installing any extra software on your web server, if you're familiar with the, you know, existing certificate issuance process and you just want to do that again, you can visit gethttpsforfree.com.
[25:39.800 --> 25:54.960]  This is a third-party piece of software that uses the Acme API and allows you to submit a CSR certificate signing request and, you know, gives you instructions to put a certain file on your website and do that whole thing without any software install.
[25:54.960 --> 26:00.580]  So, it takes more time, but it's, you know, just kind of zero touch in terms of installing any software on your servers.
[26:03.960 --> 26:06.560]  So, Let's Encrypt has, you know, limited resources.
[26:07.120 --> 26:13.160]  You know, we try to make them stretch as far as possible and make sure that everybody gets the certificates they need.
[26:13.500 --> 26:21.580]  And I think it's a commonplace of running a service on the Internet that if you give somebody something for free, they'll use all of it.
[26:22.260 --> 26:28.200]  So, we have some basic rate limits in place to ensure fair distribution of certificates to everyone who needs them.
[26:28.560 --> 26:34.700]  We do it based on the registered domain, which is, you know, say you have example.com.
[26:34.860 --> 26:37.440]  It would be, you know, www.example.com.
[26:38.000 --> 26:40.320]  The example.com part is the registered domain.
[26:40.420 --> 26:44.080]  And that takes into account, you know, other TLDs like .co.uk.
[26:46.420 --> 26:51.340]  So, within one registered domain, you can issue up to 20 certificates per week.
[26:51.700 --> 26:55.700]  The certificate is kind of the basic unit of what consumes resources for us.
[26:56.120 --> 27:01.560]  But each one of those certificates can contain up to 100 subject alternative names.
[27:01.740 --> 27:03.300]  So, you can have 100 names on that cert.
[27:03.580 --> 27:07.060]  They don't all have to be for the same registered domain.
[27:07.060 --> 27:13.060]  But if you're trying to get as many subdomains as you want on a single cert, you can do 100 of the subdomains.
[27:13.760 --> 27:14.820]  You can do 20 a week.
[27:14.980 --> 27:20.020]  So, each week you can do 2,000 new subdomains in certs.
[27:20.720 --> 27:22.860]  The other thing we really care about is renewal.
[27:23.100 --> 27:26.680]  Obviously, we never want a renewal to fail because you hit rate limits.
[27:26.800 --> 27:29.960]  Or somebody else who's also sharing a domain with you hit the rate limits.
[27:30.120 --> 27:31.740]  So, we have an exception in place.
[27:31.740 --> 27:39.980]  If you issued a certificate before and then you go to issue a certificate with the same set of names, you get a free pass on this particular rate limit.
[27:41.260 --> 27:43.440]  And so, what that means in practice... it means two things.
[27:44.260 --> 27:49.560]  It means you have a defense against, you know, hitting a rate limit while you're trying to renew.
[27:49.760 --> 27:55.500]  But it also means, in practice, you can continually grow the set of names for which you can issue for your domain.
[27:56.040 --> 27:59.740]  So, in week one, you issue 20 certs.
[27:59.920 --> 28:04.720]  In week two, you issue 20 new certs and potentially renew your previous ones.
[28:04.900 --> 28:08.820]  Although, you know, you actually have many days before you have to renew.
[28:12.540 --> 28:14.000]  So, 90-day certificates.
[28:14.220 --> 28:17.740]  This has definitely been one of the most controversial decisions Let's Encrypt has made.
[28:18.480 --> 28:20.780]  But so far, I think it's working out fairly well.
[28:20.780 --> 28:28.600]  There are kind of two main reasons we decided to go for 90 days, even though more traditional CAs tend to go for a year.
[28:29.900 --> 28:31.880]  One is key lifetime.
[28:32.480 --> 28:42.200]  We saw with the heart bleed attacks of 2014 that it's possible to have roughly Internet-wide potential key compromise.
[28:42.200 --> 28:48.820]  You know, any server running OpenSSL in 2014 might have had its private key compromised.
[28:49.300 --> 28:51.180]  And there wasn't really a good way to be sure.
[28:52.300 --> 28:55.620]  And it was a year before all of those keys were rotated off.
[28:55.800 --> 28:57.180]  And not necessarily even all of them.
[28:57.740 --> 29:08.800]  With 90-day certificates, you know, if people are issuing their certificate each time with a new key, you know, the time of exposure to that type of attack is smaller.
[29:09.280 --> 29:18.400]  But I think the even more important effect here is that it's allowed us to build expertise much faster with automated issuance and especially automated renewal.
[29:19.140 --> 29:24.220]  You know, Let's Encrypt's goal is not just to reproduce the existing CA structure but make it free.
[29:24.700 --> 29:30.440]  We're actually trying to do something new and special, which is, you know, make this stuff easier, make it more automated.
[29:31.400 --> 29:38.060]  So, you know, if we went with a one-year schedule, you know, it would have been a year from our first launch before we saw any experience with renewal at all.
[29:38.400 --> 29:44.180]  And we will only get a chance to improve our systems and for clients to improve their code once a year.
[29:44.400 --> 29:53.720]  So this way we've actually, you know, we get about six opportunities through the year to, you know, for each client to renew and make sure that renewal is working.
[29:54.040 --> 30:06.360]  And the goal here is if everybody can do automated renewal or, you know, a large majority of sites can do automated renewal, we can get rid of the, this certificate has expired message, which is kind of a counterintuitive thing.
[30:06.480 --> 30:08.940]  You'd think longer lifetimes would help more with that.
[30:09.020 --> 30:13.720]  But we think this is actually contributing to a stronger auto renewal ecosystem.
[30:14.420 --> 30:25.140]  And it's also encouraging hosting providers to build in core integration rather than relying on their users to go to sites like get HTTPS for free and paste in the certificate.
[30:27.220 --> 30:29.380]  So how are we doing by the numbers?
[30:31.260 --> 30:34.520]  This to me is one of the most interesting ones.
[30:34.940 --> 30:37.180]  My colleague JC Jones did some analysis.
[30:37.540 --> 30:41.280]  And this is again based on the certificate transparency project I talked about.
[30:42.400 --> 30:47.840]  So there's some large fraction of certificates that are available on the web that are now in the CT logs.
[30:48.260 --> 30:59.940]  And beyond its benefits for transparency and auditability of CAs, certificate transparency is a godsend for researchers because you have a large set of certificates you can analyze.
[31:01.300 --> 31:13.400]  So what JC found based on CT data and also based on data from censys.io, that's C-E-N-S-Y-S dot I-O, which is a scanning project from the University of Michigan.
[31:15.040 --> 31:29.040]  He found that of all the certificates issued by Let's Encrypt, if you look at the host names in those certificates, 94% of them had never been used in a certificate before that had been seen by census or certificate transparency.
[31:29.040 --> 31:31.900]  And this is really the number we're trying to affect.
[31:33.020 --> 31:40.300]  As much as we want people to be able to save money on their certificates, we're really trying to get new sites onto HTTPS.
[31:41.260 --> 31:44.200]  And so far it seems like we're doing that fairly well.
[31:46.120 --> 31:49.420]  This is an up and to the right graph.
[31:50.120 --> 31:52.800]  Number of currently unexpired certificates.
[31:52.800 --> 31:55.160]  We're currently at 4.5 million.
[31:56.360 --> 32:00.060]  You can see in the graph here there's a pretty sharp spike upwards.
[32:00.200 --> 32:12.680]  I believe that's when WordPress.com turned on automatic integration of Let's Encrypt search and issued for a million host names all over the course of a week or so.
[32:13.080 --> 32:16.120]  And that's an example of the great power of hosting provider integrations.
[32:16.500 --> 32:24.280]  You can turn on HTTPS for people who wouldn't even necessarily know what HTTPS was or why they should turn it on.
[32:24.480 --> 32:25.840]  They don't have to think about it.
[32:26.160 --> 32:28.780]  That's the level of easy encryption we really want to get to.
[32:31.680 --> 32:34.320]  This graph, I don't know how well you can read it from back there.
[32:34.560 --> 32:36.180]  This is not quite as reassuring.
[32:36.360 --> 32:38.420]  This is the percent of page loads.
[32:39.440 --> 32:40.920]  Yeah, it's very small text up there.
[32:41.060 --> 32:45.360]  But a percentage of page loads over SSL, aka HTTPS.
[32:46.100 --> 32:48.160]  And this comes from Firefox telemetry.
[32:48.160 --> 32:57.180]  So, Firefox has code in it that will, you know, collect various data that helps Mozilla improve the browser and report it upstream to Mozilla if you let them.
[32:57.560 --> 33:02.200]  The great thing about Firefox telemetry is that, you know, they actually make it public.
[33:02.380 --> 33:03.300]  It's anonymized.
[33:03.440 --> 33:06.280]  So, you know, you can't find data about a particular user.
[33:07.080 --> 33:13.580]  And it will tell us, you know, the number of page loads over SSL versus the number of non-SSL page loads.
[33:13.580 --> 33:19.520]  And you can see this is also up and to the right, but not quite so up and not quite so to the right.
[33:20.320 --> 33:27.280]  We were at approximately 37% in September of 2015.
[33:27.880 --> 33:30.480]  And we're now hovering right around 45%.
[33:30.480 --> 33:35.100]  So, we've come 7% over the course of about a year.
[33:35.100 --> 33:39.060]  If you extrapolate that linearly, which is almost certainly not going to be linear.
[33:39.280 --> 33:44.060]  But, you know, we'll get there in 7 to 8 years, getting into 100% HTTPS.
[33:44.720 --> 33:47.160]  Personally, I think that's not nearly fast enough.
[33:47.340 --> 33:49.420]  And we need to kind of step up this rate a little.
[33:49.600 --> 33:53.060]  So, we're going to be looking for more ways to increase the rate of adoption.
[33:54.200 --> 33:57.960]  And you can see there's a little bit of a kink in the graph when Let's Encrypt launches.
[33:59.140 --> 34:06.000]  But we'll see on this next graph, this is the percentage of validations using Let's Encrypt certificates.
[34:06.500 --> 34:08.240]  And so, this is also from Firefox telemetry.
[34:10.060 --> 34:13.540]  And what you can see here is, you know, we start out small.
[34:13.780 --> 34:14.520]  We get big fast.
[34:14.900 --> 34:19.220]  You know, this is kind of proportional to our number of issued certificates graph.
[34:19.220 --> 34:21.120]  But on the right is the percentage.
[34:21.900 --> 34:24.340]  And it's 0.15% of validations.
[34:25.160 --> 34:27.300]  So, Let's Encrypt is issuing a lot of certs.
[34:27.640 --> 34:30.940]  But they're mostly to, you know, what we'd call the long tail.
[34:31.320 --> 34:33.640]  Or relatively small sites without a huge amount of traffic.
[34:34.160 --> 34:35.420]  And honestly, that's fine.
[34:35.640 --> 34:41.560]  That's, you know, the goal here is not just to get the Googles and the Facebooks of the world encrypted.
[34:41.820 --> 34:48.740]  Which, you know, partly through EFI activism, they decided to go HTTPS some years ago.
[34:48.740 --> 34:54.940]  But we also want to get the smaller sites for which people would say, you know, it's just not worth my time to encrypt the site.
[34:55.080 --> 34:56.320]  You know, it's not worth three hours.
[34:56.680 --> 34:57.240]  Oh, five minutes?
[34:57.380 --> 34:58.260]  It might be worth five minutes.
[34:58.520 --> 34:59.220]  Zero minutes?
[34:59.380 --> 35:00.720]  And my hosting provider did it for me?
[35:00.980 --> 35:01.340]  Sure.
[35:01.500 --> 35:02.540]  It's totally worth zero minutes.
[35:04.520 --> 35:09.860]  So, you know, obviously, like any project, we want to see our fraction of validations go up.
[35:09.860 --> 35:13.160]  And so, this is a number we'll work on.
[35:15.080 --> 35:23.520]  So, you know, the kind of the big question posed in the title is, you know, how many certificates are we going to issue?
[35:23.660 --> 35:26.120]  I kind of gave away the punchline there.
[35:26.260 --> 35:29.120]  Which is, you know, by some estimates, there are about a billion websites.
[35:29.780 --> 35:37.420]  So, you know, if you look at the number of certs Let's Encrypt has issued today, we're at about four and a half million.
[35:37.860 --> 35:44.100]  There's some, you know, tens of millions of other certs from other CAs existing in the logs.
[35:45.480 --> 35:50.020]  But that's about two orders of magnitude smaller than where we need to be.
[35:50.340 --> 35:58.860]  So, we really need to, you know, accelerate and amplify the rate of certificate issuance and the rate of getting sites to start using HTTPS.
[35:59.760 --> 36:02.080]  This, by the way, is from InternetLiveStats.com.
[36:04.140 --> 36:05.720]  So, what do we need to get there?
[36:07.540 --> 36:09.460]  So, first off, read the code.
[36:09.820 --> 36:10.660]  You know, you're a bunch of hackers.
[36:10.660 --> 36:14.140]  We'd love you to take a look and try and find any vulnerabilities.
[36:14.680 --> 36:16.360]  You know, like I said, you know, we've...
[36:16.360 --> 36:18.460]  We pay for professional scans.
[36:18.660 --> 36:22.380]  But we are very welcoming to community contributions.
[36:23.060 --> 36:26.680]  If you see, you know, minor non-critical bug, file a GitHub issue.
[36:27.260 --> 36:30.920]  If you see a security flaw, visit Let's Encrypt.org.
[36:30.960 --> 36:32.660]  And we have our security contact on there.
[36:32.820 --> 36:35.700]  And we have a PGP key so you can email us details.
[36:38.680 --> 36:41.500]  We also definitely love more contributions to the code.
[36:41.700 --> 36:47.060]  We've gotten some great participation on both the boulder and Certbot repo from volunteer developers.
[36:47.540 --> 36:48.860]  That have really made the product better.
[36:50.600 --> 36:51.980]  We always want more clients.
[36:52.280 --> 36:53.480]  You know, like I said, we have dozens of clients.
[36:53.600 --> 36:54.860]  There's always room for more.
[36:55.220 --> 37:00.780]  You know, our attitude is let a thousand flowers bloom and let people find the clients that are right for them.
[37:00.780 --> 37:09.180]  And, you know, I think we're definitely still in the early days of experimenting with, you know, how automated certificate issuance can make things better.
[37:11.660 --> 37:13.200]  Especially documentation improvements.
[37:13.520 --> 37:19.960]  I led a workshop yesterday morning and led some of you through the process of getting a certificate from Let's Encrypt.
[37:19.960 --> 37:27.160]  And definitely there's places where our docs are lacking or, you know, could be more user focused or more to the point.
[37:28.700 --> 37:32.520]  We would love pull requests on our docs to, you know, any problem you've had.
[37:32.740 --> 37:37.620]  If you don't find the answer in the docs or you think it's in the wrong place, send us a pull request or a ticket.
[37:39.740 --> 37:48.780]  So, a lot of the work on both Let's Encrypt and ISRG comes from staff like myself funded by EFF memberships.
[37:49.640 --> 37:51.020]  We have a booth downstairs.
[37:51.280 --> 37:55.620]  I've been working the booth some of the time and it's been great to see how enthusiastic everyone is here.
[37:56.460 --> 37:57.700]  Could I see a show of hands?
[37:57.940 --> 37:59.640]  How many people are here are EFF members already?
[38:00.420 --> 38:00.860]  Nice.
[38:01.360 --> 38:02.200]  That's a lot of you.
[38:02.620 --> 38:07.600]  So, by the way, I have some special Let's Encrypt stickers that we haven't had at the booth yet.
[38:07.600 --> 38:09.540]  Until this morning because I forgot them in my luggage.
[38:10.140 --> 38:13.500]  But if you want to go down to the booth after this talk, you can get a Let's Encrypt sticker.
[38:15.060 --> 38:22.420]  So, membership funds EFF and funds not only Let's Encrypt but our broader activism for the future of technology.
[38:23.020 --> 38:34.460]  And especially if you become a member, that adds to the numbers that we can put to paper when we write our legislators and say, EFF is a membership-based organization with 25,000 plus members.
[38:37.040 --> 38:44.300]  ISRG is also an independent nonprofit and also has staff of its own, both operational and developers.
[38:45.180 --> 38:48.900]  And so, you can give to ISRG on the website, let'sencrypt.org.
[38:49.160 --> 38:51.700]  The other thing ISRG can really use is sponsors.
[38:52.100 --> 39:04.980]  You know, a lot of our money comes from large hosting companies and providers who look at their current bill for CA services and say, Well, we could spend, you know, a fraction of that on a sponsorship for Let's Encrypt and use their certificates.
[39:05.620 --> 39:13.200]  So, if you belong to an organization that has some money and you would like to see them sponsor Let's Encrypt, definitely get in touch about that.
[39:14.700 --> 39:16.840]  And especially hosting provider integrations.
[39:17.320 --> 39:22.880]  You know, I showed on that earlier graph where we saw, you know, a big spike from just one hosting provider integration.
[39:23.540 --> 39:32.900]  We've seen a number of others also and, you know, all of those have been extremely good for users in that sites are just easily available over HTTPS.
[39:33.660 --> 39:42.420]  So, if you know someone at a hosting provider, if you work at a hosting provider, see if you can integrate Let's Encrypt for automatic free encryption for your end users.
[39:43.920 --> 39:47.900]  And it's a little off the bottom of the slide here, but CT implementations.
[39:48.220 --> 39:54.500]  So, I've mentioned a few times just how key certificate transparency is to the health of the CA ecosystem.
[39:55.100 --> 40:00.800]  But CT itself is in its early days and it needs a bunch of things.
[40:01.000 --> 40:06.840]  So, in particular, we have about one CT implementation, implementation of the log server.
[40:07.760 --> 40:13.560]  And we need at least one more to really feel confident that it's in the spec and, you know, get it standardized.
[40:14.300 --> 40:19.100]  And we also need more people deploying CT logs, which is a fairly big task.
[40:19.120 --> 40:25.740]  You need, you know, a pretty solid institution to back it up, run multiple data centers, make sure that it's going to be reliable.
[40:26.080 --> 40:39.660]  What we've seen over the last few months is that some of the initial logs that were in CT have been disqualified, at least from Google Chrome's program, because they didn't meet the reliability requirements.
[40:39.960 --> 40:44.460]  So, that leaves us in this awkward position where the only CT logs we have are run by Google.
[40:44.740 --> 40:53.500]  And we really want a lot more organizational diversity in this system that, you know, keeps tabs on the Internet security.
[40:53.720 --> 41:00.120]  So, if you feel like you can write a CT log or deploy a CT log instance, please do so.
[41:00.440 --> 41:01.460]  The world needs you.
[41:02.880 --> 41:03.280]  Thank you.
[41:03.600 --> 41:05.780]  And now I'd like to open it up for questions.
[41:06.700 --> 41:07.820]  The mic is up front.
[41:08.080 --> 41:09.720]  Please come up and speak into the mic.
[41:14.430 --> 41:14.970]  How you doing?
[41:15.090 --> 41:15.310]  Thank you.
[41:15.430 --> 41:16.310]  Thank you for your work.
[41:16.590 --> 41:18.310]  I think we all appreciate it.
[41:18.830 --> 41:19.390]  Thank you.
[41:24.190 --> 41:29.730]  I'm wondering if you're anybody that could speak to the history of the CA system.
[41:30.270 --> 41:43.990]  And if you confirm a memory from my old days that when VeriSign and Thought were the only game in town, I feel I have these memories of, like, you had to be listed in standards and pores just to get a certificate.
[41:46.650 --> 41:47.110]  And...
[41:47.730 --> 41:48.930]  So, yeah.
[41:49.130 --> 41:51.710]  So, I wasn't there in the early days.
[41:51.850 --> 41:53.750]  But, you know, I've read up a little on the history.
[41:54.030 --> 42:03.230]  And, you know, certainly when the CA ecosystem was just getting started, you know, validation standards were higher and based on real identities.
[42:04.110 --> 42:11.930]  And I think over time, competition has kind of driven down the level of real-world validation required for identities.
[42:12.590 --> 42:16.290]  But we've also seen an expansion in the use cases we want.
[42:16.710 --> 42:19.730]  We want to... type of sites we want to encrypt on the web.
[42:20.210 --> 42:30.090]  And so, I think, you know, we do see a lot of division between people who feel like HTTPS certificates should reflect real identity and trustworthiness.
[42:30.290 --> 42:34.250]  Like, this is a company and they're at this address and they aren't scammers.
[42:34.710 --> 42:40.030]  Versus people who see HTTPS as kind of a trusted introducer of domain names.
[42:40.030 --> 42:45.810]  So, in other words, you know, a certificate just says, for this domain name, this is the key.
[42:45.990 --> 42:46.870]  And that's all it says.
[42:47.150 --> 42:51.170]  It doesn't vouch for the identity or trustworthiness of the person behind that site.
[42:51.390 --> 42:53.030]  So, you know, I'm in the latter camp.
[42:53.170 --> 42:55.770]  And I think, generally speaking, Let's Encrypt is in the latter camp.
[42:55.910 --> 43:02.910]  Which is that CA certificates are for this trusted cryptographic binding as opposed to a trustworthiness measure.
[43:02.910 --> 43:12.610]  And do you think that the flaws in the current system are kind of rooted in its connection to old world's institutions or...
[43:12.610 --> 43:18.690]  I feel like the original assumption was the only reason you... the only use case was financial transactions.
[43:19.030 --> 43:19.210]  Right.
[43:19.450 --> 43:23.690]  I think the flaws are inherent in the structure of the system.
[43:23.690 --> 43:25.210]  PKI is really hard.
[43:25.630 --> 43:27.570]  You know, we just have essentially three trust models.
[43:28.210 --> 43:30.730]  Tofu, trust on first use, which SSH uses.
[43:31.350 --> 43:33.490]  Web of trust, which PGP nominally uses.
[43:33.750 --> 43:38.070]  But, you know, most people just verify the keys of the people that are talking to.
[43:38.970 --> 43:43.250]  And kind of a hierarchical CA-based system, which HTTPS uses.
[43:43.550 --> 43:45.450]  And each of them has major flaws.
[43:45.650 --> 43:49.910]  I don't think anybody has synthesized them all into something really good that has all the properties you want.
[43:49.910 --> 43:54.350]  But fundamentally, this type of hierarchical system has these types of problems.
[43:54.450 --> 43:55.630]  Although we can patch some of them.
[43:56.170 --> 43:56.650]  Thank you.
[43:56.870 --> 43:57.230]  Thanks.
[44:00.010 --> 44:02.450]  Are you supporting wildcard certificates?
[44:02.950 --> 44:04.710]  We don't currently support wildcards.
[44:04.990 --> 44:05.990]  We might in the future.
[44:06.310 --> 44:10.430]  We're still working out in the ACME spec what types of validations would have to be done.
[44:10.850 --> 44:15.210]  We actually recently landed a significant change to how...
[44:15.210 --> 44:20.970]  the order of ACME validations to better accommodate both page CAs and wildcard issuances.
[44:21.250 --> 44:22.010]  Okay, thanks.
[44:26.340 --> 44:28.260]  How about TCP Inc?
[44:28.440 --> 44:29.720]  Are you following that at all?
[44:30.260 --> 44:30.960]  Sorry, say it again?
[44:31.160 --> 44:31.980]  TCP Inc.
[44:32.220 --> 44:33.220]  Increase TCP security.
[44:34.120 --> 44:36.460]  So the idea these people have is...
[44:36.460 --> 44:43.460]  every time you start up a TCP connection, you do an ephemeral Diffie-Hellman unauthenticated.
[44:43.820 --> 44:45.860]  So that you get...
[44:45.860 --> 44:47.500]  you get to encrypt.
[44:47.780 --> 44:50.000]  You're vulnerable to a man in the middle attack.
[44:50.220 --> 44:53.000]  But the idea is that you want to drop this deep into the stack.
[44:53.300 --> 44:56.380]  So the encrypt is happening automatically.
[44:56.840 --> 44:58.820]  Yeah, I definitely...
[44:58.820 --> 45:00.380]  I love the idea in principle.
[45:00.380 --> 45:05.500]  I think, you know, HTTPS is kind of, you know, becoming this huge...
[45:05.500 --> 45:08.240]  probably one of the biggest crypto systems deployed on the planet.
[45:08.420 --> 45:10.560]  But that does mean we're neglecting other systems.
[45:10.720 --> 45:14.880]  Like SMTP still has horrible vulnerabilities and very often isn't encrypted.
[45:16.960 --> 45:23.200]  In terms of ephemeral non-authenticated encryption, I'm not sure it'll get us where we need to be.
[45:23.380 --> 45:27.480]  We've had similar discussions in the HTTPS realm with HTTP 2.
[45:27.480 --> 45:29.540]  And, you know, there's...
[45:29.540 --> 45:38.720]  We've had a lot of discussion about whether we can kind of automatically get everybody onto HTTPS if we accept unauthenticated self-signed certs.
[45:41.040 --> 45:54.960]  And, personally, my feeling on the matter is that, you know, when the enemy is the ISP, as we see with Verizon and Comcast, any protocol that's man-in-the-middle-able is going to get man-in-the-middled potentially all the time.
[45:54.960 --> 46:01.580]  We have, like, middle boxes and optimizers who want to cache stuff or who want to, you know, track you or sell ads.
[46:01.580 --> 46:06.940]  And I think we will see that happen consistently to the point where, you know, it's just normal.
[46:07.140 --> 46:09.960]  So, I think we definitely need authentication in our crypto.
[46:11.420 --> 46:15.160]  I was surprised to see StartCom on the list of people using Acme.
[46:15.160 --> 46:24.500]  I remember they had their StartEncrypt project about a month ago with all of its fundamental architectural issues and then replacing versions without changing version numbers.
[46:25.260 --> 46:29.520]  Was it hard to convince them to use Acme or did public outcry change it?
[46:29.600 --> 46:31.580]  So, this is the cool thing about public standards.
[46:31.780 --> 46:37.240]  As far as I know, nobody from Let's Encrypt actually, you know, talked to them or tried to sell them on Acme.
[46:37.240 --> 46:41.380]  There was some discussion on the public lists where other people were like, why didn't you just use Acme?
[46:42.160 --> 46:45.760]  And so, they just announced that it was as much of a surprise to us as anyone else.
[46:47.240 --> 46:50.900]  But, yeah, you mentioned their launch and they had some bugs with their validation.
[46:53.660 --> 46:59.200]  How do you proceed with all the stuff that doesn't like Let's Encrypt certificates?
[46:59.740 --> 47:05.320]  Like this phone or the proxy in the place where I work, stuff like that.
[47:05.480 --> 47:05.640]  Yeah.
[47:06.140 --> 47:10.320]  So, the question is, how do you handle devices that don't trust Let's Encrypt?
[47:10.440 --> 47:17.700]  So, I mentioned earlier, you know, we did our best to be trusted as broadly as possible by getting a cross-signature from the ident-trust route.
[47:17.860 --> 47:24.000]  But actually, you know, the landscape of who trusts what is really fragmented and complicated.
[47:24.220 --> 47:28.220]  And different devices have different trust stores.
[47:28.220 --> 47:31.540]  And so, you know, you rarely see a CA that...
[47:31.540 --> 47:37.200]  In fact, you probably will never find a CA that can offer 100% validation across all devices.
[47:37.440 --> 47:39.980]  You know, usually it's in the 99 plus range.
[47:41.940 --> 47:44.560]  Depending on your device, you may or may not have options.
[47:44.880 --> 47:51.620]  So, for instance, older Android devices before, I think, 2.2 don't trust Let's Encrypt.
[47:51.840 --> 47:59.160]  And I believe, you know, I'd have to check my docs, but I believe that's actually because of the SHA-1 to SHA-2 transition.
[48:00.040 --> 48:00.600]  All right.
[48:02.180 --> 48:04.400]  I might have time for one more question.
[48:04.660 --> 48:06.500]  I want to finish this one up if anyone has one.
[48:08.080 --> 48:11.200]  But essentially, you know, you need to be able to update your software.
[48:11.420 --> 48:20.940]  I think with Android in particular, this is this problem that cell carriers don't always offer OTA updates and manufacturers don't offer OTA updates.
[48:20.940 --> 48:23.180]  So, we have a lot of old and secure phones.
[48:23.400 --> 48:26.820]  And that plays into a lot of security elements besides just trusting Let's Encrypt.
[48:28.820 --> 48:30.820]  A lot of systems that...
[48:30.820 --> 48:34.420]  One of the big categories that we're lacking trust in is JavaScript.
[48:34.820 --> 48:35.580]  We're lacking trust.
[48:35.820 --> 48:38.680]  Who are not trusted by is Java.
[48:39.160 --> 48:50.760]  And actually, the root that Let's Encrypt is cross-signed by, DST, DST root X3, which is identress root, was recently included in the most recent Java release.
[48:51.980 --> 48:54.780]  So, I'm afraid I don't have any easy answers there except upgrade.
[48:54.980 --> 49:00.600]  And, you know, if you can configure root stores, you can add DST root and ISRG root X1 to those root stores.
[49:01.560 --> 49:02.940]  Thank you all very much for coming.
[49:03.420 --> 49:04.360]  I appreciate your support.
[49:12.940 --> 49:15.400]  And, come by the EFF booth on the vendor level.