[00:00.000 --> 00:00.340]  My name is Langley.
[00:01.300 --> 00:08.500]  Variously, I work on SSL networking stuff on Google Chrome, and I'm mostly the engineer behind Google's HTTPS serving.
[00:09.960 --> 00:16.080]  And if I had the slides today, which apparently I don't, I will have to describe what you would see, were you able to see them.
[00:16.820 --> 00:18.800]  This would be called Living with HTTPS.
[00:18.920 --> 00:22.700]  I think I called it State of HTTPS in the program, but I prefer the other name.
[00:28.130 --> 00:28.530]  Oh.
[00:28.530 --> 00:31.550]  While you're there, sir, could you turn down the game on this mic a bit?
[00:32.130 --> 00:33.530]  I feel very voice-of-goddy.
[00:34.350 --> 00:35.030]  One, two.
[00:35.310 --> 00:35.390]  Yeah?
[00:35.870 --> 00:36.510]  Can I hold it back here?
[00:36.710 --> 00:36.850]  Cool.
[00:37.010 --> 00:37.210]  Thank you.
[00:38.050 --> 00:39.550]  Well, let's not wait for the projector.
[00:41.990 --> 00:48.770]  So, most talks around HTTPS are mostly a rant about the State of CAs, and this is not that talk.
[00:49.030 --> 00:51.050]  If you want that talk, you should go find Moxie.
[00:51.130 --> 00:52.370]  Moxie does a great talk about that.
[00:54.190 --> 00:54.910]  Hello, Moxie.
[00:55.150 --> 00:55.170]  No.
[00:57.570 --> 01:00.910]  But this talk is about the fact that most of your websites... Oh, cool.
[01:00.910 --> 01:03.890]  Most of your websites probably don't even get up to that level.
[01:04.090 --> 01:07.450]  So, you have to be doing really pretty well to even start worrying about that.
[01:10.730 --> 01:12.330]  I'm a transport security person.
[01:12.610 --> 01:20.050]  So, throughout this talk, the model is that we have two perfectly functional, non-corruptive computers that are talking over an evil network.
[01:20.510 --> 01:24.710]  So, at no point am I concerning myself with the fact that people's machines get compromised.
[01:24.950 --> 01:25.670]  That's host security.
[01:25.670 --> 01:28.070]  Chrome does great on that as well, but that's not me.
[01:29.110 --> 01:34.030]  And we assume the network is going to be fabricating packets, dropping packets, altering packets.
[01:34.470 --> 01:42.010]  And just as a basic lemma, when we're dealing with HTTPS, that also means that the network can direct the user to any web page.
[01:42.190 --> 01:46.590]  Because the network can always insert an iframe in any random HTTP request you make.
[01:46.590 --> 01:51.590]  So, we just assume that the attacker can always cause your browser to navigate to any web page.
[01:52.070 --> 01:57.170]  It's a somewhat non-obvious colliery to the fact that the network can inject packets.
[01:57.870 --> 02:09.290]  So, let's assume that our poor victim user goes to their web browser and types in mail.google.com, hit enter, sees this, logs in, and they're done.
[02:09.410 --> 02:09.690]  That's it.
[02:09.750 --> 02:10.070]  Game over.
[02:10.170 --> 02:10.610]  They've just lost.
[02:10.770 --> 02:13.890]  If they're in Iran or Syria, it might really be game over.
[02:14.590 --> 02:18.770]  Unfortunately, some of my users entrust their lives to the products that I have to secure.
[02:19.050 --> 02:22.590]  And that's a rather uncomfortable position to be in, but they do it and we do our best.
[02:24.390 --> 02:28.050]  So, hands up who in this room is looking at that and going, oh, that's obvious.
[02:28.110 --> 02:29.050]  I would never fall for that.
[02:29.130 --> 02:31.750]  I would never have just been owned by my government.
[02:32.390 --> 02:34.090]  One, I mean, you're possibly right.
[02:34.090 --> 02:36.490]  This is the audience where people would pick up on this.
[02:36.690 --> 02:42.210]  But the fact is that 99% of people are not going to notice that it's not an HTTPS site.
[02:42.210 --> 02:45.110]  Even if you can't read the text, there's no green up there.
[02:45.190 --> 02:45.970]  There's no green padlock.
[02:46.590 --> 02:51.410]  The problem is that when you type mail.google.com, the default protocol is insecure.
[02:51.830 --> 02:52.990]  The default protocol is HTTP.
[02:54.590 --> 03:02.450]  So, your browser will go off and make an HTTP request which the network can quite happily answer and give you a login page which looks exactly like a real Google login page.
[03:02.810 --> 03:05.650]  And people will log in and there will be absolutely none the wiser.
[03:06.190 --> 03:07.650]  This is called SSL stripping.
[03:07.870 --> 03:13.530]  It is a devastatingly effective attack which will work against almost all secure websites out there.
[03:13.930 --> 03:21.070]  Even ones where I guess we expect users to notice that it's not secure by the tiny lack of green up there.
[03:22.050 --> 03:28.810]  But there are other websites where it's an HTTP site but they say login using our secure server and the form is meant to submit over HTTPS.
[03:29.490 --> 03:31.170]  At this point, the user just has no hope.
[03:31.290 --> 03:32.990]  There is no indication of whether it's secure or not.
[03:34.130 --> 03:39.770]  So, before you start worrying about CAs and all of that stuff, this is what is going to get your users.
[03:40.290 --> 03:45.550]  Now, we don't have any reports in the wild of countries like Iran and Syria doing this.
[03:45.870 --> 03:50.390]  But partially, we have really bad introspection to these countries.
[03:50.550 --> 03:57.450]  The set of people in these countries, it turns out, who are technically knowledgeable, bilingual, liberally minded, is very small.
[03:57.690 --> 04:01.250]  We do not find out when terrible things happen in these countries very quickly.
[04:01.250 --> 04:06.610]  So, if this ever starts happening, given how subtle it is, we may never know.
[04:07.070 --> 04:09.230]  The solution to this is really quite straightforward.
[04:09.510 --> 04:10.190]  It's this.
[04:10.930 --> 04:14.030]  This is HSTS, HTTP Strict Transport Security.
[04:14.290 --> 04:19.350]  It is a standard that allows websites to tell browsers that they are always to be accessed over HTTPS.
[04:20.670 --> 04:23.570]  This is a header that you can set on an HTTPS site.
[04:23.750 --> 04:30.130]  And it says, remember, for 100 days, I guess, 86,400 times 100.
[04:30.510 --> 04:33.770]  Remember for the next 100 days that I am always to be accessed over HTTPS.
[04:33.910 --> 04:35.510]  And by the way, that means all subdomains.
[04:35.970 --> 04:38.790]  And we'll come back to why include subdomains is important.
[04:39.410 --> 04:44.930]  So, this means that when the user types mail.google.com, they will go over HTTPS initially.
[04:46.110 --> 04:48.530]  And it means that this is impossible.
[04:48.730 --> 04:55.250]  And in fact, this is already impossible because there are sites built into Chrome which Chrome knows are HSTS.
[04:55.550 --> 04:58.770]  Mail.google.com, accounts.google.com, these are built in.
[04:58.770 --> 05:06.470]  I had to alter this page in GIMP in order to get rid of the green because it is not possible to access these sites in Chrome insecurely.
[05:07.410 --> 05:10.790]  Firefox and Chrome will remember these headers.
[05:11.050 --> 05:13.470]  But obviously, there is a first-time problem.
[05:13.530 --> 05:20.230]  If the user flushes their cache, if the user installs a new browser, if they open a new profile, then we don't know this information.
[05:20.550 --> 05:22.990]  So, getting it built into the browser solves that problem.
[05:23.410 --> 05:24.690]  But this is there to scale.
[05:25.390 --> 05:27.470]  Now, the way you get it built into Chrome is very easy.
[05:27.470 --> 05:28.550]  You email me.
[05:29.070 --> 05:32.390]  You email me and I say, okay, like, your site looks reasonable.
[05:32.570 --> 05:33.330]  I'll check it into Chrome.
[05:33.630 --> 05:35.330]  But wait, you might exclaim.
[05:35.510 --> 05:39.990]  Surely, emailing you, Adam, is a ridiculous non-scalable method of including all of these things into...
[05:39.990 --> 05:40.510]  Yeah.
[05:40.870 --> 05:41.690]  And absolutely, it is.
[05:41.810 --> 05:43.650]  But scalability is not a problem that we have.
[05:44.470 --> 05:48.830]  We have, in the built-in Chrome lists, we have a whole bunch of Google properties.
[05:49.750 --> 05:51.230]  We have PayPal, sort of.
[05:51.770 --> 05:54.930]  We have Twitter, kind of, sort of, real soon now, they promise us.
[05:56.010 --> 05:58.290]  And in terms of sites that you've heard of, that is about it.
[05:58.910 --> 05:59.830]  We have no banks.
[05:59.990 --> 06:02.310]  Well, we have one bank, sort of, in .mt.
[06:02.490 --> 06:03.750]  And I'm not sure where .mt is.
[06:04.130 --> 06:06.310]  But their financial institutions are more clueful than ours.
[06:07.810 --> 06:11.830]  Because we have no banks who have contacted me saying, you know, we want to be put into this list, blah, blah, blah.
[06:11.830 --> 06:13.710]  And maybe that's rational on their point.
[06:13.830 --> 06:18.330]  Maybe all of their users are getting owned by malware so fast that transport security is not even a concern of theirs.
[06:20.410 --> 06:22.930]  But, yes, scaling is not a problem that we have.
[06:23.270 --> 06:27.530]  But nonetheless, HSGS, I put it first in this talk because it's by far the most important thing.
[06:27.610 --> 06:29.070]  If you remember nothing else, please remember this.
[06:29.950 --> 06:30.910]  HSGS is wonderful.
[06:31.050 --> 06:34.710]  And I will be coming back to why it is wonderful in many different respects throughout this talk.
[06:34.710 --> 06:41.450]  The next way in which it is wonderful is that it turns this, right, this is something that people sadly see quite a lot.
[06:41.810 --> 06:43.430]  But it turns this into this.
[06:43.870 --> 06:46.850]  And the important aspect is not that the width of the text changed.
[06:46.930 --> 06:47.670]  I don't know why that happened.
[06:47.910 --> 06:50.030]  The important aspect is here we have two buttons.
[06:50.330 --> 06:51.850]  This proceed anyway button.
[06:52.210 --> 06:54.710]  God, I hate that proceed anyway button because everybody clicks it.
[06:54.970 --> 06:59.230]  We know that statistically nearly 80% of Chrome users click on that button when they see this page.
[06:59.390 --> 07:01.150]  And this is really red.
[07:01.390 --> 07:03.010]  We can't make this any more scary.
[07:06.490 --> 07:07.650]  But this is really red.
[07:07.930 --> 07:11.910]  And Syria, a year ago, did this to Facebook.
[07:12.190 --> 07:13.370]  They didn't even try, right?
[07:13.450 --> 07:14.630]  They man-in-the-middle attacked Facebook.
[07:14.850 --> 07:17.010]  They should have just SSL stripped it because that would have worked.
[07:17.750 --> 07:18.510]  But they didn't.
[07:18.630 --> 07:21.010]  They replaced Facebook.com with a bad certificate.
[07:21.010 --> 07:24.030]  And you got this error and people clicked through at a hell of a rate.
[07:24.450 --> 07:28.310]  And I don't know what the human damage resulting from that was.
[07:28.450 --> 07:30.590]  But in Syria, not good.
[07:31.610 --> 07:33.750]  But HSTS turns this into this.
[07:33.750 --> 07:36.430]  And the important thing here is there is no proceed button.
[07:37.290 --> 07:40.170]  All certificate errors are fatal on HSTS sites.
[07:40.430 --> 07:45.410]  It is completely ridiculous that we ask our users to evaluate the security of X.509 certificates.
[07:45.690 --> 07:47.110]  We should never have done that.
[07:47.490 --> 07:49.430]  We are locked into it as a legacy item.
[07:49.910 --> 07:52.130]  HSTS is the way that we can crawl out of this.
[07:52.590 --> 08:00.550]  So, with Chrome, if you go to mail.google.com and you are man-in-the-middle attacked, it does not work because the certificate error only has a back button.
[08:02.790 --> 08:09.470]  Next up, HSTS will protect you from making mistakes, even if you think you are a great website.
[08:09.470 --> 08:17.390]  For example, let's say, and it is common security practice, we try to teach our users you need to type in HTTPS or you need to use a bookmark.
[08:17.610 --> 08:19.310]  Using a bookmark is actually a pretty good idea.
[08:19.910 --> 08:24.670]  So, let's say you have set up your mother's computer with a bookmark for her banking site and she clicks on it.
[08:26.350 --> 08:28.310]  So, I am not picking on Citibank, by the way.
[08:28.390 --> 08:31.870]  They were literally the second site I tried and they had this problem.
[08:32.050 --> 08:33.550]  I was surprised the first site didn't.
[08:34.410 --> 08:38.010]  But this is a widespread problem of which Citibank is merely a convenient example.
[08:38.750 --> 08:41.110]  So, let's say that you set up a bookmark for this.
[08:41.310 --> 08:46.770]  Now, you have gotten past the initial problem that HTTP is the default because you set your bookmark with HTTPS.
[08:46.910 --> 08:47.250]  Clever you.
[08:48.170 --> 08:49.710]  But if you do this, what do you get?
[08:50.950 --> 08:52.230]  Okay, well, this is beside the point.
[08:52.330 --> 08:52.550]  I am sorry.
[08:52.690 --> 08:53.330]  Please don't do this.
[08:53.330 --> 08:54.450]  Citibank, what the hell?
[08:57.070 --> 08:58.770]  So, let's say, let's try this again.
[08:59.310 --> 09:00.630]  www.citibank.com.
[09:02.250 --> 09:04.510]  If you click on this bookmark, what do you get?
[09:04.750 --> 09:06.450]  You get redirected back to HTTP.
[09:07.590 --> 09:10.550]  And, of course, from there you get redirected to HTTPS again.
[09:11.070 --> 09:12.390]  But that is beside the point.
[09:12.470 --> 09:15.570]  Because as soon as you have gotten to this point, the attackers got their in.
[09:16.030 --> 09:17.070]  Again, game over.
[09:17.330 --> 09:20.950]  Lots of sites do this because from Citibank's point of view, everything works.
[09:20.950 --> 09:22.530]  It's completely silent.
[09:22.710 --> 09:24.590]  It's completely non-obvious that there's something horribly wrong.
[09:24.950 --> 09:25.650]  Everything works.
[09:26.150 --> 09:27.970]  And huge numbers of sites do this.
[09:28.070 --> 09:30.590]  Their redirect trains bounce back between HTTP and HTTPS.
[09:33.250 --> 09:36.390]  I'm going to sort of step away from HSGS for a second.
[09:37.090 --> 09:44.890]  Assuming you get that done, the next thing which is going to completely destroy all security on your site are the three horsemen of the mixed scripting apocalypse.
[09:46.290 --> 09:46.730]  Right?
[09:47.790 --> 09:53.370]  If you have any of these three on your website, and dear God, it's really easy to do it.
[09:53.530 --> 09:54.570]  You have no security.
[09:54.730 --> 09:55.070]  It's over.
[09:55.650 --> 10:01.410]  What these are doing is these are directing an HTTPS web page to load content from HTTP.
[10:01.890 --> 10:02.730]  Active content.
[10:03.010 --> 10:04.610]  You can load images and that's not great.
[10:04.730 --> 10:06.210]  The attacker will replace the image with porn.
[10:07.010 --> 10:08.870]  It's not fantastic, but it happens.
[10:08.870 --> 10:14.350]  But if you do this, then the attacker gets to run generally arbitrary JavaScript on your origin.
[10:14.810 --> 10:16.750]  At which point we also call that game over.
[10:17.230 --> 10:19.430]  This is incredibly easy to do.
[10:19.770 --> 10:26.070]  Because if you have a site that serves over both HTTP and HTTPS, the attacker gets to pick the page.
[10:26.510 --> 10:41.590]  So these pages which you do not... which no user in a normal flow would ever get to over HTTPS, if they're served over HTTPS and they have this in, which will never cause a problem because they're meant to be served over HTTP, that's enough.
[10:41.790 --> 10:43.790]  The attacker gets to pick the page which has this problem.
[10:44.590 --> 10:47.250]  The way to try and sort this out is to get into good habits.
[10:47.590 --> 10:55.070]  Good habits, in this case, involve scheme relative URLs, which are relatively obscure but completely browser compatible.
[10:55.450 --> 10:56.510]  Stunningly, these work everywhere.
[10:56.610 --> 10:56.950]  No problem.
[10:57.110 --> 10:58.990]  We use them on google.com all the time.
[10:59.190 --> 11:00.650]  And we're a quite large website.
[11:01.930 --> 11:05.770]  You use this, and it will adopt the scheme from the surrounding page.
[11:05.950 --> 11:08.030]  So if it's an HTTP page, it's an HTTP load.
[11:08.150 --> 11:09.770]  If it's an HTTPS page, it's an HTTPS load.
[11:10.710 --> 11:17.990]  The only downside is that if you look at your website when it's on disk, then it will be file, and it will inherit the file protocol, and then it won't work.
[11:18.510 --> 11:25.090]  But nonetheless, this is a good habit to get into because there will be browsers for decades to come which will load mixed scripting.
[11:25.150 --> 11:27.490]  And if your users are using that, you're in trouble.
[11:28.610 --> 11:39.090]  But realistically, persuading every webmaster in the world to understand this problem and to not screw up when it's incredibly easy to do so is not a going concern.
[11:39.290 --> 11:43.330]  So instead, what's going to have to happen is the browsers are going to have to block mixed script loads.
[11:43.330 --> 11:46.510]  So to their credit, IE9 does this.
[11:46.730 --> 11:48.010]  IE9 did it before Chrome.
[11:48.270 --> 11:49.350]  We were quite embarrassed.
[11:49.650 --> 11:54.870]  We scrambled to do it as fast as we could, but it's really tough to deploy because so many people mess this up.
[11:55.090 --> 12:00.870]  But now, I'm glad to say, in Chrome, if you do a mixed scripting load, you will get this.
[12:01.030 --> 12:02.190]  It does not work by default.
[12:03.630 --> 12:08.490]  This obviously is a CSS load that's been blocked, which is why the New York Times is looking like it's 1995.
[12:10.810 --> 12:13.650]  There's one of these damn buttons again, but it will go away.
[12:14.370 --> 12:18.970]  This is, we're going to have this for 12, 18 months, and then the don't load button will go away.
[12:19.130 --> 12:23.650]  It's already gone away for some sites, and then we'll just block mixed scripting.
[12:23.810 --> 12:27.350]  But not all of your users you can rely on to be using IE9 and Chrome.
[12:27.650 --> 12:30.130]  So you still have to pay attention to mixed scripting problems.
[12:30.130 --> 12:32.010]  They can still screw your users.
[12:34.230 --> 12:42.270]  The next unfortunate problem we are laden with from HTTPS is that HTTP and HTTPS cookie jars are the same thing.
[12:44.090 --> 12:49.190]  So, remember, we assume that our attacker can cause the user's browser to load any page.
[12:49.370 --> 12:51.810]  They can just inject iframes onto any insecure load.
[12:52.390 --> 12:58.990]  So, if you set a cookie on an HTTPS site, and they cause the browser to load some subdomains, that cookies will be sent along.
[12:59.210 --> 13:00.790]  This is fairly standard.
[13:01.650 --> 13:08.790]  And hopefully, those of you who are webmasters in the audience know that you can set the secure tag on a cookie, which says, only send it over HTTPS.
[13:09.170 --> 13:11.670]  Don't send this cookie over HTTP requests.
[13:13.690 --> 13:20.610]  This is a complete miasma, because, again, if you forget to set this tag, everything works just perfectly.
[13:21.230 --> 13:28.210]  We can't automatically figure out anything in the browser, because sites quite legitimately set cookies, which are both secure and insecure.
[13:29.330 --> 13:32.490]  And so, sites miss this tag all the time.
[13:32.590 --> 13:37.050]  Even if they get it right now with the next revision, they forget it, and nothing breaks.
[13:40.790 --> 13:42.850]  But, HSTS will solve this problem for you.
[13:43.150 --> 13:50.630]  If you set HSTS and say include all subdomains, that means the browser... sorry, the attacker cannot make your browser do an HTTP load.
[13:51.270 --> 13:53.230]  Because all loads are over HTTPS.
[13:53.410 --> 13:54.010]  You've already said that.
[13:54.670 --> 14:09.450]  There is a second part to this fact, which most people miss, which is that not only will HTTPS cookies be sent on HTTP requests, but HTTP requests can set HTTPS cookies.
[14:10.130 --> 14:18.810]  If I, as an attacker, force you to do an HTTP load, I can do a set cookie, which will override cookies that were set on HTTPS.
[14:19.250 --> 14:25.410]  So, as an attacker, when you are, say, logged into Gmail, I can make you do a load, and I can log you in as me.
[14:26.010 --> 14:32.710]  And just as you click send mail, that mail gets sent into my outbox, and I can log you back in as you, and you'll never know it happened.
[14:35.050 --> 14:37.910]  HSTS protects you from this as well, for exactly the same reason.
[14:38.030 --> 14:42.330]  If we prevent HTTP loads, and there's no way the attacker can get the cookie to set it.
[14:43.650 --> 14:47.810]  Sorry, I mean, the attacker can get the cookie, but they can't get the HTTP request to set the cookie.
[14:49.430 --> 14:55.730]  And actually, for the example of mail.google.com, at least, you know, in Firefox and Chrome, it won't work because of HSTS.
[14:58.870 --> 15:04.150]  At this point, if you fix these three problems, you are in the top 0.1% of secure websites.
[15:05.550 --> 15:06.830]  Possibly even more.
[15:06.970 --> 15:14.790]  Because I basically never see sites which are not run by people who work with me that get all this right, these three things.
[15:15.870 --> 15:18.170]  HSTS, mixed scripting, cookies secure.
[15:20.730 --> 15:23.410]  So, you know, if you need to run away, you can do so now.
[15:23.730 --> 15:25.190]  You have gotten most of the value of this talk.
[15:27.550 --> 15:31.890]  Next up, if you're going for bonus points, put your website into SSL Labs.
[15:32.890 --> 15:39.170]  SSL Labs is a lovely little site which will run some tests, and it will give you a grade, and I don't know how the grade is determined.
[15:39.370 --> 15:46.930]  But it will tell you a bunch of things, a bunch of hard-to-diagnose stuff that people commonly get wrong, and it will say, you've got it wrong, which is very good to know.
[15:47.630 --> 15:55.370]  The only caveat I have, I don't run this website, is it will scream about something called the beast attack, and you shouldn't worry about that because the browsers all fixed it.
[15:55.370 --> 16:06.610]  in a, quite frankly, staggering display of cooperation, all the browsers together all decided that they were willing to break some old websites in order to fix this problem.
[16:08.150 --> 16:12.090]  And Firefox was a little bit behind, and they took some shoving, but they got there eventually.
[16:12.370 --> 16:21.930]  And so now all the browsers have patched to use 1n-1 record splitting, and so servers don't need to worry about the beast attack by only using RC4, but SSL Labs still screams about it.
[16:22.230 --> 16:24.210]  Other than that, this is a fantastic site.
[16:24.210 --> 16:29.330]  If you run an HTTPS server, you should put yourself in there because it takes all of 30 seconds.
[16:31.810 --> 16:35.570]  Next up, none of this is worth anything if you don't have a real certificate.
[16:37.030 --> 16:38.090]  StartSSL, give them away for free.
[16:38.670 --> 16:40.690]  They're a little Israeli company run by one dude.
[16:41.110 --> 16:42.770]  I think he has some staff, but it's mostly one dude.
[16:44.770 --> 16:45.230]  I'm sorry?
[16:46.390 --> 16:47.250]  There's three of them now.
[16:47.610 --> 16:48.130]  It's not just Eddie.
[16:48.370 --> 16:48.450]  Okay.
[16:49.590 --> 16:51.370]  But nonetheless, StartSSL are a real CA.
[16:51.490 --> 16:52.210]  They're really audited.
[16:52.210 --> 16:55.470]  They have decent penetration, but I don't think they're in XP.
[16:56.310 --> 17:03.750]  But nonetheless, if you're currently running a self-signed certificate and you force your users to click through every single time, please stop training them to click through that damn red screen.
[17:06.550 --> 17:07.870]  Oh, they're in the latest XP.
[17:07.870 --> 17:14.870]  Okay, so if you're using XP3, I guess, which some of them might be, then it even works there.
[17:15.170 --> 17:18.010]  But like I said, they have the most god-awful website in the world.
[17:18.130 --> 17:21.190]  It's a complete nightmare to use, but they give away real certificates for free.
[17:21.330 --> 17:28.410]  So if you are using a self-signed cert or you were not doing HTTPS because of this problem, this is your answer.
[17:30.590 --> 17:31.730]  Next up was...
[17:31.730 --> 17:32.130]  Oh, yes.
[17:32.690 --> 17:33.690]  Consider forward secrecy.
[17:33.830 --> 17:35.430]  Again, this is just for bonus points.
[17:35.790 --> 17:41.850]  If you've gotten HTTPS mixed scripting and your cookie is correct, you can go home and sleep.
[17:41.970 --> 17:42.510]  You're doing great.
[17:42.710 --> 17:45.670]  If you are looking for bonus points, think about forward secrecy.
[17:47.370 --> 17:58.330]  If you've been to the talks that the EFF gave two days ago and yesterday, then hopefully they've explained to you the value of maybe not logging and maybe having a retention policy.
[17:59.990 --> 18:07.670]  And I'm assuming that, you know, folks like you run websites used by people in countries, which that's really useful.
[18:08.770 --> 18:14.110]  But if you are not using forward secrecy, then it might be that someone else is doing the logging for you.
[18:16.410 --> 18:18.450]  Now, I'm hoping that nobody here is a beginner.
[18:18.830 --> 18:23.030]  So, I'm assuming that, you know, when I talk about SSL, you're going to know the basics.
[18:23.270 --> 18:30.510]  But most of the time, if you have a laptop open and use Chrome and you click a green padlock, it will tell you the key exchange method used for that connection.
[18:30.750 --> 18:32.310]  And typically, it will be RSA.
[18:33.290 --> 18:42.570]  An RSA key exchange in TLS means that the client picks a session key, a random session key, it encrypts it to the server's public key and sends it to the server.
[18:42.570 --> 18:47.910]  And we know the server's who they say they are because only the real server could decrypt that session key and complete the handshake.
[18:48.150 --> 18:49.310]  This is perfectly fine.
[18:49.790 --> 18:57.550]  But it means that at any point in the future, that RSA private key is sufficient to decrypt that session key again.
[18:57.770 --> 19:05.530]  So, if anybody has recorded that handshake and they get your private key at any point in the future, they can decrypt it retrospectively.
[19:06.750 --> 19:15.510]  I have not yet heard of any law enforcement agency or autocratic government being clueful enough to record traffic and then exploit the private key.
[19:16.930 --> 19:19.560]  But they keep on getting better, right?
[19:20.390 --> 19:24.690]  The autocratic governments, they were pretty clueful at the start and they were using off-the-shelf stuff.
[19:24.870 --> 19:26.930]  And now they've moved on from off-the-shelf stuff.
[19:28.470 --> 19:33.610]  And this is something, like I said, for bonus points, that will probably be more important in about five years' time.
[19:33.710 --> 19:34.990]  No harm in getting to it now.
[19:35.850 --> 19:51.390]  So, what forward secrecy means is rather than using RSA for a key exchange, we use one of the two methods of key agreements that TLS supports that causes the server to make up a public key for that one connection, sign that public key, and then use that to agree the key.
[19:51.390 --> 19:54.250]  Now, after the connection is finished, that public key is destroyed.
[19:54.910 --> 20:00.670]  So, the information required to decrypt that connection does not live beyond the lifetime of that connection.
[20:00.930 --> 20:03.410]  There is no possibility of retrospective decryption.
[20:03.710 --> 20:09.090]  Even in 10 years' time, when your RSA key can be factored, we still can't retrospectively decrypt these connections.
[20:11.510 --> 20:16.890]  The way you enable this in your config is that you promote DHE or ECDHE cipher suites.
[20:17.770 --> 20:34.130]  Most of you, if you run servers, are probably aware of this incredibly odd line that's probably in your Apache config that says SSL cipher suites, which includes a snippet from a text protocol defined by OpenSSL, and it has lots of exclamation marks and words like all and high and medium and,
[20:34.130 --> 20:44.170]  you know, plus AES and all this stuff, you can take that string and you can plug it into OpenSSL ciphers and it will tell you it will expand it into the list of ciphers that it meets.
[20:44.510 --> 20:48.950]  What you want is that you want DHE and ECDHE ciphers to be at the top.
[20:49.530 --> 20:56.610]  And realistically, I'm not going to be able to explain all the ins and outs of forward secrecy and their interactions with session tickets right now.
[20:56.730 --> 21:00.210]  Although when we get to questions, if somebody here wants to ask me, I'll go on about it.
[21:00.830 --> 21:05.990]  This is more a pointer to those who want to know that, oh, maybe I should look into forward secrecy.
[21:06.090 --> 21:08.930]  Maybe I should do a Google search on that and see how I can configure my web server.
[21:11.830 --> 21:15.870]  Again, for bonus points and less so, you should keep your software up to date.
[21:16.050 --> 21:18.050]  And I don't just mean security revisions.
[21:18.130 --> 21:19.270]  I take that for granted.
[21:20.570 --> 21:26.390]  I have patches in, I think, half of the OpenSSL security advisories in the past year or two.
[21:27.210 --> 21:28.990]  They keep on coming up at quite a rate.
[21:28.990 --> 21:34.250]  You have to keep up to date with your security advisories in OpenSSL, in your web server, and so forth.
[21:34.950 --> 21:38.530]  But beyond that, OpenSSL actually gets better over time.
[21:38.650 --> 21:41.170]  It's a very mature library, but we are working on it.
[21:41.310 --> 21:42.490]  And here's one example.
[21:42.950 --> 21:50.470]  So, I mean, the bottom may be cut off by heads for some of you, but the three bars are basically the last three major revisions of OpenSSL.
[21:50.470 --> 21:52.430]  098, 10, 101.
[21:53.630 --> 21:59.270]  And the higher the bar, the more RSA 2048 bit private operations you can do per second.
[21:59.590 --> 22:01.290]  Now, this is just straight maths.
[22:02.490 --> 22:06.470]  It's an exponentiation over a group.
[22:07.230 --> 22:17.190]  And you would think the CPU would pretty much max out, but it turns out that if you get Intel to put researchers onto the problem, they can come up with some nice code in which we got in 101C.
[22:17.410 --> 22:22.790]  And so there's a straight 30% improvement on what should be completely CPU bound just by updating your software.
[22:22.910 --> 22:23.590]  That's quite sweet.
[22:25.510 --> 22:39.830]  Again, if you enable forward secrecy and you use ECDHE, like, for example, Google does, by the way, then the CPU low can go up slightly, but as long as you're running the latest version of OpenSSL, it doesn't go up that much.
[22:40.170 --> 22:46.470]  So here's the ECDHE P256 operations per second, which you can ignore.
[22:46.470 --> 22:49.690]  Here's the additional CPU cost of doing forward security.
[22:50.890 --> 22:53.270]  In 0998, we had, you know, 1500 here.
[22:53.490 --> 22:59.650]  And then we actually dropped in 100, which is unfortunate, but we made the code constant time.
[23:00.070 --> 23:05.570]  So previously, in ECDHE, you have to raise a value to the...
[23:05.570 --> 23:08.310]  Well, it's an elliptic group.
[23:08.510 --> 23:11.090]  You multiply a value by your private key.
[23:11.090 --> 23:17.710]  And in 098, the amount of time that takes depends on your private key, which is kind of unfortunate for side-channel analysis.
[23:17.990 --> 23:21.850]  If the attacker can measure how long you're taking to do it, they can start to guess things about your private key.
[23:22.150 --> 23:25.390]  So we got rid of all that in 100 and made it constant time.
[23:25.490 --> 23:26.510]  So at least use 100.
[23:27.190 --> 23:35.350]  And then for 101C, I decided to deploy this for Google, and this speed was not going to suffice.
[23:35.490 --> 23:39.150]  So I rewrote it with a couple of my colleagues, Bodo and Amelia.
[23:40.930 --> 23:45.510]  And so if you're doing this, you really want to be a 101C, because you want to be this bar and not this bar.
[23:47.510 --> 23:58.910]  And actually, the problem here is that I had previously written code for Dan Bernstein's curve 25519, which is a beautiful curve, whereas P256 is kind of a pile of poo.
[24:00.730 --> 24:03.970]  The NIST, I understand what they were trying to do, but it was short-sighted.
[24:04.110 --> 24:05.890]  And the prime is a huge pain in the neck.
[24:06.030 --> 24:09.550]  And I did things that I shouldn't have done, and I can get this bar up for the next release.
[24:11.770 --> 24:12.390]  But there we go.
[24:12.470 --> 24:15.290]  So you should pay attention to OpenSSL releases.
[24:15.450 --> 24:16.170]  How am I doing for time?
[24:16.430 --> 24:17.490]  Because this is...
[24:17.490 --> 24:18.350]  I don't know how many minutes.
[24:18.350 --> 24:18.790]  That's about right.
[24:18.970 --> 24:23.810]  This was the first half of my talk, which is the public service announcement for SSL.
[24:27.010 --> 24:31.810]  The next part of my talk, I'm going to go on about something we call public key pinning.
[24:32.010 --> 24:35.510]  Now, this is double secret secure bonus points.
[24:36.590 --> 24:44.690]  From this point onwards, I'm basically going on less about practical stuff that you really should do, and more about future stuff.
[24:44.890 --> 24:46.770]  Maybe more interesting, maybe less interesting.
[24:47.030 --> 24:52.090]  But here is a very stylized representation of what a certificate looks like.
[24:52.090 --> 24:54.610]  We have, who is it about?
[24:55.190 --> 24:56.050]  Says who?
[24:56.430 --> 24:57.770]  What's their public key?
[24:58.550 --> 25:01.870]  And where can I fetch the certificate of says who?
[25:03.090 --> 25:04.490]  And that's really all it says.
[25:04.630 --> 25:11.350]  All this is saying is, Barca is saying that the holder of this private key is foo.com.
[25:12.290 --> 25:12.850]  Right?
[25:12.990 --> 25:16.570]  And then we take these, and we put them into what we call a chain.
[25:17.610 --> 25:22.470]  So, at the top here, we have, Barca says things about foo.com.
[25:23.870 --> 25:25.350]  And this could be Barca.
[25:25.710 --> 25:28.990]  And Barca is signed by VeriSign, let's say.
[25:29.910 --> 25:38.250]  Now, if you read the specs, they say that TLS servers, they must send their certificates in the correct order.
[25:38.450 --> 25:40.570]  They must send exactly the right certificates.
[25:41.330 --> 25:44.010]  And they must not include the root because that's silly.
[25:44.090 --> 25:47.230]  The client either already has it and trusts it, or it doesn't and it's not going to work.
[25:48.290 --> 25:52.330]  The reality is that this is always first.
[25:52.490 --> 25:52.910]  That's true.
[25:53.150 --> 25:54.530]  Because if that's not first, nothing works.
[25:54.950 --> 26:00.230]  But as a browser vendor, the reality is that sites include only this certificate.
[26:00.770 --> 26:03.530]  They include this and the intermediate and the root.
[26:03.530 --> 26:07.530]  They include this, the intermediate, some other intermediate they heard about, and two roots.
[26:08.210 --> 26:12.990]  They include this, another leaf certificate for their other web server, multiple intermediates, multiple roots.
[26:13.610 --> 26:20.970]  And they basically go for a drive-by shooting approach where they include about 12 certificates in the hopes that the browsers will be able to pick out the correct ones and just figure it out.
[26:21.190 --> 26:24.250]  And it actually works because the browsers are really nice about that.
[26:24.550 --> 26:26.130]  We completely ignore the standards.
[26:26.390 --> 26:27.990]  All browsers completely ignore the standards.
[26:28.390 --> 26:39.030]  And actually, they simply take the first one and call that the leaf And then just try desperately to build some chain from there to a route they know about using any intermediate they can get their grubby hands on.
[26:40.810 --> 26:42.870]  Now, they will take intermediates.
[26:42.970 --> 26:44.690]  They will cache them from prior connections.
[26:44.990 --> 26:48.230]  They will download them over HTTP if they have to.
[26:49.450 --> 26:55.510]  They will just take all the other certificates that the server sends, put them into a big pool and just try to weave some thread through it.
[26:56.290 --> 26:59.170]  And what this means is that most of the time it works.
[26:59.970 --> 27:09.210]  However, what it also means is that as a website operator, you have no idea what the hell kind of chain some browser is going to make for your website.
[27:09.530 --> 27:13.490]  It's almost certainly not going to be the one you presented to it, even if you get it right.
[27:14.850 --> 27:26.010]  And then just to make things even more wonderful, this is an X.509 distinguished name, which was designed by the sorts of people who like to put things into boxes.
[27:27.250 --> 27:35.010]  And it was honestly designed to some massive hierarchical global namespace where everything in the world would be named by this distinguished name.
[27:35.570 --> 27:38.050]  And everything that's named would be unique.
[27:38.470 --> 27:40.630]  Now, obviously that didn't really work out.
[27:40.830 --> 27:46.770]  But in addition to that, CAs will frequently reissue certificates with exactly the same name, but they're different certificates.
[27:47.230 --> 27:52.770]  They will do so in order to update the expiry time, if the certificate is going to expire.
[27:53.150 --> 27:57.810]  They will do so because they want to reissue it with a new hash function.
[27:58.050 --> 28:00.130]  They will do so because they just want to put stuff in there.
[28:00.510 --> 28:05.250]  And sometimes they will do so and there is no difference between the two certificates except the serial number.
[28:06.250 --> 28:07.670]  Why did... I don't know.
[28:08.550 --> 28:13.890]  Some CAs issue certificates that attest to the fact that the certificate is invalid for the use of a CA.
[28:14.310 --> 28:18.770]  And then they reissue because obviously a bunch of clients blew up and said, what the hell?
[28:19.370 --> 28:24.930]  Some CAs issue key usages that say this CA certificate can only be used for key agreement and not for signing certificates.
[28:25.190 --> 28:26.390]  And so they reissue those too.
[28:27.030 --> 28:37.870]  And so even if the browsers didn't desperately try to thread some path through everything they can find, CA's issue multiple versions of routes and intermediates.
[28:38.070 --> 28:43.370]  So there is no way that you can possibly know what chain a browser is going to build for your website.
[28:44.670 --> 28:59.450]  Now, what we wanted to do about two years ago was that for Google and Chrome, and sort of Android and whichever browsers want to follow along with us, we wanted to say that we know the certificates for Google.com are issued by our CAs.
[28:59.870 --> 29:03.510]  We don't want the browsers to accept just any old CA.
[29:06.130 --> 29:09.250]  And so we said, well, we should build in hash certificates.
[29:10.270 --> 29:16.010]  And then we went, oh, wait, that doesn't work because we can't hash over these certificates because we have no idea what they're going to be.
[29:17.070 --> 29:23.490]  The only thing we can roughly do is this subject public key info, which is the X.509 name for public key.
[29:24.130 --> 29:31.770]  We can say that whatever ends up here, its public key must be valid for validating the signature on this certificate.
[29:32.550 --> 29:33.830]  So maybe that works.
[29:34.590 --> 29:36.930]  And, you know, whatever ends up here, it must assign the intermediate.
[29:37.950 --> 29:45.910]  Now, maybe the actual, if this was the chain we intended, maybe another intermediate came over here and actually redirected the chain to a completely different route.
[29:46.450 --> 29:50.710]  That's a possibility, but we just had to say, well, screw it, because we can't do anything about that.
[29:51.890 --> 30:03.230]  So what we have done is something that we call public key pinning, which says that when we validate a site, we require that in the chain somewhere is one or more of a number of known public keys.
[30:04.690 --> 30:12.210]  So the most secure thing you can do is you can say, my public key, the public key I hold that no one else has, must be in the chain.
[30:14.690 --> 30:19.770]  And that obviously is the most secure, because nobody else should have, you know, the private key corresponding to it.
[30:21.150 --> 30:26.930]  The issue being that we reissue our certificates on, you know, almost a weekly basis, we rotate our certificates.
[30:27.290 --> 30:29.670]  And so our public keys change every time we do that.
[30:30.310 --> 30:34.830]  Just as a matter of hygiene, we want to get rid of the old keys as fast as possible and turn them over.
[30:36.410 --> 30:40.710]  And also, if you do that, you've got to be a little bit worried that you're going to lose your private key.
[30:41.310 --> 30:41.670]  Right?
[30:41.750 --> 30:42.790]  It's kind of a hell of a trade off.
[30:42.890 --> 30:46.790]  You can tell the whole world, my server will always be signed by this public key.
[30:46.890 --> 30:54.230]  But if you lose the private part, then your whole website's right down with no very good plan of getting it ever back up.
[30:55.370 --> 31:07.230]  So rather than doing that, when public key pinning, we want to, we generally say for Google at least, we'll take this intermediate, which we happen to control because we're huge and we can do that.
[31:08.070 --> 31:12.590]  But we'll take this intermediate and this route, and we'll say that for Google.com, you've got to be...
[31:12.590 --> 31:15.230]  You've got to either be signed by this route or this intermediate.
[31:16.350 --> 31:17.910]  Remember, we control this in our case.
[31:18.070 --> 31:23.010]  So we can go to a different CA and say, please cross sign our intermediate and we can change CAs.
[31:23.170 --> 31:28.290]  So we are not binding ourselves into one CA for the rest of the time, because that would be bad, because then it'll ask for money.
[31:31.350 --> 31:40.370]  And, you know, there is a possibility that should three very specifically sized meteorites strike at three locations on Earth, we could perhaps lose this intermediate.
[31:40.790 --> 31:47.290]  But then we can go to our CA, our current one, and say, please give us a new certificate, and that's okay, because we built their public key in as well.
[31:48.810 --> 31:56.570]  And so although, you know, not perfect, we're trusting our CA, we're trusting someone who is not us, they have a key to sign for us.
[31:56.570 --> 32:00.670]  It's still a heck of a lot better than trusting the hundreds of CAs out there.
[32:02.090 --> 32:03.870]  And we did this, and we deployed it.
[32:06.110 --> 32:08.930]  Kind of, it turns out, a very, very fortuitous time.
[32:09.030 --> 32:09.670]  We didn't know this.
[32:10.390 --> 32:18.270]  But it turns out we deployed it probably in between the Iranian government testing their man in the middle attack, and the Iranian government deploying it.
[32:18.590 --> 32:20.450]  So when they tested it, it worked.
[32:20.630 --> 32:22.130]  And when they deployed it, it didn't.
[32:30.070 --> 32:33.070]  And so that was, that then became known as the DigiNotar case.
[32:33.790 --> 32:37.690]  Where I got an email, one, I can't remember which day of the week it was, morning.
[32:37.930 --> 32:39.850]  I think it was a Monday morning, because it was a hell of a week.
[32:40.690 --> 32:49.970]  With a screenshot from one of the very few technically competent bilingual, liberally minded people in Iran, saying, I suddenly can't use Google.
[32:50.150 --> 32:53.090]  I get, you know, I get this great big red screen.
[32:53.090 --> 32:55.810]  And because it's HSGS, there is no proceed button.
[32:56.730 --> 32:58.410]  I get this great big red screen.
[32:58.590 --> 33:01.470]  And I used OpenSSL, and I dumped the certificate chain.
[33:01.850 --> 33:02.450]  Thank you.
[33:02.730 --> 33:03.790]  Thank you for doing this.
[33:04.670 --> 33:07.390]  Thank you for knowing to do that, and not email me a screenshot.
[33:10.830 --> 33:14.810]  And I looked at this, and my colleague in Zurich looked at this, and went, oh, shit.
[33:16.010 --> 33:17.790]  And so that was a DigiNotar week.
[33:18.110 --> 33:20.890]  And for those who don't know, DigiNotar is now an ex-company.
[33:21.810 --> 33:22.550]  That was it.
[33:22.650 --> 33:22.930]  They're dead.
[33:23.070 --> 33:23.470]  They're no more.
[33:28.960 --> 33:30.520]  And so public key pinning.
[33:30.740 --> 33:48.020]  If you are the sort of website which gets these sorts of things done to them, which includes us, which includes at the moment Tor and Twitter, then email me and say, hey, I was targeted by this government, or I was in DigiNotar set, or something along those lines,
[33:48.160 --> 33:52.620]  to say I'm important enough, and I will work with you to publicly pin your website in Chrome.
[33:53.280 --> 33:57.920]  I think Firefox is sniffing it, taking our list, and building it into Firefox, too.
[33:59.780 --> 34:09.500]  If you are not one of those websites, and I'm afraid I can't promise to do this for everyone, because it takes a whole bunch of time and hand-holding to set this up.
[34:11.040 --> 34:12.740]  And for HSTS, I'll do it for anyone.
[34:13.000 --> 34:15.380]  We have splendidbacon.com on the HSTS list.
[34:15.520 --> 34:21.180]  But the public key pinning, it takes me a bunch of time, so I'll only do it for the sorts of sites which I think are worthwhile doing it for.
[34:21.960 --> 34:30.540]  But if you are not one of those sites, there will also be methods in the future to set HTTPS headers, just like the strict transport security header, to set your public key pins.
[34:31.040 --> 34:33.980]  And this is an enormous foot gun, right?
[34:34.100 --> 34:39.400]  You can take your site offline for Chrome and Firefox users forever, if you get this wrong.
[34:40.380 --> 34:42.020]  And so it's a little bit terrifying.
[34:42.380 --> 34:44.260]  But we will be supporting that header.
[34:44.400 --> 34:46.280]  I think it's already in the current Chrome versions.
[34:46.400 --> 34:50.200]  We may be supporting Moxie's TAC proposal, which is another way of doing the same thing.
[34:50.460 --> 34:54.380]  But for super secure bonus points, you can do this.
[34:54.780 --> 34:56.400]  But do HSTS first.
[35:00.720 --> 35:01.820]  Next up, Dane.
[35:02.900 --> 35:04.500]  I can't remember what Dane stands for.
[35:05.240 --> 35:11.320]  But Dane is the ITF effort for going, holy crap, DNSSEC got deployed.
[35:11.480 --> 35:12.240]  We should do something with it.
[35:13.880 --> 35:18.800]  For those who don't know, DNSSEC has been going for about 15 years now, in terms of various designs.
[35:19.860 --> 35:30.500]  And then recently, in the past couple of years, mostly, I think, thanks to Dan Kaminsky, Roots and a bunch of GTLDs have deployed DNSSEC, which is a way of signing DNS entries.
[35:31.480 --> 35:40.420]  And Dane is a way of saying, well, we should put stuff in DNS, which, you know, like certificate fingerprints and public key fingerprints, so that we can use this trust mechanism.
[35:42.600 --> 35:44.160]  DNSSEC is actually a kind of a...
[35:44.860 --> 35:47.660]  It's very complicated, but it's not nearly as complicated as X.509.
[35:48.140 --> 35:49.520]  And it's also federated.
[35:49.760 --> 35:51.180]  So, you know, it's...
[35:51.180 --> 35:57.100]  If you get your key set up, for example, .com, it doesn't matter that you have 10,000 host names in corp.example.com.
[35:57.240 --> 36:00.700]  You don't have to go to a CA and try and get wildcard search and search for all of these.
[36:00.960 --> 36:03.340]  It works like DNS does, and we quite like that.
[36:03.340 --> 36:07.780]  It's also time-based revocation, short-lived signatures.
[36:08.120 --> 36:09.300]  And maybe I'll get onto that later.
[36:09.740 --> 36:13.680]  But short-lived signatures work an awful lot better than our X.509 revocation mechanisms.
[36:13.900 --> 36:15.960]  So we quite like DNSSEC as a PKI.
[36:17.660 --> 36:23.580]  And Dane is saying, well, we can put hashes of certificates in DNS, and you can check it with DNSSEC.
[36:24.120 --> 36:25.120]  Could you trust them?
[36:25.900 --> 36:30.120]  Which is interesting, because most CA certificates are what we call DV.
[36:30.840 --> 36:32.540]  DV, domain-validated certificates.
[36:33.000 --> 36:39.960]  The CA is saying, I've sent an email to this domain, or I've looked up a file on this web server.
[36:40.320 --> 36:41.720]  And, you know, it's not much, right?
[36:41.900 --> 36:43.740]  That relies entirely on DNS.
[36:44.000 --> 36:46.700]  If someone can subvert DNS, they can get CA certificates.
[36:47.060 --> 36:50.740]  It's not as if by trusting DNS, we're going, you know, we're trusting any more.
[36:50.840 --> 36:52.300]  We're not increasing our attack surface.
[36:54.160 --> 36:55.280]  So this is intriguing.
[36:55.780 --> 37:00.820]  The problems being that the Internet is horribly, horribly broken, and we can't do DNSSEC lookups.
[37:01.880 --> 37:05.400]  I did a test where we tried to do DNS TXT lookups.
[37:06.060 --> 37:08.320]  We did them for sites that we were connecting to.
[37:08.480 --> 37:10.660]  So we've just done a valid A lookup for them.
[37:10.820 --> 37:12.760]  We've just connected to them, so they're clearly up.
[37:13.540 --> 37:16.180]  And we tried to do a TXT lookup for that same name.
[37:16.400 --> 37:22.920]  Now, what we expect is a response that, or possibly a real response with data, but mostly a response that says, there's no such record.
[37:23.740 --> 37:27.020]  What we actually get about 3.5% of the time is absolutely nothing.
[37:27.760 --> 37:31.920]  Because firewalls block anything that's not an A record, or maybe a quad A record if you're lucky.
[37:32.700 --> 37:34.700]  And 3.5% of...
[37:34.700 --> 37:38.160]  I don't know what our current usage numbers are, but for Chrome, hundreds of millions.
[37:38.280 --> 37:46.940]  3.5% of people is, you know, sort of New York State in terms of number of people that we would be breaking if we tried to do this sort of thing.
[37:46.940 --> 37:49.720]  Because we can't allow it to fail.
[37:49.880 --> 37:53.060]  If it's a security mechanism, it has to be hard fail.
[37:53.180 --> 37:57.280]  Otherwise, the attacker can simply block it, and say, oh, no, nothing here.
[37:57.440 --> 37:58.300]  And it's completely useless.
[37:59.900 --> 38:07.880]  So, given that it's completely impossible to deploy this on the modern Internet, I've tried to go for the next best thing, which is in Chrome and has been for a while.
[38:09.480 --> 38:17.380]  Rather than have the browser do the DNS lookup, you can take these DNS records, which are signed by DNSSEC, and you can stick them in a self-signed certificate.
[38:18.320 --> 38:22.620]  There is no reason, once things are signed, that you have to get them over port 53.
[38:23.220 --> 38:27.100]  As long as they're signed, we can just check the signatures, and we can get these records any which way.
[38:27.180 --> 38:30.980]  As long as you can get them to us, we can check them and validate them and trust them.
[38:31.460 --> 38:42.120]  So, at the moment, the record you need to use is some bastard hacked up CAA record, which I made up, because the Dane RFC is currently in the RFC editor's queue and hasn't been published yet.
[38:42.540 --> 38:55.620]  Once the Dane RFC is published, you will be able to, with your DNSSEC secured zone, set up a Dane record, grab the DNS records and their signatures, stick them in a self-signed certificate, give it to Chrome, and it will be valid.
[38:56.020 --> 38:57.460]  It won't be valid by anybody else.
[38:57.900 --> 38:59.140]  Not a lot I can do about that.
[38:59.320 --> 39:14.970]  So, this is only really interesting to either enterprises that deploy Chrome largely internally, and want to sign their 100,000 desktops in their corp namespace, which CAs can't reach and so forth, and they don't want to give wildcards out to all of these hosts.
[39:15.950 --> 39:29.570]  Or, if you currently run a site with a self-signed certificate, because f*ck the CAs, man, f*ck the man, we don't want to pay no one, which apparently there's an awful lot of sites out there, then you can get a Dane certificate, and it will work at least in Chrome,
[39:29.610 --> 39:32.290]  and it won't be any worse in all the other browsers than what you have now.
[39:35.930 --> 39:41.330]  So, that's as far as I go for slides, and I have more than enough material to prattle on for the rest of the hour.
[39:41.570 --> 39:44.610]  But is there anyone here who wants me to talk about something in particular?
[39:44.750 --> 39:47.750]  For example, I can talk about certificate transparency, I could talk about revocation.
[39:48.050 --> 39:50.350]  Those are the two big topics I was going to go on about.
[39:52.250 --> 39:55.610]  TLS 1.2, I've seen a bunch of issues, so there's firewalls.
[39:55.990 --> 39:56.530]  Oh, yes.
[39:56.750 --> 39:56.810]  Okay.
[39:56.990 --> 39:58.250]  So, TLS 1.2.
[40:00.090 --> 40:03.250]  A long time ago, in the midst of history, there was SSL v2, and it was crap.
[40:03.530 --> 40:07.270]  And then there was SSL v3, which came out, I'm not entirely sure when.
[40:07.650 --> 40:12.390]  And then the IETF took the protocol and decided not only to rename it, but also to renumber it.
[40:12.810 --> 40:14.650]  So, then was born TLS 1.
[40:14.950 --> 40:18.550]  So, TLS 1 is, in fact, a greater number than 3.
[40:20.450 --> 40:27.310]  And this, back when we had the UI options, we had two UI options, enable SSL 3, enable TLS 1.
[40:27.630 --> 40:31.930]  Everyone who wanted to be secure said, oh, I don't want version 1, I'll only use version 3.
[40:32.110 --> 40:33.270]  And they turned off TLS 1.
[40:34.770 --> 40:39.570]  But TLS 1 was published, I don't know, 2001?
[40:40.110 --> 40:41.350]  11 years ago or so?
[40:43.990 --> 40:46.090]  And since then, there have been two revisions.
[40:46.330 --> 40:51.490]  We've had 1.1 and 1.2, which have seen very, very little adoption because no one really cares too much about them.
[40:52.130 --> 40:56.670]  And we frankly still haven't got over the firewall problems of SSL v3 versus TLS 1.
[40:57.070 --> 41:08.730]  But, thanks to somebody sponsoring the OpenSSL Foundation to implement TLS 1.2 in the most recent version of OpenSSL, we are starting to see it deployed.
[41:10.610 --> 41:12.350]  We are also starting to see it deployed.
[41:12.870 --> 41:16.030]  And this may have been the motivation for whoever paid OpenSSL to do it.
[41:16.610 --> 41:19.630]  Because the NSA loves something they call Suite B.
[41:20.510 --> 41:21.650]  Suite A you don't get.
[41:21.770 --> 41:23.190]  Suite A is what they really want.
[41:23.690 --> 41:24.690]  But it's classified.
[41:25.010 --> 41:27.490]  So, Suite B is what the proletariat gets.
[41:29.050 --> 41:34.850]  And the NSA has been pushing for over a decade now for everyone in the world to use Suite B.
[41:35.090 --> 41:41.730]  And Suite B, although it has options for things like RSA, they are very clear that they don't like it very much.
[41:41.730 --> 41:47.910]  And really what you should be doing is ECDHE, ECDSA, AES128, ECM.
[41:48.090 --> 41:49.370]  Which is a hell of a lot of letters.
[41:50.050 --> 41:52.250]  But what it means is that you need TLS 1.2.
[41:54.130 --> 41:56.230]  So, Google servers support TLS 1.2.
[41:56.410 --> 41:58.310]  And iPhones support TLS 1.2.
[41:58.530 --> 41:59.630]  And that was exciting.
[41:59.830 --> 42:05.510]  Because then suddenly all the iPhones in the world, all the iPhone apps were talking TLS 1.2 to Google.
[42:05.710 --> 42:08.850]  And all the firewalls which have been built by Muppets over the past decade.
[42:10.430 --> 42:13.290]  Which pattern match on the version number, all broke.
[42:16.670 --> 42:21.610]  And I just about managed to avoid rolling back 1.2 support at Google.
[42:22.350 --> 42:24.390]  We got a lot of complaints when we rolled it out.
[42:24.550 --> 42:26.870]  Because when we were only version 1, it was fine.
[42:26.870 --> 42:29.330]  Because all the iPhones in the world would only talk 1 to us.
[42:29.350 --> 42:31.550]  And all these firewalls would go, OK, I recognize this.
[42:31.950 --> 42:35.570]  And when we rolled out 1.2, suddenly all the iPhones could talk to us in a more secure manner.
[42:35.630 --> 42:36.670]  And the firewalls freaked out.
[42:38.570 --> 42:41.830]  And we got a lot of, well, quite a lot of pressure to roll it back.
[42:42.210 --> 42:46.230]  But I said, well, if we roll it back, then what is the path for ever going forward ever again?
[42:46.370 --> 42:47.630]  How is this not the end of the road?
[42:49.110 --> 42:50.690]  And since it would have been the end of the road.
[42:50.970 --> 42:54.030]  Since if we had rolled it back, there would never be any pressure.
[42:54.250 --> 42:57.210]  And no one else in the world would ever deploy TLS 1.2.
[42:57.590 --> 42:58.990]  Because if we can't pull it off.
[43:00.650 --> 43:03.270]  So we still support 1.2.
[43:03.410 --> 43:07.770]  And I understand this has caused an awful lot of problems for an awful lot of firewall vendors who have had to patch their buggy crap.
[43:08.030 --> 43:08.710]  I'm sorry.
[43:13.250 --> 43:14.410]  So that happens.
[43:15.630 --> 43:17.410]  Chrome, TLS 1.1.
[43:18.110 --> 43:20.590]  We have TLS 1.1 supporting Chrome now.
[43:21.970 --> 43:30.190]  And we, all browsers, when they get any kind of handshake error or sometimes even a connection reset, will downgrade to SSL v3.
[43:30.190 --> 43:31.970]  Because there are...
[43:31.970 --> 43:36.810]  About 1% of all servers cannot do TLS version negotiation.
[43:37.390 --> 43:40.150]  They just won't accept even the negotiation.
[43:40.450 --> 43:43.610]  They will simply drop any connection that is not compatible with them.
[43:43.970 --> 43:46.610]  And SSL v3 is the absolute baseline we can possibly do.
[43:46.710 --> 43:47.370]  We turn off...
[43:47.370 --> 43:48.230]  We don't offer compression.
[43:48.370 --> 43:49.110]  We don't offer SNI.
[43:49.190 --> 43:51.650]  We don't do any of these things that can possibly freak out a server.
[43:52.410 --> 43:54.850]  So we've always had this fallback for SSL v3.
[43:54.930 --> 44:00.090]  And the hope was that at least maybe the fallback wouldn't get any worse with TLS 1.1.
[44:00.090 --> 44:02.470]  That does not appear to be the case, I'm afraid.
[44:03.050 --> 44:11.050]  Not only are we having to botch the record header version number to only ever say one, we are having to add yet another fallback.
[44:11.650 --> 44:13.890]  Chrome has never fallback on connection reset.
[44:14.130 --> 44:17.950]  But for TLS 1.1, we now have to fallback for connection reset to get through these firewalls.
[44:18.750 --> 44:21.510]  So the answer is, yeah, it's a huge problem.
[44:23.070 --> 44:26.210]  And while we have these fallbacks, we can never depend on...
[44:26.750 --> 44:29.890]  We can never depend on any security feature of any future version of TLS.
[44:30.090 --> 44:36.630]  Because if the attacker can simply send a reset packet and get us to downgrade the version, then that's not secure.
[44:37.090 --> 44:42.970]  And that is something I'm going to have to do something about because elliptic curve forward security doesn't work with SSL v3.
[44:43.210 --> 44:50.170]  So when you cause Chrome to downgrade to SSL v3 or any other browser, forward security on Google websites suddenly switches off.
[44:52.130 --> 44:56.130]  And for entirely personal reasons, I do not want to be...
[44:57.070 --> 45:00.190]  I mean, I don't... I don't go anywhere terribly dodgy in the world.
[45:00.350 --> 45:06.490]  But some of our employees have had unfortunate situations where the local authorities have said, we would like Google to do something.
[45:06.790 --> 45:14.910]  And given that I have the private keys to lots of things that lots of nasty people would want, I don't want people not to be using forward secrecy.
[45:15.110 --> 45:17.510]  I want to be able to say, there's no point torturing me.
[45:17.610 --> 45:18.550]  I can't give you the keys.
[45:22.150 --> 45:23.910]  You can't do elliptic curve to femoral...
[45:25.750 --> 45:26.650]  No, we don't.
[45:26.750 --> 45:27.690]  We could switch it on.
[45:28.010 --> 45:32.490]  But the problem is that we have to worry about the DDoS surface.
[45:32.490 --> 45:41.110]  So if we offer to do that, if we offer to do, say, 1K, then if someone DDoSs us, we have to be able to do that.
[45:42.550 --> 45:43.390]  I didn't...
[45:43.390 --> 45:45.190]  I have not got that through operations, folks.
[45:45.470 --> 45:52.170]  I think it is easier to fix our client to somehow get around this version rollback than to offer that.
[45:52.370 --> 45:53.250]  I rather...
[45:53.250 --> 45:54.030]  Yeah, it's possible.
[45:54.190 --> 45:54.450]  You're right.
[45:56.310 --> 45:58.550]  A 1K exponentiation is fairly expensive.
[45:58.770 --> 46:00.250]  I'd have to throw them something.
[46:00.250 --> 46:06.890]  I'd have to do enough work to make all the rest of this fast enough such that the overall speed decrease was not significant.
[46:07.350 --> 46:11.090]  And I've got to move Google to 2048-bit keys.
[46:11.570 --> 46:16.330]  And that's going to cost me a lot of my goodwill budget when I suddenly drop that on them.
[46:17.690 --> 46:20.090]  So my goodwill budget is...
[46:20.090 --> 46:21.570]  it's committed already.
[46:25.720 --> 46:27.040]  Yes, I'm very...
[46:27.640 --> 46:30.500]  I mean, I believe the jump to 2048 was too big.
[46:31.840 --> 46:33.080]  I wish it had been smaller.
[46:33.420 --> 46:38.160]  But NIST have said that by the end of 2013, blah, blah, blah, it shall be 2048.
[46:38.580 --> 46:41.240]  And given that we have large numbers of...
[46:41.240 --> 46:44.780]  of the sorts of people who go through NIST guidelines and say, do you meet these?
[46:45.880 --> 46:46.180]  Right?
[46:46.640 --> 46:48.540]  Then we jump to 2048.
[46:51.520 --> 46:52.000]  Okay.
[46:52.680 --> 46:55.420]  So for time-wise, shall I pass along about revocation or CT?
[46:55.420 --> 46:56.520]  I've just...
[46:56.520 --> 46:57.360]  I've just bitched.
[46:57.500 --> 47:00.100]  So in the last few minutes, I shall go on about CT.
[47:00.460 --> 47:01.360]  This is more optimistic.
[47:04.520 --> 47:16.200]  So keep in mind as I say this, I've said all these things about how you shouldn't worry about CAs because your website sucks so badly because of SSL stripping and mixed scripting and cookies that you don't even get up to this level.
[47:16.640 --> 47:18.680]  So that's the thing you need to remember.
[47:20.260 --> 47:33.180]  But if you do get up to this level, then you can concern yourself with the fact that there are hundreds of organizations with CA signing power and we don't even know how many there are because companies occasionally give it out and, you know, they don't...
[47:33.180 --> 47:35.040]  well, they actually very often give it out and don't tell anyone.
[47:36.960 --> 47:45.240]  The idea of certificate transparency, which was a proposal put forward by Ben, Laurie and myself, is to be as nice to the CAs as possible.
[47:45.460 --> 47:48.420]  All we want from them is we want to know what the hell they're signing.
[47:48.640 --> 47:54.560]  We want to say that if you are making a public assertion about some website, that public assertion should be public.
[47:56.200 --> 48:05.880]  Because, you know, given that I sort of manage and deeply involved in Google serving, I am not confident that I know all the certificates out there issued for Google.com.
[48:06.260 --> 48:11.600]  In an organization as large as us, we do occasionally have panics where someone says, what the hell is this certificate?
[48:12.080 --> 48:14.380]  And everyone goes, Jesus Christ, where did it come from?
[48:14.540 --> 48:17.180]  And, you know, eventually I say, no, it's this obscure thing, don't worry.
[48:17.680 --> 48:22.320]  There is no way, even we can't keep track of all the certificates issued for us.
[48:22.460 --> 48:29.520]  There is no way if you are some smaller site and some small CA issues a certificate for you, you never find out.
[48:30.200 --> 48:35.020]  So we would like to say that all certificates, if they're for public websites, should be public.
[48:35.300 --> 48:39.660]  And therefore, if I am foo.com, I can say, what are all the certificates issued for foo.com?
[48:39.660 --> 48:46.800]  And if suddenly something pops up, signed by, did you know, you can go, whoa, wait, that's interesting.
[48:47.480 --> 48:50.180]  It's only retroactive, but nonetheless, it would be really nice to know.
[48:51.820 --> 48:59.300]  So, we can implement this using something called an append-only data structure, which is a cryptographic thing that we can, we can build reasonably.
[48:59.580 --> 49:03.560]  If you are a CA, we trust you, and we have to trust you because we trust you to go verify these certificates.
[49:03.560 --> 49:06.100]  But in the append-only data structure, we don't have to trust you.
[49:06.160 --> 49:18.340]  We can have the clients validate the things they see, and we can have all manner of cross-checks and auditors to make sure that everything that you publish stays published, and we can make sure the clients don't trust anything that's not published.
[49:18.420 --> 49:19.460]  This is a solvable problem.
[49:20.400 --> 49:28.760]  The major problem is that we need some way to get some proof of publication in a certificate to the client so that we can check it.
[49:30.960 --> 49:38.140]  And we need to do this without breaking either most of the clients or most of the servers in the world because either of those things makes it undeployable.
[49:38.900 --> 49:42.780]  The only thing that we can sort of wedge into all the servers in the world is their certificate.
[49:43.020 --> 49:45.880]  It's the only sort of configuration knob that we can twiddle.
[49:45.980 --> 49:52.000]  We can make things as easy as possible for admins, but if we say you have to upgrade your server, then that's not going to happen.
[49:52.160 --> 49:58.320]  I get bug reports from people running servers from 13 years ago that haven't been touched, literally from the last millennium.
[49:59.880 --> 50:04.140]  So if we're going to force everyone in the world to do this, we have to do it without them upgrading their server.
[50:04.600 --> 50:08.280]  So we said, well, can we wedge something in a certificate somewhere?
[50:09.000 --> 50:11.220]  And there were two places where you can look to do this.
[50:11.340 --> 50:23.140]  You can look to send additional certificates, you know, bullshit meaningless certificates that because browsers, you know, as I said, try to weave this path through the certificate miasma will ignore.
[50:24.140 --> 50:32.560]  and we said, oh, there's also this one place in certificates, the signature algorithm parameters which is unused and is outside of the signed area so we can stuff anything we want in there.
[50:32.960 --> 50:37.860]  And I ran a couple of tests and we said, how compatible with clients are these two things?
[50:38.120 --> 50:40.160]  And it turns out neither of them are very compatible.
[50:40.420 --> 50:44.800]  They break enough clients doing either of these things that it's kind of a no-go.
[50:45.500 --> 50:56.400]  So, now, Ben is talking to CAs and Ben is of the opinion that we can get the CAs to cooperate in this and put a proof of publication in the signed area of a certificate.
[50:56.800 --> 51:09.380]  And then we can set up these certificate logs where you can go and you can say, you know, what certificates exist for foo.com or you can go to some service that says, please alert me if a new certificate appears for foo.com.
[51:09.820 --> 51:12.480]  This would be a significant step up from where we are now.
[51:14.840 --> 51:17.740]  Ben is still very positive about this and believes the CAs will cooperate.
[51:18.400 --> 51:19.700]  I am perhaps less so.
[51:20.600 --> 51:30.560]  But we're still going to try and we're still going to try and, you know, scare up some publicity and possibly some support and possibly some public shaming of CAs.
[51:30.780 --> 51:33.840]  And I think there will be a Google security blog post coming.
[51:34.460 --> 51:37.680]  I think it would have happened by now were it not that everyone is on vacation right now.
[51:38.760 --> 51:40.980]  So that's CA and, sorry, CT.
[51:41.220 --> 51:44.220]  And in the last seven minutes, I'll go for any more questions.
[51:56.790 --> 51:58.910]  So the question is, what about convergence?
[51:59.330 --> 52:00.790]  Convergence is one of Moxie's projects.
[52:02.450 --> 52:10.390]  Even though I'm going to slightly bash it, I should say that, you know, Moxie is a pal and Moxie does more work than almost anyone in trying to do this thing and actually writes code.
[52:10.550 --> 52:12.170]  I respect Moxie massively.
[52:13.250 --> 52:14.130]  But convergence.
[52:14.950 --> 52:20.590]  Convergence involves the browser when verifying a certificate, going off and checking with a bunch of people, is the certificate valid?
[52:20.590 --> 52:22.030]  Do you agree with it?
[52:22.470 --> 52:28.490]  And where agree is not precisely defined in order to allow some flexibility, but it could mean, like, if you make a connection, do you see the same one?
[52:30.370 --> 52:34.890]  The problem with this is, A, browsers cannot make requests synchronously when verifying certificates.
[52:35.050 --> 52:35.670]  It breaks the world.
[52:36.310 --> 52:45.010]  If you are behind some hotel, you know, capital portal login, then you have to be able to validate the certificate without talking to anybody else, because it won't let you talk to anybody else.
[52:45.010 --> 52:47.290]  And we can't break every hotel network in the world.
[52:48.210 --> 52:50.970]  The second problem is that these...
[52:51.890 --> 52:53.370]  He calls them notaries, right?
[52:53.670 --> 52:55.130]  These notary servers...
[52:55.130 --> 52:57.090]  Let's imagine that we are going to deploy it in Chrome.
[52:57.470 --> 53:03.670]  So we have to pick some notaries which are going to be contacted every single time a Chrome user anywhere validates a certificate.
[53:04.030 --> 53:06.610]  Well, that's the kind of DDoS flood that will take out almost anything.
[53:07.330 --> 53:13.410]  And given that if they go down, every Chrome everywhere stops working, then we have quite a strong incentive to be running them ourselves.
[53:13.570 --> 53:14.570]  In fact, it's the only option.
[53:14.570 --> 53:15.830]  We'd have to run them all ourselves.
[53:16.370 --> 53:21.130]  And so Convergence turns into a Chrome phone's home to Google to validate every certificate.
[53:21.510 --> 53:23.910]  And it breaks captive portals.
[53:24.310 --> 53:28.890]  So from a piracy point of view, the idea that Chrome phone's home to validate every certificate doesn't fly.
[53:30.990 --> 53:31.470]  Most...
[53:31.470 --> 53:36.530]  Everything I've built so far in my career at Google has managed to avoid me carrying a pager.
[53:37.130 --> 53:38.270]  This is very important.
[53:38.810 --> 53:41.770]  Anything which involves me having to carry a pager is kind of a no-go.
[53:42.410 --> 53:44.170]  Everything so far, I can...
[53:44.170 --> 53:46.650]  It can break completely and I can wait four days.
[53:46.910 --> 53:51.770]  Four days without touching it and nothing will go horribly wrong, which means that I can have a long weekend and come in on the Monday.
[53:52.790 --> 53:55.190]  And so that is also a severe negative for me.
[53:55.550 --> 53:57.910]  So, no, Convergence is not something we're pursuing right now.
[54:00.170 --> 54:00.570]  Sure.
[54:00.570 --> 54:01.530]  How can you see CAs as well?
[54:07.240 --> 54:08.940]  How can you really trust them?
[54:09.600 --> 54:12.120]  The question is, how can you really trust CAs?
[54:12.260 --> 54:15.880]  And the answer is, you kind of have to because we've got no other option.
[54:17.500 --> 54:17.700]  Right.
[54:17.980 --> 54:19.180]  CT is our best attempt.
[54:19.920 --> 54:21.300]  We're trying, but it's really tough.
[54:23.140 --> 54:23.240]  Yeah.
[54:25.580 --> 54:26.060]  Sure.
[54:37.180 --> 54:43.920]  So, the question is, with public key pinning, if you set it in a header, what about the first run problem where the client doesn't have the pin?
[54:44.580 --> 54:46.220]  The major answer is build it into the browser.
[54:47.300 --> 54:48.520]  Otherwise, no, there isn't an answer.
[54:48.640 --> 54:51.220]  That's the weakness of not building it into the browser.
[54:51.440 --> 54:52.200]  That's why we built it in.
[54:58.930 --> 55:00.890]  Are client-side certificates going anywhere?
[55:00.890 --> 55:01.370]  No.
[55:29.830 --> 55:40.110]  So, is the problem, I run an HTTPS site and I need to include JavaScript which is only served over HTTP, or is it, I'm including JavaScript from this ad network and therefore, I have to trust them?
[55:40.810 --> 55:41.270]  It's both.
[55:42.790 --> 55:43.250]  Okay.
[55:43.370 --> 55:50.970]  So, if you're on an HTTPS site and you need to include some JavaScript say from an app network and it's only served over HTTP, that's a real pain in the backside.
[55:51.490 --> 55:51.830]  I'm sorry.
[55:53.210 --> 56:07.090]  Well, given that I work for an advertising company which may have been guilty of this at times in the past, I can tell you that there is a significant contingent of people within the company screaming that this is a problem and things are sort of moving but I have nothing to announce.
[56:07.470 --> 56:13.930]  The second one is that if you're on an HTTPS website and you source JavaScript from this ad network, you are vulnerable to them.
[56:14.210 --> 56:14.490]  Yep.
[56:20.230 --> 56:20.670]  Yep.
[56:24.270 --> 56:24.670]  Sorry.
[56:34.920 --> 56:37.440]  So, you're saying, what if the server doesn't respond to HTTP?
[56:37.780 --> 56:39.820]  It doesn't actually buy you much because the attacker will.
[56:40.780 --> 56:43.440]  The attacker in the network can respond to HTTP even if your server doesn't.
[56:43.600 --> 56:46.140]  What you should do is you should serve a 301 redirect.
[56:46.400 --> 56:47.440]  301s can be cached.
[56:48.260 --> 56:54.160]  So, even if you don't have HSTS, which you should have, if the 301 is cache, at least your users have a fighting chance.
[56:54.860 --> 56:59.820]  But yeah, not serving HTTP doesn't buy you anything as far as I know because the attacker can fabricate it.
[57:00.360 --> 57:02.140]  I think this gentleman is waiting for a while.
[57:02.700 --> 57:03.320]  No, he's done.
[57:09.110 --> 57:19.550]  Simply because we update our certs and keys that often and simply keeping the old key around would be one extra place to keep it in the certificate issuance process.
[57:19.550 --> 57:20.830]  So, we don't do it.
[57:21.290 --> 57:27.390]  So, yes, our certs rotate very, very frequently and almost on a biweekly basis I get emails from Pigeon users.
[57:28.070 --> 57:35.790]  Apparently, Pigeon binds to the key and remembers it, SSH style, which is kind of reasonable except it works really badly with Google when we rotate every two weeks.
[57:38.810 --> 57:39.290]  Someone...
[57:39.290 --> 57:39.610]  Okay.
[57:40.090 --> 57:40.150]  Go.
[57:40.490 --> 57:41.090]  Why is this
[57:50.870 --> 57:51.410]  so scary?
[57:51.650 --> 57:52.010]  Right.
[57:52.090 --> 57:56.630]  The question is, why is bad HTTPS more scary than HTTP?
[57:58.690 --> 58:02.030]  The answer sort of somewhat is legacy.
[58:02.490 --> 58:04.310]  We can't change that much.
[58:04.990 --> 58:20.110]  But I think the more important answer is that if you said HTTPS, the user in some sense, or somebody asked for a secure connection and we're failing to provide it to you, which is more interesting than if you didn't ask for a secure connection and you didn't get it.
[58:23.390 --> 58:25.110]  Yeah, I guess that's my answer.
[58:25.210 --> 58:37.930]  If we simply just didn't decorate HTTPS sites, then when an attack occurred, the fact that an attack occurred is more interesting than the benefit of just allowing people to run self-signed certs.
[58:38.030 --> 58:41.610]  If you need a cert, go to start SSL or DNSSEC.
[58:41.770 --> 58:49.510]  I think I would much rather make it easy to get certs than make it easy to use self-signed certs and possibly hurt other things at the same time.
[58:51.550 --> 58:52.030]  Sure.
[58:56.530 --> 58:57.010]  Yeah.
[59:04.240 --> 59:04.720]  Okay.
[59:05.160 --> 59:06.620]  So the question is...
[59:06.620 --> 59:11.040]  And by the way, I've just realized I'm the last person in this room, so I can keep going for hours.
[59:11.300 --> 59:21.260]  So if you want to run away, I hereby relieve any social pressure that you may feel and guilt about standing up and walking out.
[59:22.180 --> 59:24.160]  So the question here was CDNs.
[59:24.160 --> 59:31.000]  If I run an HTTPS site, and I'm sourcing stuff from CDNs, the CDN is nasty and will not give me HTTPS service.
[59:32.200 --> 59:33.580]  Some CDNs absolutely will.
[59:34.020 --> 59:38.140]  I mean, we run our own, I'm afraid, so I can't...
[59:38.140 --> 59:38.560]  Right.
[59:38.800 --> 59:41.060]  But some CDNs absolutely do, and I see them doing it.
[59:41.180 --> 59:42.040]  Akamai will, for example.
[59:42.200 --> 59:44.300]  Oh, this gentleman's going to tell me that I can't go on for hours.
[59:44.440 --> 59:45.240]  I just have to make a quick announcement.
[59:45.660 --> 59:45.980]  Yeah.
[59:46.240 --> 59:49.000]  So I just want to mention, there was a schedule change.
[59:49.140 --> 59:50.100]  I know some of you have heard about it.
[59:50.180 --> 59:53.740]  We're doing Lost Film Fest in the second room over there, the Sassaman room.
[59:54.160 --> 59:56.480]  That's starting now, going to closing ceremonies at 7.
[59:56.800 --> 59:58.000]  Closing ceremonies at 7.
[59:58.140 --> 01:00:02.460]  And you're wrapping up, because we have to close up the AV.
[01:00:02.760 --> 01:00:05.160]  But thanks so much for everyone for being here.
[01:00:05.160 --> 01:00:05.360]  Can I just change the question?
[01:00:05.620 --> 01:00:06.180]  Yeah, yeah, please.
[01:00:06.300 --> 01:00:11.280]  You can take another minute or two, but the AV guys are literally standing by because we're scheduled to pack this room up.
[01:00:11.540 --> 01:00:11.940]  Okay.
[01:00:11.940 --> 01:00:12.720]  And of course...
[01:00:12.720 --> 01:00:13.200]  Sorry, you can hang.
[01:00:13.720 --> 01:00:14.040]  You can hang.
[01:00:14.080 --> 01:00:14.600]  I can hang.
[01:00:16.520 --> 01:00:17.120]  No, no.
[01:00:17.200 --> 01:00:18.280]  I used to be an AV guy.
[01:00:18.460 --> 01:00:19.780]  I was a roadie for some years.
[01:00:19.940 --> 01:00:20.280]  No, you can hang.
[01:00:20.460 --> 01:00:22.060]  Just without the AV guys.
[01:00:22.180 --> 01:00:22.380]  Sure.
[01:00:22.980 --> 01:00:24.960]  So just to finish this question, which will be the last one.
[01:00:25.420 --> 01:00:27.640]  So yes, some CDNs will do HTTPS.
[01:00:27.740 --> 01:00:29.620]  You can simply go around, but they might charge you more.
[01:00:30.000 --> 01:00:31.740]  I don't have a good answer for that.
[01:00:31.920 --> 01:00:37.760]  I have floated a proposal where we say that in the HTTP, you can load a resource...
[01:00:37.760 --> 01:00:41.620]  Sorry, in the HTML, you can load a resource over HTTP if you provide the hash of it.
[01:00:41.800 --> 01:00:44.280]  If we can verify it, we don't need to get it over SSL.
[01:00:46.800 --> 01:00:48.640]  The problem with that is it's only going to be Chrome.
[01:00:48.760 --> 01:00:51.020]  It's going to trigger mixed scripting errors in the other browsers.
[01:00:51.120 --> 01:00:52.960]  I'm not sure how good an idea it is.
[01:00:53.100 --> 01:01:00.400]  And someone else at work decided to tack this idea onto a much bigger and more ambitious idea, which will probably sink and drag that down with it.
[01:01:02.120 --> 01:01:03.980]  So I don't know how it's going to happen.
[01:01:05.020 --> 01:01:06.200]  Yes, I'm sorry.
[01:01:06.320 --> 01:01:09.960]  Yes, CDNs, you may have to pay some more, but they will absolutely serve a HTTPS for you.
[01:01:09.960 --> 01:01:10.480]  Right.
[01:01:10.740 --> 01:01:11.880]  Thank you very much, ladies and gentlemen.