And our first speaker, over from the states, is Yan Zhu, who works at Brave, which is a company that builds a browser which is very much optimized for performance and for security.

And Yan is really prolific.

A member of the Electronic Freedom Foundation, worked on SecureDrop, Let's Encrypt, bringing digital certificate to the masses, former member of the W3C tag, just someone who's very, very busy and prolific.

So here today to talk about tools faster, safer websites, please welcome Yan Zhu everyone.

Thank you.

So I have to unlock like four different things before my presentation starts.

So hopefully less than half of this presentation will be me typing in various passwords.

Sorry about that.

I have to type in-- OK, great.

Now we can finally start, hopefully.

So my presentation is called How to Make Websites Slow and Unsafe.

Not really.

It's April Fools'.

Happy April Fools', everyone.

Yeah, Do they have that in the Netherlands? Probably had it before the US, actually.

So is the web fast, yet? Who thinks it's fast? Who doesn't? Well, that's kind of an open question.

And that's not actually one I'm going to address in this talk.

But let's actually just look at some data about how fast the web is.

This again, is from its HTTP Archive, which Estelle pointed out earlier.

So from 2014 to 2016, you see that the size of requests has gone up pretty steadily, especially CSS.

Like people are using bigger and bigger CSS files.

The number of TCP connections per site has actually remained around the same.

Sites with Flash have gone down, which is great from a security perspective.

And sites with HTTPS has gone up from 9% to 27%.

That's a factor of three.

So we should be very happy about that.

So is TLS fast yet? That's a really great question because even three years ago, or even one year ago, a lot of people said, well, we can't deploy HTTPS.

Its just too slow.

We can't do it.

The performance isn't good enough.

But I think they're wrong by now.

As an example, even Netflix now is moving to HTTPS.

They just announced this about a year ago.

Netflix, I don't know if it's that big in the Netherlands, but in the US, it accounts for the plurality of internet traffic.

So in 2015, you could say you would Netflix and chill.

In 2016, you can Netflix over HTTPS and chill.

Yeah.

Just to illustrate how dramatic this will be, on the before side, 65% of web traffic in North America at peak hours was unencrypted.

This is data from an ISP called Sandvine.

And in 2016, the red and green parts have switched, so instead of 65% unencrypted, it's about 65% encrypted traffic.

And that's solely due to Netflix.

One website.

If you need more convincing that TLS is fast now, there is a great site by Ilya Grigorik from Google called IsTLSfastyet.com.

And basically he makes the point that, yes, TLS is fast because we have good CPUs, better than we did in the early '90s, at least.

And we have all these features that can speed up HTTPS deployments.

I'll go into two of those that I think are really interesting.

So how many people here are familiar with the TLS handshake? Cool, about half the room.

So just to reiterate-- your client does a SYN-ACK with the server.

And then it says, hello, I would like to start TLS.

Server says, OK, I support TLS.

Here's my cert.

Client says, OK, here's the key we're going to use.

It's a little more complicated if you use forward secrecy, but the point is, there's three round trips that you need before you can even start sending encrypted data.

And that three round trips is what people usually think of when they say, TLS is expensive or CPU intensive.

But note that if you use session resumption, which is a feature where the server stores data from the last connection the client made so it can resume using the keys from the last session, then you can actually get this down to two round trips.

So if you want to learn more about this, just google session resumption.

But most servers will do this by default.

And you can say, like, rotate session tickets every 5 minutes or something.

And so that actually makes these handshakes less expensive.

In TLS 1.3, there

is actually going to be another optimization to get down to zero round trips, although I think SYN-ACK might still be there.

But anyway, there's ways you can make there be less round trips.

Another TLS optimization is HTTP/2.

So you might say, wait, how is that TLS.

This is HTTP/2.

It's just like HTTP/1, the next version of it-- 2.

And what is HTTP/2, anyway? Well, so HTTP/1 was created around 1995, back when sites looked like this.

You would have this header and you would have content.

And that would be great.

You could be accessible.

It was nice, it was fast.

And now sites look more like this.

You have an ad, another ad, a content somewhere like a Buzzfeed or iframe, another ad, some tracking pixels, some Flash ads, et cetera.

So sites are not this anymore.

They're slow and they make a lot of requests.

So why would we even use the same protocol.

It's actually kind of amazing we're still using HTTP/1 in a world where websites are so different.

And so that's part of why HTTP/2 exists.

I think of it as HTTP/1 on Adderall.

So it uses binary encoding instead of text and header and compression.

It has multiple performance improvements.

But the one I want to point out is that it makes multiple requests per TCP connection.

The next speaker will get more into this.

But essentially instead of making a request and waiting for a response and then making another request, the browser can just make a request and then use that same TCB connection and then get the responses back in this multiplex way, which is quite nice.

And so this largely gets rid of weird hacks that people have to do like inlining and spreading and concatenating various files so that you can minimize the number of TCP connections.

Does HTTP/2 require encryption.

So in the standardization process, this was a huge question.

Should HTTP/2 be available only over HTTPS? And the answer is no according to the spec.

But in practice, actually, yes, because there's two ways you can upgrade to HTTP/2.

Method 1 is the client just sends an upgrade header and the servers says, OK, that's cool, let's do HTTP/2.

Method is that the client in the TLS hello from the TLS handshake says, I support HTTP/2.

And then the server upgrades.

So method 1 is great if you want to support clients like cURL.

But the major browsers like Chrome and Firefox and I think now Edge has announced that they'll only support method 2 over HTTP/2.

So if you want this nice multiplexing and these nice performance improvements, you have to deploy HTTPS, unless you only want to talk to people using cURL, which you might.

And so that's what it looks like in a Wireshark dump.

My browser, Brave, connected to Akamai.

And if you look at the client hello, you see this ALPN Next protocol field, and that says H2.

And that's me saying I support HTTP/2, please upgrade me.

But you might say, well, that's great, but HTTPS is really annoying to set up and maintain.

And you would be pretty correct, at least in 2015, you would have.

Because to get a certificate, you have to do this tedious-- so this is from Dream Host, and it's this long 12-step process.

And at the end, there is a red warning bar that says, don't accidentally copy and paste your private key into our website, et cetera.

And let's say you got through this.

Usually this takes people an hour or two when they do it for the first time.

But say you get through that and you have a certificate.

Now you want to set up HTTPS.

Then you might find that you don't know how to pick the correct encryption algorithms.

So our RC4 was a popular cipher that people used up until 2014.

But then as cryptanalytic attacks against it got better and better, experts started saying, actually don't use RC4 anymore.

So unless you're keeping up to date with these latest encryption attacks, then you might not realize that this is now a vulnerable algorithm.

So let's say you get past that and now your TLS is correctly configured.

You go to your site and you (say, https)//Lenova.com.

But then your site is broken because of something called mixed content blocking.

Essentially, if you switched your top level site to HTTPS but you're including resources from HTTP origins, the browser says, no, we don't want that because that's not secure, we're just going to block it, actually.

So now your JavaScript is broken, your images aren't loading.

And it's a huge mess.

So I have good news, which is that when I was at the W3C, we actually wrote a spec to solve this exact problem.

It's called Upgrade and Secure Requests.

So essentially, if you find yourself in this situation, which many of you might, you can just send us HTTP header that says, Upgrade and Secure Requests and modern browsers will treat the page as if the subresources are HTTPS.

I actually had to use this a few weeks ago on my WordPress blog because I updated WordPress and somehow it downgraded all my HTTPS pictures to HTTP.

So I was lazy and instead of manually fixing all the HTTP links, I just said Upgrade and Secure Requests, and then voila, Chrome upgraded everything and my blog works again, which is great.

But TLS, and arguable, is still kind of difficult.

So at EFF, the Electronic Frontier Foundation, we said what if we started a certificate authority.

Sounds like a good idea, right.

Sounds kind of hard.

And what if we used our certificate authority to give everyone free certificates in five seconds or less.

And what if we also gave people packages so that they could automatically deploy TLS in an easier way.

And so that's what Let's Encrypt is.

How many people here have heard of it? Yeah, well, that's almost everyone, so good.

Let's Encrypt is a new CA.

It was created by EFF, Mozilla, University of Michigan.

Thank you very much to Cisco and Akamai for being top level sponsors.

We actually did not create a new root CA.

We're currently an intermediate CA that's been signed by a CA named IdenTrust.

So thanks to them for the cross signature.

That means essentially browsers already trust Let's Encrypt.

We are going to get into the root certificate programs for Mozilla, Firefox, and Chrome, and IE.

But that takes about a year.

So in the mean time, we're an intermediate CA.

And a new nonprofit called the ISRG is managing all of this work.

Thank you, again, to our sponsors.

So our current status is as of last fall, we entered private beta last fall.

We are now in public beta.

In our first eight hours, we issued about 10,000 certificates.

That's one certificate every three seconds.

As of yesterday, we had issued about 1.4 million certificates,

which makes us by volume one of the largest CAs, already.

And that's our activity graph.

The top line is the number of total issued certificates over time.

So here's some cool data.

What's the most popular TLD that's been using Let's Encrypt? Well, it's actually dot-com and other, but the biggest country TLD is France.

So thank you, France, followed by Germany.

And like I said earlier, we have these different clients that are using Let's Encrypt.

So who are these clients? Well, there's various types of servers that could be using HTTPS.

So I call this the client layer cake.

I last showed this slide around Halloween, so it's Halloween themed.

But we can pretend it's Easter themed now.

Maybe not.

So at the top is people like Yahoo and Google and Facebook.

They basically have their own fancy TLS infrastructure.

Some of them have their own server software that no one else uses in the open source world.

Right below that is sites that run multiple servers that are load balanced.

A lot of startups do that and a lot of smaller companies.

And then there's people like me who use Digital Ocean and AWS.

But basically we have a single server that's self-hosted or managed-hosted.

And then at the bottom layer, there is this large number of people who are just using DreamHost or WordPress where they don't have a terminal.

They just have a web interface that they go on and then do stuff.

So we want to eventually cover at least the bottom three layers.

But right now, Let's Encrypt is mostly good for the middle two.

The bottom one will require partnering with DreamHost and WordPress, et cetera.

So here is a nice pie chart of some of our clients.

I won't get into it very much, except to note that the majority is using our default client, which we ship as a Let's Encrypt package.

And it's written in Python.

This one is kind of harder to read, but it's the client operating systems.

One thing to note is that while a lot of people are using the latest Debian of Ubuntu, there's people using Debian 7 and Ubuntu 12 and stuff.

And there's a long tail of old operating systems and people who will never update.

So it's an open question of how to keep those people secure without holding back the entire internet.

So if anyone is interested in building their own Let's Encrypt client, this is just a quick picture of how it works.

So basically, the client has to contact the Let's Encrypt CA and say, I want to prove to you that this domain is authentic so you can issue a certificate to it.

So there's various types of challenges that the client can do to prove ownership of the domain.

So get challenges, perform challenges, and then cleanup challenges.

That's authentication.

Man, this is hard to read.

Not going to go into detail, but once the client proves ownership of the domain and gets a certificate, it has to do a lot of work to deploy the certificate and automatically configure the server to use HTTPS.

So this is the interface where it gets the cert, installs it, and does things.

It has features where if this somehow messes up your server configurations so your site no longer works, you can say revert and roll back, et cetera.

But anyway, so the result of all this is that to set up as a cell with Let's Encrypt, you just git clone Let's Encrypt, or download it from your package manager, if it supports it.

And then you run Let's Encrypt auto to install.

And to install TLS on Apache, all you have to do is say, Let's Encrypt Apache.

And it'll show you like a curses interface where you can pick the domains you want.

You can also specify a command line flags to say, set up SSL for these domains if you know which domains you want SSL for.

And renew or revoke will be just as easy.

You can just say.

Let's Encrypt renew, Let's Encrypt revoke.

The Python client does all of that work.

So that's it.

Make the internet great, again.

You can help out on GitHub, Let's Encrypt.

Let'sEncrypt.org is the site.

Hopefully, that was under 20 minutes.

Cool.

[APPLAUSE]