I'm Yan Zhu,  I don't work at night, technology fellow at EFF.
	Who here is excited to encrypt the entire web?  
	(Applause) 
	Yan Zhu:  I like the energy.
	[Static-inaudible] it's 2015, for instance, last summer when I went, this was the last time I logging into CORA, log in place was over HTTP and lo and behold passwords were being sent over.
	This is bad if you're like daily active users in that case, the purpose of spreading information about various topics.
	It's not bad if you have a man in the middle.
	I don't know, there's a little little site of Google, some pages like this, landing page for Google ads, still over HTTP by default, all public information, man in the middle like myself can inject a button that makes it look life-like and Google-like, and unsuspecting user will read it, and I'll direct them to my fishing site.
	This is still a problem.
	Second big problem of the world, is that setting up TLS is tedious, even in 2015.  Who here has done this process?  You know how bad it is.
	>>  I still have one arm at least 
	Yan Zhu:  What's that.
	If you want it do this on dream host, go to web WIKI, you're not an alcoholic anonymous yet, but still a 12-step process.
	How long does it take a total Newbie to setup for the first time?  I made a little video with some of co-workers from EFF.
	I went around and asked people can you setup TLS and none had done it before, So, hopefully, this will work.
	(Music Playing) (Video Playing)
	>>  Hello Parker, what are you doing today.
	>>  Trying to setup HTTPS on my website.
	>>  That sounds fun.
	>>  Yeah.	Maybe.
	>>  WOW, I didn't think that was going to be click able, no kidding -- so -- what do I do?  -- how do I do this?  (Laughter).
	>>  Okay.
	Click the wizard.
	>>  So their site was down that day.
	Guess we won't do that today.
	>>  Okay.
	>>  That's it (Laughter) so then I went to someone else in the office.
	>>  Here we have NOAH making sure he can get e-mail at [static-inaudible] which we'll need later to setup.
	>> All right, 3 minutes later.  
	>> What's up NOAH?  We are totally filming this.
	So because NOAH has not [static-inaudible] he is going to get coffee instead (Laughter).
	>>  No kidding, that's not click able.
	Express lane, I want express lane.
	Do I have to give them my real home address?  How long does it take to sign in, congratulations.  Okay.
	What does this mean?  Generally free of charge?  (Laughter) handling fee?  But where is my -- is it attached?  Where is it?  Is it in browser?  Oh, here I am, still waiting for the e-mail with my certificate.
	I got a thank you e-mail that maybe points me to an account, I have a proxy error, from their website, want to try to go to it, yeah.
	After an hour and multiple tries, no certificate.  
	(End of Video)
	Yan Zhu:  Sorry, that was sad video, this took a lot of hours due to various mistakes we were making.
	All right.
	So let's assume that went perfectly and got our certificate.
	We want to setup SSL on server, but SSL configuration is confusing.
	Few years ago people say R C4 is efficient and fast, but in 2015, say we need to kill R C4.
	Another example, Chrome [static-inaudible] not secure and sooner or later if your site uses hashes and certificate chain you'll be insecure in Chrome and Firefox.
	We should make a movie about [static-inaudible] man, gets fired from job and reads Morgan FREEDMAN -- in theaters next fall.
	Other examples, so, even later in the fall, people said, disable.
	There's log jam and log jam means you have to generate your own, and the point is, if you're not paying attention to this stuff, you can fall behind.
	And SSL configuration will be insecure if you use configure audit tool.
	It will give you F.
	But, like notice that Let's Encrypt is getting A plus, it's getting one of best sites SSL has seen recently.
	What's that?  (Laughter).
	Sorry, I did that a few days ago.
	We use latest recommended from [static-inaudible] book.
	I'll put a plugin for him right here.
	People don't have capacity to keep track of, so we end up with a broken encryption on the Internet.
	Problem 4, mix content blocking.
	This is keeping a lot of people from transitioning to full HTTPS.
	Mixed content blocking when your site is over XDDL, browser says we need to keep user at HTTPS secure level.
	So we block HTTPS resources that you try to load.
	Your site is broken in you load scriptions from AT&T.
	It's available over HTTPS, but they can't load fonts yet over HTTPS, so by default you use HTTP.
	Who here uses HTTPS Everywhere?  Awesome.
	Peter and I work on maintaining that browser extension.
	If you use HTTPS Everywhere and Chrome you can go to website and see what sites -- this is useful developer tool if you convert site from insecure to secure.
	So, open up web tools and there's a tab you with play with that helps rewrite stuff.
	W 3 C will help you out.
	There's a new header, called upgrade insecure request.
	When browser sees header, it says this site wants to upgrade, -- so physical try to HTTPS request and if that fails, it gets blocks, but it won't do insecure network request.
	And I think the final problem, is that there's too matter certificate authorities.
	There's a lot.
	Peter and some colleagues made this very complicated scaring looking graph a few years ago, Peter can you tell me what it means.
	Peter Eckersley:  Yeah, it's not the whole map, we presented at DEF CON in 2010.  We set out, we thought there would be about 66 certificate authority if FireFox, maybe 150.  But when we scan the Internet we realize they're all signing and delegating certificate authorities, -- and we concluded that, CA's operated by organizations and compromise of CA's could compromise the demand on the web.  
	Yan Zhu:  Scary, not able to sleep.
	Early this year, last year, this year, Google found certificates from Chinese certificate authority.
	This is not just theoretical, we detected this in the wild.
	Peter, this sounds bleak, how are we going to make a world that we want to live in, in the future.
	Peter Eckersley:  Solution to problem, of far too many certificate authorities, is actually to start another certificate of authority (Laughter).
	(Applause).
	But really in more detail, I'll explain in a few minutes.  We need detail vision for security so we get every website it needs and not suppose to have.
	So solution for security.
	And also solution for user ability.
	Web developers don't want to go down the insane rabbit hole.
	So, biggest question we need to answer for this project is, we're going to issue certificates, how do we decide whether to do so.
	And think of this as being like that scene from the Holy Grail, someone shows up and says I want to certificate, and you say, bring me a shrubbery and you go on your quest, and come back with a shrubbery, say that's nice but I would like a different one as well.
	This dialog, hopefully not so comical, called the ACME protocol -- we'll have a client as well, and then the shrubbery called challenges, has to perform to prove they deserve a certificate, there's issue you have to deal with, is bootstrapping from non cryptographic authentication, somehow up to cryptor, how do you know what -- [static-inaudible] for at least bulk issues certificate authorities the ones comparatively cheap and not charge $1,000, you send e-mail to, our address at that domain name, web master or something, send off e-mail, totally insecure, if link gets clicked who ever asks to happen gets [static-inaudible].
	Some go in and inspect --
	So, we are going to do variance of this time of domain validation, there's a new DV protocol, that works at TLS, aim to prove not just that you're user on destination machine that you happen to register the name admin, but that you actually have administrative control over the web.
	Consider, fake host we ask you to answer for.
	We do in TLS handshake.
	We inspect the results and make sure you're able to customize those.
	We also support simple HTTP, which has less security in it, but will also be necessary for some people behind proxies or in the wild we get certain number of tax against these things and monitor statistics and see how it's going.
	Probably down [static-inaudible] extra things one we get a lot of request is DNS valudation, have the DNS name, in a special record, and, another one we may do is upgrade of DVS, do a whole lot of domain in single handshake.
	If you're hosting thousands of domains, do one fancy challenge instead of thousands over and over again.
	And might do that on different port.
	Additional port.
	For people that want to keep their file 443 going the way it is.
	We have to do a lot of auditing on that port before you pick which one you'll use.
	Probably involve Internet wide scans.  All of this domain validation stuff is terrifying, imagine Internet is dark hole and flinging packets down the hole and something comes back and is he, yes, I'm this domain.
	And could have been eaten by monsters or modified.
	You never know.
	[Static-inaudible] they can defeat these messages.
	Not very reassuring.
	We can do better than that.
	We can do multi path, servers in multiple discs to make several versions of validation request, this doesn't completely project you, might compromise each of places or someone may compromise route.
	[Static-inaudible] this probably isn't good enough for us to build the whole Internet security infrastructure.
	We can do better than that, what we need to do is ensure this leap of faith down the dark hole only happens once.
	How?  We talked about SSL observatory, we spoke at DEF CON years ago, there's a number of projects, we have decentralized a million FireFox clients opted in sending certificates, certificates transparency databases, and Z map project that James and colleagues have done.
	And these build giant databases of all public databases in existence.
	We know, the public portion at any given movement.
	That lets us do this thing, when someone comes through the door and asks for domain name like bank in New Zealand or corporate name [static-inaudible] we look in database and say there is valid certificate for this domain name.
	We're not going to do [static-inaudible] we're going to ask you to prove position of private key in the existing valid certificate.
	That way you only get a certificate if you already, by signing something [static-inaudible].
	This is going to be a little less usable.
	It may mean you have to chase around to figure out where existing keys for your set.
	If you lost it, you might have to go to another certificate authority and buy a set.
	We insure we never wrote, to bank or anything that has a certificate right now.
	Just because router got compromised.
	You might notice, if you [static-inaudible] -- TOFU, TOFU, it's model where, if whatever trust establish on insecure connection if anything changes the person on other end changes you'll notice and be protected against it.  Next problem we have to deal with, is the horrible TLS configuration, there are, hot jam that can get you.
	What we want to have is a client that runs on your server, agent that runs on your server and magically figures out the right way to do things for you.
	At least if you want that.
	What this does is take current situation where every web developer out in the world is like a giant, crowd of millions of people, and sitting as security community quelling saying understanding this knowledge, all of you need to understand this body of knowledge to customize your site correctly.
	A world where we have a small team of people, maybe the people in this room, people that want to contribute to the project, figure how we do do it correctly, do it once correctly and give everyone a tool to sort out the details.
	That's the aim with the fancy client we're supporting.
	I aim, plan for when someone gets it and installs, it will support, tweaking existing server, we have API you can use to, to pass the challenges and then install resulting certificate or certificates.
	If you need lots of them.
	And tweak all security parameters and options, maximizing security or subject to constraints to compatibility to all clients.
	And, automating tasks like renewal and response to security incident, [static-inaudible] -- some of you probably are a little terrified saying automated security [static-inaudible].
	Let me talk about what we mean by doing that.
	It's a spectrum, this is easy stuff.
	We go and look up lists of recommended, debate them for a while, pick a good value.
	We CSP stapling so everyone can tell where the certificates have been [static-inaudible].
	More tricky is redirecting from HTTP to HTTPS because of mixed content blocking, sometimes this can cause breakage.
	We can do a fancier version, if you look if you have client modern enough and do different upgrade more modern client.
	Order renewal, we have implemented largely, but they're a little tricky, and cases, what happened if you fail to renew domain and something went wrong with one of domains so you have old set that's about to expire and new set for fewer names -- so, have to transition, you want to tell admin, please, pay attention to me, program on your server, I'm trying to juggle, but admin is not reading e-mail.
	We want to get these cases right.
	And then the hot stuff is fully right for everyone and depending on [static-inaudible] HSTS header if you don't set it your site is totally insecure but secret that can break if not done correctly.
	We need to be handholding and give admin good tools and advice and to turn on when ready and not beforehand.
	The hottest stuff -- HPKP pinning that lets you lock out all other certificate authorities but can break sites easily.
	[Static-inaudible] proxy in the server or, [static-inaudible] this stuff is theoretically possibly but engineering task down the road.
	CA is terrifying things because they control the security of the whole web and trying to build a giant automated machine and have to be afraid of thing we're building.
	How did we design for safety as we build this giant robot authentication machine?  So one part of answer is defense in depth.
	I think things I'm describe describe is that -- we need to plan, detect and survive.
	Protect against ourselves basically, we have a few cards up our sleeve with this.
	One is, all of them amount to be transparent.
	We'll publish the logs of transactions we have when people ask for a certificate.
	As a public server asking for public certificate we believe it's totally public event, so we list the logs.
	And what happened when we tried to verify it.
	Publish full verifiable certificate of issue.
	See if they're all signed and collect the set.
	And we'll also push that data into the certificate transparency logs.
	So people can validate everything is there.
	Now we also help you with HPKP, if you're brave and crazy to lock out the other thousand CA's, you still need to keep us and couple of [static-inaudible] as backup options.
	If you break that pin your site will become unreachable for months and it's happened to people.
	And then, we also need a plan [static-inaudible] compromise.
	What happened in employee is working for someone and what happens if we just screw up and there was a bug we should have stopped, but one of systems gets compromised and we're planning to, what happens if we, we see CRYPTO attacks that are powerful.
	The plan is to have some mechanisms that allow fast server initiation response.
	We should be able to put up a flag on a million sets and get them within 24 hours, issues, reissued, if client is calling us saying do you have emergency for us to respond to we can tell them before that happens.
	If they want their site working that way.
	We can do recertification, [static-inaudible] we can switch it out for a different one, go to cold storage, bank vault make a key and get new one, and roll everyone onto the new set really fast.
	These are structural protections that help make this safer.
	So, institutional, this project began as merger, and Mozilla project, it's now, all organizations teeming up together.
	Non-profit called Internet security research group, and has major sponsors, EFF, Mozilla, AKAMAI, and putting resources in.  Linux foundation, couple more sponsors on the way.
	Breakdown which bits are being done by which teams.
	Operations of CA servers and so forth -- everyone has been chipping in on the giant complicated policy and bureaucratic tasks that happen here.
	Current schedule we have, this is as of this week -- slight revision so we'll have our first set issue during the week of the 7th of September, default browsers trust from mid October roughly and beta program to start deploying them on wider set of sites and general availability.  Availability for everyone will be the 16th of November.
	In the meantime we have a lot of work today.
	This, bureaucratic tests of passing audits, producing documents, documentation about your backup plans for everything, that's one of giant tasks that make starting certificate authority expensive and time consuming.
	We have a couple people working through this.
	They're tenacious in getting those audits passed.
	And if you guys are interested our, for server and client, on gethub, come and hack it, break it, implement some of the cool features we talked about and have not got yet and help us encrypt the entire web.
	I'm not going to leave it there, hand over to James to give demo how the client works and some of the stuff we have running right now.
	>> I'm James, hopefully we can do a life demo here and nothing will go wrong.
	Pray to demo Gods if it does.
	There we go.
	You can increase your font size.
	Yan Zhu:  Can people see that?  Bigger?  
	>>  No 
	Yan Zhu:  That's about as big as you can get.
	James Kasten:  Right now using virtual environment -- hopefully we'll get into managers here, when you download the code off gethub it gives instructions to setup virtual environment and client is running in python right now.
	But let's go through an example here.
	So, pretend, [static-inaudible] who owned encryption example.com -- you know, he likes to teach people about CRYPTO set it up himself -- (Laughter) and, you know he's also interested in making money.
	So he, it has everything to be secure, all logos, and, icon up there, but doesn't run over TLS.
	Unfortunate it looks secure to me.
	You know how that goes.
	So, luckily, you can, simply he has Apache, server that -- sorry -- not used to that -- all right.
	So, I, when you run the client, go through, it preview release, basically client go through your server configuration and figure out what names you're hosting.
	Goes through CONFIG files and select which names.
	First example we do -- it will go through and solve the challenges for you.
	Listing what it does here.
	Can use a little tune up, in that timeframe we solved the challenges and setup TLS on server, that was 20 seconds rather than 3 hours.
	(Applause).
	James Kasten:  There we go.
	Yeah.
	So we have, now mind you it's self signed because we do have CA up and running yet, if you, happy hacker route, I don't advice, because keys public.
	You can get that green bar up there right now.
	(Laughter) the logo, or the, are you talked about extended elevation certificates.
	So we can also, you know -- it's probably advised for the we're awls going to want to run over HTTPS, so we can run and,  you can specify everything on the commandline and not use any prompts at all.
	Once again, it will quickly setup the server, solve the challenges and it also create redirect from the original HTTPS host to, to the new host.
	So, that's all [static-inaudible].
	>>  So we'll add nice -- try to figure out which the doss -- [static-inaudible].
	James Kasten:  Now you're safe, some people don't want us to touch configuration, which makes sense, if you want to simply remove everything or mess up configuration, which it won't, hopefully -- you can, roll back everything that I just did.
	There are 3 check points, roll back everything and now HTTPS is no longer enabled on anything and goes back to original state as if we didn't touch anything.
	What?  Not yet.
	I was trying to get that ready for demo but could not code fast enough.
	Finally, you know if we don't support your server right now or want to use another technique, you can specify, we have manual authenticator, which does not require route, it simply gives file to server and stand alone, and click.
	>>  That's on 443 so turn off existing website if you have one.
	James Kasten:  Yeah, that's it.
	(Applause).
	>>  Do we have time for questions?  10 minutes, awesome, let's go.
	I think there's a MIC, go up and ask questions on the MIC.
	>>  How hard was it to become certificate authority and get accepted by browser.
	>>  We didn't talk about this.
	How many people here think that in order to become a certificate authority you need to be accepted by the browser vendors?  Can I see hands?  I'm seeing like, so many of you may have realized you don't need to be accepted by the browser vendors at all.
	All you need to do is get one existing certificate authority to promise, by contract to cross sign you.
	And you're in, all of the browsers instantly.
	So the crucial thing for us was getting agreement with certificate authority saying if you pass audit we'll cross sign you.
	And once we had that we can talk about the fact we're going to do this.
	Because we had reliable path of being browser trusted CA.
	There's bureaucracy, documents hundreds of pages long, think we should probably have a backup plan and emergency plan and way of vetting personnel and write all of those things down, it becomes a long list.
	And write down another entry, document all your answers to previous questions an pass audit where you get asked for the documentation where the documentation is.
	It costs money and takes time.
	We're close to have it done.
	We're going to have cross sign from CA called IdenTrust.
	>>  Demo is awesome, is there plans to get involved with C panel or hosting environment where users are not so savvy to get certificates.
	>>  Absolutely we want those tools available.
	The fancy python one can be used by those hosting environment.
	I think they'll be trade off for different people.
	Some will do their own and some will apply our.
	>>  API.
	>>  Yes, 2 API, ACME, protocol, it's opened.
	And another API for client.
	You have new server so you might want to write for instance a post fix or XMVP server module.
	We have a simple API with python client that helps you understand new types of servers.
	>>  So, obviously with certificate you have to think of revocation lists, something as large as Internet you'll have a large revocation list.
	[Static-inaudible] that can cause security issues, because of compromise if they get pushed off CRL, so, what is your plan for dealing with that.
	>>  We're going to do OSCP, I can't remember latest plan, the reason for doing CRL's is make sure Google, reverts certificate list are going to have fresh way of knowing which of our sets is valid.
	We'll lunch with a 3 month validity window.
	We'll have little less risk structurally than most CA's in the long run, perhaps we could aim to one day have, CSP, staple environment, I think that's more speculative.
	And a lot of missing technical pieces an questions, because revocation on the web right now is broken.
	>>  Thanks.
	>>  On the server side, when actually updated CONFIGS, do you have plans on integrating management tools that are vying for updating those --
	>>  We want to be -- oh,  yeah, we'd like to write installer for puppet and chef, I'm aware that is major need there.
	We have not got around to that yet.
	It should be possible and if people want to write their own clients that would be awesome too.
	>>  We have a fairly clean API for extending client functionality, if you want to make those things happen, come and find us on gethub.
	>>  I work for puppet, I'll check it out.
	>>  As we know a lot of ad sites or web content are paid for through ad sites, as you push to even crept these, [static-inaudible] how do you think that will impact constant information on the web.
	>>  We launched thrive si badger, the answer is, I don't think there's a technical reason, ad tech companies switch to HTTPS, there's nothing you can't do in HTTPS that you can't to in HTTP.
	Much to my, sadness actually you can get refers, either you can post them which ad companies do, or you, if it's HTTPS, they'll largely still there.
	It's complicated, but mostly they get blocked because it's HTTP destination and HTTPS source.
	I think, [static-inaudible] some ad company why could do this.
	I've been in room with ad tech people saying why are you doing this, and I think the answer is everyone will end up doing it.
	>>  You have a lot of plans that seem lofty and large goals.
	You have 2 API's available, do you have any other API's planned and if so what will they do.
	>>  No other API's planned in, for the short-term and one of 2 API's is small.
	The big one is ACME protocol, Massachusetts shepherding through that, it's going to be like big new web protocol, the API smaller for python clients, way to write python code for your particular server that slots in neatly, it's more like plugin infrastructure for the client.
	>>  Thank you very much.
	>>  I was one of guys that said not every it site should have SSL, you talked about your plans for avoiding direction collusion, site.com, site.com, no reissue to a different actor.
	What if I get site secure.com.
	>>  I think this is opened question.
	We in talking a lot internally about 2 plans, 2 different types of plans.
	I think from a first principle basis, we need to protect against fishing, but also a question that whether [static-inaudible] is going to continue to be the best layer to do this.
	Because it's traditionally been the layer, because of lock icon and [static-inaudible] which made sense when that was a mock of a trusty E-Commerce site.
	>>  It's not trust, it's identity, gives identity and transport security.
	>>  Let me finish -- sir, let me finish.
	If we were going to do it outside of [static-inaudible] the 2 places would go into domain system itself or into the client.
	So that there's a richer API.
	The client has, already existing clients with safe browser from Google and used by other browsers.
	One option is take data set and [static-inaudible] do all of maximum protection against fishing and pass data set over to save browsing or say we have a flag going up, here is evidence, you make a decision to right [static-inaudible], the other option is we do that ourselves inside our own infrastructure but there are costs to that.
	One is, when we deploy HSTS, and then their site gets on to a watch list because they host 10,000 software downloads and 3 turn out to be malware, they get put on safe browsing list.
	If we respond to that by revokes server, would he close unrepairable outage at site.
	It seems dangerous to do this kind of detection with false positive rates inside kind of basic protocol layer that protects communication.
	We have not got [static-inaudible] these are factors we weigh out.
	People say I run that site with thousand downloads and Google blocks me sometimes, I don't want to be denied, ability to communicate for people.
	>>  I think you're also looking at identity validation versus domain validation, 
	>>  Say you're new sales certificate authority is successful and everyone has your certificates.
	Seeing primary goal to -- say I go to your encryption example right now, my web browser makes connection on port 80 first, if I'm man in middle respond to that connection, how are you going to address that.
	>>  HSTS, that, it does 2 things, deals with that and fact that people don't know secure flag on cookies and so huge numbers of wen site, don't flag them as secure and [static-inaudible] you need ultimately for secure site, we will try to help site do that but in category of things that can cause breakage and need good tooling, turning on for a few minutes, are us and gradually increasing, good test for breakage.
	The plan is go in there and fix this stuff for people but it will take work to smooth out rough edges.
	>>  Even every site is sending header, man in middle will intercept.  
	>>  There are preload lists in browser, we could auto submit.
	That would wind up on preload list, that's a bridge we have to cross with browser when we have enough deployment to cause a problem.
	>>  Do you think better solution to make browser makers to start with port 443.
	>>  Doesn't help, attacker can drop the package.
	>>  Good point.
	>>  Thank you.
	Will you eventually support world card certificates.
	>>  Not support at first, who knows what we'll do later.
	>>  I can tell you why it's hard, people mad about identity and fishing, to give people wild card certificates they can get PayPal, they're domain.com whatever, and they can do that without limits.
	And so -- we will get, unless we have a good answer to the fishing debate, wild cards will be politically sensitive for that reason.
	>>  Follow up with that, anyway at all you can use this for dot local domains.
	>>  Dot local domains, in TLS make sense, the thing one should aim for there, is get name space that's, not colliding or makeup new browser UI for local.
	[Static-inaudible] for this local name spaces.
	But [static-inaudible] separately from public web names.  Thank you.
	>>  Thank you everyone.
	(Applause).
	(Applause).