[00:00.000 --> 00:03.060]  A couple of quick announcements before we do the talk.
[00:03.920 --> 00:05.280]  Check out your RFID badge.
[00:05.780 --> 00:07.120]  AMD.hope.net.
[00:07.660 --> 00:08.260]  Check it out.
[00:08.480 --> 00:13.000]  I have a card telling me it's online, so have fun.
[00:15.220 --> 00:16.400]  The card says it is.
[00:17.900 --> 00:21.700]  We've also got a bunch of talks going on in the Morse room that aren't on the schedule.
[00:21.900 --> 00:24.300]  These are impromptu talks that folks have signed up to give.
[00:24.560 --> 00:27.880]  There is still space left if you want to sign up and give your own talk in the Morse room.
[00:28.540 --> 00:31.440]  Crunch is going to talk about EV charging stations.
[00:31.440 --> 00:35.700]  There's going to be a talk about patents, homebrew versus piracy in video games.
[00:35.920 --> 00:37.200]  A lot of cool stuff coming up.
[00:37.760 --> 00:38.160]  Check it out.
[00:38.200 --> 00:40.420]  Morse room is out in the back.
[00:41.700 --> 00:42.680]  So... Quick question.
[00:42.940 --> 00:44.520]  When and where are the lightning talks today?
[00:44.980 --> 00:49.240]  Lightning talks are after the keynote and they're going to be in the main hall.
[00:49.760 --> 00:51.320]  Also raises a good point.
[00:51.500 --> 00:53.260]  The keynote overflow will be here.
[00:53.400 --> 00:56.120]  We will have a live feed in this room.
[00:56.120 --> 00:59.940]  So if there's not room in the main hall, come on in here and we'll be able to help you guys out.
[01:01.080 --> 01:08.080]  So I don't know about you guys, but when I'm browsing to websites, when I see that little open lock go to closed, I just assume, you know, I'm good.
[01:08.380 --> 01:09.860]  Everything's nice and safe.
[01:10.680 --> 01:14.300]  It turns out that that might not necessarily be the case.
[01:14.960 --> 01:17.480]  There are some problems and there are some good solutions out there.
[01:17.900 --> 01:21.160]  And Seth Schoen here is going to talk to us about a lot of that.
[01:21.680 --> 01:21.740]  Seth.
[01:27.220 --> 01:28.060]  Hi, good morning.
[01:28.760 --> 01:31.860]  I appreciate all of you getting up and coming out to hear me.
[01:32.000 --> 01:33.260]  I think it's pretty early.
[01:34.080 --> 01:35.320]  I'm sure many of you do too.
[01:36.240 --> 01:38.620]  How many of you were at the monkey sphere talk last night?
[01:41.000 --> 01:41.400]  Cool.
[01:41.400 --> 01:45.300]  There seems to be a huge contingent of monkey sphere people right in the center there.
[01:46.420 --> 01:51.480]  A lot of the concerns that I'm going to talk about are actually the same as the concerns that were expressed in the monkey sphere panel.
[01:51.480 --> 01:56.240]  And this is kind of spooky here with the lighting.
[01:57.680 --> 02:02.460]  I think Dan Gilmore expressed them more eloquently than I'm going to be able to.
[02:02.700 --> 02:04.560]  And with cool diagrams, which I don't have.
[02:05.140 --> 02:08.560]  So if you get a chance, you should take a look at the video of the monkey sphere talk.
[02:09.200 --> 02:15.100]  Because I think it will provide a really good explanation about some of the concerns that I'm going to try to present.
[02:17.200 --> 02:20.460]  So a lot of you have probably heard something like this.
[02:21.700 --> 02:26.500]  This is something that someone wrote on the TLS list about two weeks ago.
[02:27.420 --> 02:29.980]  A lot of you may have even said something like this.
[02:31.960 --> 02:38.640]  So the idea in the conventional wisdom in some way is that HTTPS is for credit card numbers.
[02:39.340 --> 02:43.880]  I actually saw someone in the elevator with a shirt with a little picture of a padlock.
[02:44.060 --> 02:46.520]  And it said, this means you can trust me with your credit card number.
[02:51.180 --> 02:52.200]  I really want that shirt.
[02:54.520 --> 02:58.660]  But there's this idea that this HTTPS thing is for credit card numbers.
[02:58.660 --> 02:59.580]  And that's what it's for.
[02:59.680 --> 03:00.880]  And you need to use it there.
[03:00.960 --> 03:02.800]  And you shouldn't really expect to see it anywhere else.
[03:03.480 --> 03:08.800]  And this idea has persisted to the extent that someone is still repeating it on the TLS list like two weeks ago.
[03:10.300 --> 03:13.000]  And I see it in journalism about HTTPS.
[03:13.080 --> 03:14.600]  And I see it all over the place.
[03:15.880 --> 03:20.480]  And obviously, I'm going to say that this notion is eroding and that that's a good thing.
[03:22.180 --> 03:31.000]  So there is a good historical reason for this, which is that Netscape wanted to reassure users that it was safe to send their credit card numbers online and to buy things online.
[03:31.880 --> 03:35.040]  And so they came up with this original version of SSL.
[03:35.500 --> 03:37.280]  And they said, okay, we have encryption.
[03:37.280 --> 03:38.580]  Your credit card numbers are safe.
[03:38.700 --> 03:39.520]  You can feel confident.
[03:39.900 --> 03:41.100]  We have this padlock.
[03:41.360 --> 03:42.200]  Don't worry about it.
[03:43.400 --> 03:50.260]  It's not really clear that this is actually a major factor in preventing credit card fraud.
[03:50.820 --> 03:58.780]  A lot of credit card fraud really occurs in other ways that don't have anything to do with trying to intercept credit card numbers on the wire as people pay for things.
[03:59.660 --> 04:02.380]  People might try to intercept credit card numbers with key loggers.
[04:02.960 --> 04:06.340]  They might try to steal the credit card numbers from the e-commerce sites themselves.
[04:07.320 --> 04:08.780]  They might try to get them in other ways.
[04:09.080 --> 04:12.320]  So it's not really obvious that this is a major issue.
[04:12.900 --> 04:14.260]  I'm certainly happy it's there.
[04:15.440 --> 04:17.020]  But it's far from the only thing.
[04:17.580 --> 04:25.020]  But maybe a more important point is that credit card numbers are not necessarily anywhere near the most sensitive thing that you try to communicate on the web.
[04:28.220 --> 04:42.620]  So a lot of people give their credit card number and their credit card every day to strangers in stores and restaurants who may then take the credit card numbers into a back room and do something with them and then bring them back.
[04:44.640 --> 04:49.120]  I don't know if they would want to do the same thing with their Google searches or their Wikipedia browsing.
[04:50.660 --> 04:52.860]  I think for many people that's a lot more sensitive.
[04:54.680 --> 04:56.820]  And so I think there's been a recognition of that.
[04:57.520 --> 05:01.100]  Also people are very concerned about protecting passwords and logins.
[05:01.360 --> 05:10.880]  And they're concerned about software downloads because they don't necessarily want someone who controls the network to be able to replace a binary or browser plugin.
[05:11.980 --> 05:16.820]  And also people are maybe finally starting to realize that packet sniffing is really easy.
[05:17.600 --> 05:30.220]  I actually want to make a video that shows people how easy packet sniffing is because I do think there are a lot of people who don't quite perceive that, who might use a Wi-Fi network and not realize that everyone can run Wireshark and see all their packets.
[05:31.260 --> 05:34.760]  I think this audience is not really the target audience for that video.
[05:35.220 --> 05:37.200]  But I think there's a need for that.
[05:37.600 --> 05:39.740]  But a lot of site operators are aware of this.
[05:39.840 --> 05:46.080]  And so they're starting to turn on HTTPS for non-financial transaction parts of their websites.
[05:46.200 --> 05:47.380]  And I think that's a great development.
[05:48.220 --> 05:50.100]  Here are just a few recent examples.
[05:51.320 --> 05:51.680]  Google.
[05:52.640 --> 05:53.860]  We're very grateful to them.
[05:53.960 --> 05:55.140]  We were asking for that for a long time.
[05:56.080 --> 05:57.480]  We're very grateful that they did it.
[05:58.700 --> 05:59.060]  Facebook.
[06:01.340 --> 06:02.560]  Twitter and Identica.
[06:04.860 --> 06:07.860]  And that's for the ability to read tweets as well as post tweets.
[06:08.540 --> 06:11.540]  So you don't have to be logged in to use it, which I think is important.
[06:13.200 --> 06:17.360]  A lot of people may see Twitter as trivial, but there are a lot of people who use it for...
[06:17.360 --> 06:20.940]  things that they could get in a lot of trouble for, like political protest organizing.
[06:22.180 --> 06:25.020]  In places where they're not really allowed to organize political protests.
[06:25.280 --> 06:32.040]  So it can actually be quite important that people not know what tweets you're reading and not know that you're the author of particular tweets.
[06:32.220 --> 06:34.360]  Even though the content of the tweets themselves is public.
[06:35.260 --> 06:36.620]  There's an anonymity aspect.
[06:37.700 --> 06:38.180]  Gmail.
[06:40.040 --> 06:40.520]  Wikipedia.
[06:40.880 --> 06:41.780]  This is really great.
[06:42.000 --> 06:45.140]  And in fact, all of the Wikimedia Foundation wikis in every language.
[06:46.300 --> 06:49.820]  So Wiktionary, Wikinews, Wikipedia in every language.
[06:51.100 --> 06:52.800]  Amazon outside of the US.
[06:52.860 --> 06:54.940]  I don't know why they don't do it in the US.
[06:55.880 --> 06:56.860]  That would be nice.
[06:57.780 --> 07:01.240]  Notably for browsing and shopping, not just for payment.
[07:02.580 --> 07:04.400]  So there's an issue...
[07:04.400 --> 07:06.120]  I'll talk about this a little later.
[07:06.120 --> 07:09.700]  You know, not just with your credit card number, but what did you actually buy?
[07:09.840 --> 07:11.960]  And what did you actually look at and browse through?
[07:12.800 --> 07:18.640]  And there's generally a lot of concern in the physical world about privacy of people's reading habits.
[07:18.720 --> 07:20.220]  And Amazon started as a bookstore.
[07:20.860 --> 07:31.540]  And there's a concern and a lot of law in the United States about protecting people's confidential book purchasing and book browsing history.
[07:31.860 --> 07:33.820]  As well as the books that they check out from a library.
[07:34.780 --> 07:42.240]  So it's nice to see a site like Amazon make it possible for you to browse and fill a shopping cart in HTTPS.
[07:42.880 --> 07:44.240]  U.S. Postal Service.
[07:45.500 --> 07:48.700]  GMX, which is a very popular web mail provider in Germany and Europe.
[07:49.660 --> 07:52.420]  Several newspapers like the New York Times and the Globe and Mail.
[07:54.620 --> 07:57.620]  Medical and genetic sites like 23andMe.
[07:58.560 --> 07:59.900]  Blogging sites like WordPress.
[08:01.340 --> 08:06.460]  Meibo, which is a chat and IM interface, our site at EFF.
[08:07.140 --> 08:12.220]  More than 100 other sites that we know of for purposes other than credit cards.
[08:13.580 --> 08:14.480]  I think that's great.
[08:14.980 --> 08:17.880]  I think it's a wonderful development and a relatively recent development.
[08:20.660 --> 08:23.060]  So HTTPS is also very fragile in some ways.
[08:23.280 --> 08:24.960]  And I'm going to talk about two of those ways.
[08:25.080 --> 08:25.700]  There may be others.
[08:26.740 --> 08:28.620]  One is an attack called SSL stripping.
[08:29.500 --> 08:32.240]  And one is a problem about public key infrastructure.
[08:33.020 --> 08:36.100]  And then I'm going to talk a little bit about what we can try to do about some of these things.
[08:38.600 --> 08:42.660]  So SSL stripping is an attack that was invented by Moxie Marlin Spike.
[08:44.160 --> 08:48.020]  And it's a subtle point, but it's a very powerful attack.
[08:48.760 --> 09:00.140]  There are some sites that try to require HTTPS because they feel, the site operators feel, that what goes on on those sites is very sensitive and should always be private and confidential.
[09:00.360 --> 09:03.140]  So you should always be using HTTPS when you're on that site.
[09:04.340 --> 09:07.600]  And the leading example of this in many ways is PayPal.
[09:08.120 --> 09:17.040]  So if you go to PayPal in HTTP, they're going to redirect you immediately to HTTPS no matter what page on the site you went to, including the homepage.
[09:18.220 --> 09:21.380]  They don't want anyone to change any of their HTML.
[09:21.700 --> 09:23.780]  They don't want anyone to change any of their JavaScript.
[09:24.300 --> 09:27.860]  They don't want any content to appear anywhere on that site that they didn't put there.
[09:29.000 --> 09:33.620]  Which kind of makes sense considering the magnitude of the attacks against them.
[09:34.860 --> 09:36.480]  And so they'll send you a redirect.
[09:37.340 --> 09:39.520]  So if you type PayPal.com, you get this redirect.
[09:40.600 --> 09:45.520]  Well, Moxie said, an attacker doesn't have to let the user see that redirect.
[09:46.400 --> 09:50.280]  The attacker can hide that redirect and then proxy the entire session.
[09:50.820 --> 09:53.400]  The attacker can make the connection in HTTPS.
[09:54.020 --> 09:59.560]  And the attacker can make an unencrypted version of the exact same content available to the user.
[10:00.040 --> 10:03.620]  So the user actually goes through with the login process and interacts with the site.
[10:04.360 --> 10:07.560]  That's not available in unencrypted HTTP.
[10:09.040 --> 10:10.840]  But the attacker makes it available.
[10:11.620 --> 10:12.920]  A very powerful attack.
[10:14.120 --> 10:15.380]  Moxie really thought of everything.
[10:15.920 --> 10:20.380]  His SSL strip tool can replace the site's favicon with a picture of a padlock.
[10:20.900 --> 10:25.760]  So I really think someone needs to do an experiment to see what percentage of users get fooled by this.
[10:25.940 --> 10:28.380]  But please do it in a lab and not your workplace or cafe.
[10:32.300 --> 10:41.220]  So it's pretty significant because most users never type in HTTPS even if they're going to a site that supports it.
[10:41.760 --> 10:51.980]  Even lots of users who know what HTTPS is and know why they should use it, they don't necessarily have a bookmark to the secure version of a site.
[10:51.980 --> 10:54.100]  And so they're potentially vulnerable to this attack.
[10:54.980 --> 10:57.780]  And they might never notice because they are interacting with the real site.
[10:59.440 --> 11:04.580]  So there's a proposal to address SSL stripping called strict transport security.
[11:05.940 --> 11:16.280]  And the basic idea is that a site can say this site is HTTPS only and the browser should only access it in HTTPS regardless of what the user says.
[11:17.000 --> 11:18.600]  Regardless of what links say.
[11:19.520 --> 11:22.000]  You should always load the HTTPS version.
[11:22.360 --> 11:23.880]  There is a bootstrapping problem.
[11:24.700 --> 11:31.600]  If the attacker doesn't let the user communicate with the real site, the user might never learn about the site's policy.
[11:33.020 --> 11:34.040]  So that's tricky.
[11:36.890 --> 11:40.910]  It appears that all major web browsers are going to implement this in the near future.
[11:41.210 --> 11:46.490]  The first implementation that ships by default in a browser is in Google Chrome and Chromium.
[11:47.610 --> 11:48.550]  And that's great.
[11:49.070 --> 11:54.310]  One of the difficulties about this is that sites have to want to be HTTPS only.
[11:55.890 --> 12:08.350]  Because if any browser that supports this connects to the site in HTTPS and learns about the strict transport security policy, then, at least from that browser's point of view, that site is HTTPS only.
[12:08.570 --> 12:11.650]  And it will break if the HTTPS version is unavailable.
[12:13.250 --> 12:20.050]  Some sites, as it turns out, want to offer HTTPS, but they don't necessarily want to require it or force it.
[12:21.010 --> 12:30.350]  One reason might be that their sites load a little bit slower in HTTPS because there are additional round trips in the setup for the TLS protocol relative to just setting up HTTP.
[12:31.610 --> 12:40.350]  Another consideration that's a bit more insidious is that they may fear that some networks would block them if they went HTTPS only.
[12:42.190 --> 12:51.290]  And there's a recent precedent for that in terms of Google's actions after they deployed even the optional version of their encrypted search.
[12:52.330 --> 13:12.930]  When Google deployed their encrypted search, they started receiving complaints from schools that were running sensorware that the schools had to choose between blocking a bunch of Google services that the teachers were using in HTTPS or letting students do searches that would bypass the sensorware.
[13:13.890 --> 13:21.170]  And the schools were very mad that they were confronted with this choice because they wanted to be able to block some stuff without blocking other stuff.
[13:21.450 --> 13:24.970]  And if it was all in the same encrypted host, they wouldn't be able to block it.
[13:26.810 --> 13:35.530]  So they complained to Google a lot and Google actually decided to move their encrypted search onto a different host so that it would be easier to block.
[13:36.890 --> 13:53.830]  So I think that's just one taste of the power that network operators may hold over sites' decisions about encryption by threatening or desiring to block things in order to retain the ability to observe users' activities.
[13:56.510 --> 14:01.370]  And that wasn't even making the site HTTPS only, which would be a much bigger step.
[14:03.270 --> 14:08.010]  So EFF and the Tor project are collaborating on a thing called HTTPS Everywhere.
[14:08.830 --> 14:10.450]  This is a Firefox plugin.
[14:10.810 --> 14:12.530]  You can get it at the URL here.
[14:13.630 --> 14:15.790]  Over 200,000 people have downloaded it.
[14:15.990 --> 14:22.930]  And the basic idea is that we rewrite HTTP to HTTPS on sites that we know will support it.
[14:25.470 --> 14:34.630]  Interestingly, in a couple of cases, that doesn't necessarily mean that the site operator particularly wanted you to access it through HTTPS, but they permit you to.
[14:36.050 --> 14:42.990]  So we do experiments with sites where we try rewriting various parts of the site in HTTPS and we see if it breaks the site or not.
[14:43.270 --> 14:47.510]  And if it doesn't break the site, we'll write a rule that does the transformation.
[14:49.010 --> 14:53.870]  And so I think there are cases where some sites don't necessarily realize that they're available in HTTPS.
[14:53.870 --> 14:55.610]  But it's still a good thing for their users.
[14:55.990 --> 15:00.710]  I don't think we're doing something bad to the site by encouraging users to use them in the secure form.
[15:04.060 --> 15:09.460]  So some people say, well, why don't you just add an S or why don't you just try adding an S and see if the connection succeeds?
[15:10.380 --> 15:14.080]  And the basic difficulty is that URL patterns can be very unpredictable.
[15:14.660 --> 15:19.480]  And you can get a portion of a site that's available in HTTPS and a portion that's not.
[15:19.480 --> 15:22.440]  And so it depends on the particular path of the particular URL.
[15:23.320 --> 15:29.300]  If you want an example of this, go get HTTPS everywhere and look at the rules for Wikimedia or for Google.
[15:30.140 --> 15:35.180]  Just to start, both of them send you to a different host if you're in HTTPS.
[15:36.740 --> 15:39.160]  And then they may change the URL scheme.
[15:39.740 --> 15:46.500]  And then for Google, there are particular Google services that will work and particular Google services that won't work in HTTPS.
[15:46.500 --> 15:49.960]  So we have to actually know what those are and write regular expressions for them.
[15:50.860 --> 15:55.040]  And similar problems with somewhat less complexity occur for lots of other sites.
[15:55.400 --> 15:57.420]  So we have lots of regular expression rules.
[15:57.540 --> 15:58.260]  It's kind of a mess.
[15:59.060 --> 16:02.160]  We have a big backlog of user-contributed rules that we need to merge.
[16:02.860 --> 16:07.440]  And we need to try to store them in a hash table so that we can scale up to more rules.
[16:07.560 --> 16:17.860]  And ultimately, we think we need to move to something like AdBlock Plus where there's a subscription of user-contributed rules that make sites work in HTTPS.
[16:19.420 --> 16:20.980]  In a way, it's kind of a mess.
[16:22.840 --> 16:26.420]  But it actually does provide a lot more privacy and security to users.
[16:26.600 --> 16:28.920]  So that's nice, even if it's a mess.
[16:31.180 --> 16:39.720]  Now, I want to talk a bit about some of the issues that were raised in that monkey sphere talk yesterday about certificate authorities and certificate authorities' role.
[16:41.240 --> 16:49.200]  I actually just wrote an article about this which has just appeared in this month's China Rights Forum published by Human Rights in China.
[16:49.200 --> 16:54.920]  So if you want to see a longer written discussion of this, go to Human Rights in China.
[16:55.520 --> 16:57.020]  Take a look at the China Rights Forum.
[16:57.020 --> 16:57.840]  It's available online.
[16:58.080 --> 17:00.980]  You can see my article about certificate authorities.
[17:01.220 --> 17:02.860]  It's also called Behind the Padlock.
[17:05.240 --> 17:07.840]  So there's this concept of Zuko's triangle.
[17:08.740 --> 17:13.900]  Zuko says that you have to pick two of these three properties for a naming system.
[17:14.920 --> 17:19.700]  decentralized, human, meaningful, and secure that you generally can't get all three.
[17:21.680 --> 17:23.300]  There's been a lot of discussion about that.
[17:23.420 --> 17:25.860]  And some people say it depends what your assumptions are and so on.
[17:28.560 --> 17:36.360]  So we often use names that aren't secure in the sense that they're not cryptographically secure and wouldn't protect us against a man-in-the-middle attack.
[17:38.720 --> 17:47.400]  We often use names that are decentralized in the sense that there's no party that has to be trusted with the centralized power to assign them.
[17:47.820 --> 17:53.760]  We often use names that are human-meaningful, like other people's first and last names.
[17:56.160 --> 17:59.460]  Apparently, according to Zuko, we can't get all three at the same time.
[18:00.100 --> 18:04.020]  And so there's this choice about which one do you want to give up.
[18:04.440 --> 18:17.620]  One idea is that we could give up human-meaningful and have the PGP web of trust, where people look at and talk about these hexadecimal strings and they have to, like, read them to each other.
[18:18.780 --> 18:23.560]  I visited a friend's hotel room here at this conference two nights ago.
[18:23.720 --> 18:32.680]  And I walked in and my friend was saying, like, Charlie, delta, three, four, zero, alpha, bravo, seven, three.
[18:33.780 --> 18:36.260]  And I said, yeah, I walked in on a hexadecimal party.
[18:38.560 --> 18:40.020]  He was verifying a fingerprint.
[18:40.320 --> 18:44.240]  And I was really proud, like, that's a really responsible thing to do.
[18:45.620 --> 18:51.080]  You can see that a lot of people consider it kind of a nuisance because it's not really very human-meaningful stuff.
[18:51.440 --> 18:53.800]  And you have to potentially read the whole thing over the phone.
[18:54.840 --> 18:59.760]  I mean, there are interesting alternatives, like maybe 2D barcodes.
[18:59.940 --> 19:02.180]  And you could have a 2D barcode of a key.
[19:02.300 --> 19:04.520]  And if someone scans it, then they have it and they got it from you.
[19:04.620 --> 19:05.680]  So they know it's okay and so on.
[19:06.940 --> 19:12.200]  But in some sense, it's not human-meaningful the way that your first name is or the way that, like, google.com is.
[19:13.420 --> 19:23.180]  You could also choose to give up decentralized and say that there's a central entity or entities that have the power to issue these certificates.
[19:23.900 --> 19:32.080]  And that's the certificate authority model and that's the model that Netscape chose when they cooked up their implementation of SSL.
[19:32.760 --> 19:50.720]  And this idea actually historically comes from a military chain of command scenario where there's this chain of command and there's someone who's in charge and they issue responsibilities to people and they also issue cryptographic keys to people along that same military hierarchy.
[19:51.520 --> 19:58.840]  And so there are some concerns about this if you don't want to trust a single centralized entity.
[19:58.980 --> 20:01.800]  And there might be reasons that you might not want to trust an entity.
[20:02.180 --> 20:08.200]  There might also be reasons that you don't want to trust 40 or 100 or 200 such entities.
[20:09.680 --> 20:13.120]  So there's this perennial concern about these certificate authorities.
[20:13.520 --> 20:15.280]  There are a lot of them.
[20:15.520 --> 20:20.260]  I don't know how many of you have recently looked in your browser at the list of certificate authorities.
[20:20.540 --> 20:24.440]  But it's always an extremely alarming experience if you really think about it.
[20:25.060 --> 20:27.320]  There's this question, who are these people?
[20:27.740 --> 20:28.960]  Who chose them?
[20:30.080 --> 20:33.520]  What happens if these certificate authorities do something wrong?
[20:33.520 --> 20:51.020]  Either because someone tricks them, which has happened, or because they didn't understand what they were supposed to be doing, which has happened, or because they have a technical problem, or because they get sold to another entity, or because someone just asks them nicely to issue a fake certificate,
[20:51.220 --> 20:51.860]  and so on.
[20:52.360 --> 20:55.680]  So how would we know if they did this?
[20:56.220 --> 20:58.200]  And would they suffer any consequences?
[20:59.980 --> 21:02.180]  Also, why are there so many of them?
[21:02.860 --> 21:07.080]  Because they're all equally trusted to vouch for any site.
[21:07.540 --> 21:17.400]  It's not like there's VeriSign that can sign things for .com, and the China Internet Network Information Center that can sign things for .cn, and they can't sign for each other.
[21:17.500 --> 21:18.500]  That's not the way it works.
[21:18.680 --> 21:20.140]  They can all sign for any domain.
[21:20.820 --> 21:24.060]  So also, why are they all completely trusted to sign for any domain?
[21:26.600 --> 21:27.040]  Okay.
[21:27.680 --> 21:30.220]  So in practice, there have been a lot of scandals about this.
[21:32.100 --> 21:50.520]  One of the really impressive ones, in terms of best use of a PlayStation cluster, was the MD5 collisions paper, where they found that a certificate authority was still using MD5, which had been recommended by the cryptographic community to stop using for digital signature applications,
[21:50.900 --> 21:57.140]  because it was discovered that you can actually create collisions in the MD5 hash function in a useful way.
[21:57.380 --> 22:08.360]  So the researchers took their PlayStation cluster and their great cryptographic skill, and they said, we're going to trick someone into issuing us a certificate that does not mean what they think it means.
[22:09.260 --> 22:09.980]  And they did.
[22:10.520 --> 22:11.880]  And they got...
[22:11.880 --> 22:25.320]  I think many of you have probably read this paper, but they got a certificate authority, a mainstream trusted certificate authority, to issue them a certificate that was effectively a full delegation of all of its authority to them to do anything they wanted.
[22:26.060 --> 22:29.940]  Now, they're nice people, so they made it expire in the past, but that was their choice.
[22:31.880 --> 22:44.700]  Moxie Marlinspike also published another cool attack called a null prefix attack, having to do with this perennial issue about string termination in C.
[22:45.460 --> 22:47.720]  You know, this has been haunting people for a long time.
[22:48.220 --> 22:50.700]  We just, like, never know where our strings end.
[22:52.040 --> 22:55.700]  Well, even today, we don't really know where our strings end or where they don't end.
[22:57.120 --> 23:04.860]  Partially browser's fault, but it also shows that certificate authorities are willing to sign pretty dodgy certificates if you just give them money.
[23:05.200 --> 23:12.700]  Like, they're willing to sign certificates that contain really weird characters in really weird places or that are kind of longer than they appear to be.
[23:14.900 --> 23:22.340]  Another weird scandal was that a certificate authority, just last year, was issuing certificates with no checking.
[23:23.380 --> 23:27.840]  So, supposedly, they're supposed to check that you own the domain that you're buying a certificate for.
[23:28.100 --> 23:31.180]  That's the only thing that they're getting paid for.
[23:32.500 --> 23:38.740]  There was a certificate authority that was omitting that step and still collecting the money.
[23:39.260 --> 23:40.140]  And so,
[23:44.180 --> 23:49.660]  a founder of a rival certificate authority said, well, this is not really that good.
[23:49.940 --> 23:55.140]  And he went and just bought a certificate for Mozilla.org from the certificate authority.
[23:55.360 --> 23:56.680]  He doesn't own Mozilla.org.
[23:56.800 --> 23:59.700]  He just said, could I please have a certificate for Mozilla.org?
[23:59.780 --> 24:00.300]  Here's some money.
[24:00.780 --> 24:01.760]  And they said, sure.
[24:01.860 --> 24:02.560]  And they gave it to him.
[24:02.640 --> 24:03.560]  And he exhibited it.
[24:03.640 --> 24:04.520]  And it was kind of scary.
[24:06.820 --> 24:16.920]  There was also a paper from Chris Segoyan and Sid Stamm, where they reported on a presentation from a surveillance equipment vendor called Packet Forensics.
[24:17.600 --> 24:32.800]  And in the presentation, Packet Forensics said that their cool appliance could do automated man-in-the-middle attacks, and that you just had to load it with an appropriate certificate obtained, in their words, potentially by court order.
[24:33.660 --> 24:35.700]  And Segoyan and Stamm said, what?
[24:36.120 --> 24:38.760]  You can get a court order for a certificate?
[24:38.940 --> 24:39.720]  How does that work?
[24:40.700 --> 24:50.680]  And then there was an enormous controversy about the addition of the China Internet Network Information Center, RootCA to Firefox, which has gone through and it's in there.
[24:50.940 --> 24:52.500]  It's in their RootCA store.
[24:53.880 --> 25:04.300]  I actually think that the controversy sort of missed the real point, which is that all of these certificate authorities are potentially suspect in some way, and all of them have too much unaccountable power.
[25:05.500 --> 25:21.560]  People were particularly anxious about the Chinese government, and I can understand their anxiety, but all of these certificate authorities have this kind of power over you, and many of the other certificate authorities are also run by other governments or government-affiliated organizations.
[25:22.760 --> 25:33.140]  My tentative count was that about six Root certificates in Firefox were run by governments, and about 24 in Internet Explorer.
[25:33.520 --> 25:36.120]  And that's for years.
[25:36.140 --> 25:39.800]  That's before the addition of the China Internet Network Information Center.
[25:40.000 --> 25:48.660]  So I think the debate kind of missed that point, that there are governments that are in there already, and there's a question about, how do we know what these certificate authorities are doing?
[25:51.360 --> 26:01.340]  And so a lot of people, and again in the MonkeySphere talk this was articulated very well, it seems that the certificate authorities are doing something very important.
[26:01.840 --> 26:12.060]  We do actually want to know if we're talking to the real site rather than a man in the middle, rather than someone on our wireless network or at our ISP who's spying on all of our communications.
[26:12.060 --> 26:17.420]  And the certificate authorities do give us information that could help us make this decision.
[26:17.740 --> 26:19.340]  And that seems very important.
[26:19.820 --> 26:28.700]  But it's strange to think that there's this list of entities that everyone in the world can trust, and should trust for these purposes.
[26:29.340 --> 26:38.840]  It's strange to think that there need to be dozens or hundreds of them, since every new certificate authority is a potential source of additional risk to users.
[26:39.760 --> 26:49.980]  Someone just did a great calculation about assuming that the probability of misbehavior from each certificate authority is independent of each other.
[26:51.340 --> 27:01.460]  And then choosing a probability value and choosing a number of CAs, and you can make a little graph of the probability that no CA will misbehave.
[27:03.800 --> 27:05.180]  So it's kind of bad.
[27:07.780 --> 27:20.700]  So one thing that we're doing over at EFF is an SSL observatory, which is starting with a survey of all of the public certificates presented by HTTPS servers on the Internet, which we have done.
[27:21.400 --> 27:22.400]  There's an asterisk.
[27:22.560 --> 27:23.800]  You can ask me about the asterisk.
[27:23.800 --> 27:24.960]  It's sort of all.
[27:25.100 --> 27:25.920]  It's not actually all.
[27:27.720 --> 27:32.100]  It's actually hard to get all of them for some interesting reasons.
[27:32.640 --> 27:43.460]  What we want to do is learn about how certificate authorities are being used and how they're behaving and what they're signing, and potentially retrospectively discover if some of them are misbehaving.
[27:44.300 --> 27:48.380]  We can't necessarily prove that they're not misbehaving, but we may be able to notice if they are misbehaving.
[27:49.160 --> 27:59.260]  I wanted to show you the really cool logo for this, which is going to be a woman standing on a tower, holding a telescope and looking at the night sky.
[28:00.000 --> 28:04.980]  And the night sky is going to be filled with twinkling yellow padlocks.
[28:05.340 --> 28:08.240]  But our graphic designer is still working on it, so I can't show it to you.
[28:08.340 --> 28:12.640]  But you can imagine a night sky full of padlocks and the telescope and everything.
[28:14.940 --> 28:16.760]  So the data is being analyzed right now.
[28:17.660 --> 28:23.700]  My colleague Peter Eckersley is running a whole bunch of queries over the database, looking at interesting things.
[28:24.320 --> 28:27.300]  He's planning to have initial results ready to present at DEFCON.
[28:28.360 --> 28:32.660]  And there should be a lot of interesting stuff, even if we don't directly find an attack.
[28:33.040 --> 28:37.200]  There should be some interesting things and some surprising things, just from looking at this data.
[28:38.160 --> 28:46.400]  We hope in the long run that we'll have a way that the public can submit certificate observations of their own, like, I encountered this certificate.
[28:47.060 --> 28:48.420]  You should have it in your database.
[28:49.240 --> 28:54.400]  One reason for that is that what you see on the Internet depends on where you are.
[28:55.460 --> 28:56.820]  And that's true in many ways.
[28:56.960 --> 29:00.000]  You might see geolocation, geotargeted advertising.
[29:02.680 --> 29:06.620]  It's also true in terms of certificates, which is kind of odd.
[29:07.200 --> 29:13.680]  But there are these CDNs, content delivery networks, and people have different co-location facilities in different places.
[29:13.920 --> 29:16.100]  And they'll often send you to the closest one.
[29:18.040 --> 29:22.100]  And different colos might actually have different certificates.
[29:22.580 --> 29:30.140]  This is something that has really antagonized me, because it makes some simple, elegant solutions to these concerns impossible.
[29:31.120 --> 29:32.140]  Maybe impossible.
[29:33.220 --> 29:41.500]  If different colos have different certificates, then people in one place or on one network may see a different certificate than the one that other people see.
[29:41.500 --> 29:50.900]  And that's why we could really increase our coverage by getting submissions from the public on different networks rather than just our particular scanning machine.
[29:51.880 --> 30:08.380]  Also, if someone is doing an attack with a fake certificate, concocted particularly for that purpose, they would probably be well advised to do that attack against a very small number of people, and for a very short time.
[30:09.080 --> 30:12.280]  Because these certificates are visible.
[30:12.460 --> 30:13.680]  You could save them.
[30:14.060 --> 30:19.340]  And they provide evidence about what happened in the sense that you can see who signed them, and what they signed.
[30:19.740 --> 30:36.080]  And so if someone did an attack, and they did the attack for a long time against a lot of people, if any of those people saved the certificate, and looked at it, and compared it to what other people are seeing, they might realize that there was an attack,
[30:36.080 --> 30:38.460]  and they might be able to deduce who is responsible.
[30:39.380 --> 30:45.020]  And so getting wide coverage could be very important in terms of seeing attacks that are occurring in the wild.
[30:47.280 --> 30:48.340]  So we hope to do that.
[30:48.560 --> 30:51.200]  We also hope to allow the public to look at the data that we gather.
[30:51.500 --> 31:03.620]  So if you run a site, ideally, you would be able to go to the observatory and look up all of the certificates that people have seen in the wild for your site, which might be of some interest to you.
[31:04.960 --> 31:19.060]  A lot of people have also been talking about trying to change browser security policy in order to try to address some of the concerns about the power of certificate authorities by adding other information sources that people can use.
[31:19.060 --> 31:23.120]  So one of them that was presented here at HOPE yesterday is the monkey sphere again.
[31:23.820 --> 31:30.560]  This uses the PGP Web of Trust to make assertions about the keys that websites should be using.
[31:31.020 --> 31:32.340]  And that's a really cool idea.
[31:33.160 --> 31:38.200]  It's challenging because a lot of people don't like reading the hexadecimal strings to each other.
[31:39.580 --> 31:46.400]  So we still have to figure out how to make the PGP Web of Trust grow and make people willing to participate in it.
[31:47.020 --> 31:57.440]  But technically, this is a really excellent idea because it provides a clear alternative to having these few entities with this unique power to say things about keys.
[31:58.760 --> 32:15.600]  Another proposal that a lot of people have been excited about is called perspectives, where you get information from a wide variety of servers about what keys they're currently seeing and what keys they've seen recently for a particular site that you want to connect to.
[32:16.200 --> 32:18.280]  And this is a project from Carnegie Mellon.
[32:18.660 --> 32:20.960]  And I use it and I think it's really great.
[32:21.540 --> 32:29.700]  The difficulty is, again, that sites can use different keys for different people.
[32:31.740 --> 32:38.160]  So, there might be people in Russia who all see a particular key for a particular service.
[32:38.520 --> 32:40.060]  And there might be people in the U.S.
[32:40.060 --> 32:41.220]  who all see a different key.
[32:41.900 --> 32:49.100]  And now they have to decide, is the Russian government attacking everyone in Russia with a man-in-the-middle attack?
[32:49.860 --> 32:50.680]  Is the U.S.
[32:51.060 --> 32:52.420]  government attacking everyone in the U.S.
[32:52.480 --> 32:53.480]  with a man-in-the-middle attack?
[32:54.480 --> 32:59.120]  Or is the site just using two different COLO facilities with two different legitimate keys?
[32:59.640 --> 33:06.200]  And there is no real way to make that decision automatically, because technically these situations would be indistinguishable.
[33:06.720 --> 33:11.620]  The other concern is that a site can actually use many different legitimate keys at the same time.
[33:12.840 --> 33:13.920]  Citibank does this.
[33:14.200 --> 33:29.240]  It's really frustrating to go to the Citibank site with perspectives and open up the perspectives window and see the history graph, and you see this quilt, because they have dozens of keys, and they use all of those keys all the time.
[33:30.180 --> 33:37.120]  It seems that they have some cryptographic appliances like cryptographic load balancers, and they have a different key in each one.
[33:37.500 --> 33:40.880]  And so the key that you get just depends on random luck.
[33:42.800 --> 33:53.080]  And so you can't say, oh, that's the same key that all the other people are seeing, because there's almost no chance that all the other people will be seeing that same key right at the same moment.
[33:54.780 --> 34:05.800]  And in the model as proposed by Netscape and as implemented by all of the major browsers, it's okay in some sense for Citibank to be doing that.
[34:07.100 --> 34:14.840]  There is no explicit rule anywhere that you have to use the same single key for a site at a given time.
[34:15.720 --> 34:35.160]  We also had a fun experience where we were running perspectives and we were looking at some sites, and we looked at the PayPal site, and there was this key change that lasted like four hours, and then it went back to the original key.
[34:36.700 --> 34:45.760]  And it was like, wait, why did the PayPal site key change for four hours when it hadn't changed for weeks and weeks, and then it didn't change for weeks and weeks after that?
[34:46.120 --> 34:53.380]  Um, did someone like do a BGP attack and route all of their, all of PayPal to somewhere else for four hours?
[34:54.160 --> 34:58.740]  Uh, so we got in touch with PayPal, and the PayPal people said, no, that was okay.
[34:59.320 --> 35:01.380]  Uh, don't worry about it.
[35:03.400 --> 35:09.500]  So, yeah, I mean, it's frustrating because, you know, we're relying parties.
[35:09.500 --> 35:11.140]  Like, we want to worry about stuff.
[35:12.160 --> 35:19.040]  Um, so there's also a proposal to use individuals' observed history.
[35:19.240 --> 35:23.520]  Like, what certificate authority have I seen a site using?
[35:24.800 --> 35:29.060]  Uh, there's a proposal called CertLock, uh, from Seguyen and STEM.
[35:29.060 --> 35:32.040]  And there's also DNSSEC.
[35:32.420 --> 35:39.680]  Um, some of you may be aware that the root zone is finally signed as of this week.
[35:40.020 --> 35:44.120]  So you can actually theoretically validate things in the DNS cryptographically.
[35:45.460 --> 35:49.640]  Uh, so DNSSEC is a signing system for the domain name system.
[35:50.000 --> 35:53.620]  So you can actually get digital signatures over your DNS records.
[35:53.620 --> 35:58.000]  And for the first time this week, the root zone is signed.
[35:58.920 --> 36:02.680]  Um, top-level domains that you use are probably actually not signed yet.
[36:02.700 --> 36:06.260]  So you probably actually can't get your, your DNS records signed.
[36:06.440 --> 36:08.120]  But, you know, some people can.
[36:08.740 --> 36:14.660]  Uh, so there's a proposal that we can use DNSSEC to publish server queues.
[36:14.780 --> 36:19.380]  And they can be signed in the DNS, which is cool because it's another source of information.
[36:19.880 --> 36:22.360]  And it's not the same as the certificate authorities.
[36:22.360 --> 36:33.800]  Um, it's still centralized because the DNS authorities, instead of the certificate authorities, are in a position to sign things that aren't true.
[36:34.100 --> 36:35.720]  So it doesn't get rid of the centralization.
[36:36.140 --> 36:43.240]  You could say it's still progress because now we have another central authority that can work in parallel to the existing central authority.
[36:43.420 --> 36:46.800]  And if they disagree, maybe we can look into the matter.
[36:47.560 --> 36:49.520]  Um, doesn't get rid of the centralization.
[36:50.780 --> 36:59.500]  Uh, there's also a notion that there should be more standardization of how sites talk about their security policies.
[36:59.920 --> 37:01.860]  There are a lot of mechanisms for this.
[37:02.200 --> 37:14.900]  Um, so Andy Steingrubel and Jeff Hodges from PayPal have proposed that there should be a single place that browsers go to learn about all these kinds of policies.
[37:15.680 --> 37:17.640]  Uh, I think that would be a great development.
[37:18.300 --> 37:29.420]  And I think one of the other things that that mechanism could be used for is for a site to talk about what keys or what certificates users of that site should expect to see.
[37:30.120 --> 37:35.380]  For example, a site could say, we use this cryptographic key.
[37:37.380 --> 37:41.880]  Um, but we're planning to change to this other one in two weeks.
[37:42.360 --> 37:46.580]  So if you see us change to this other one in two weeks, that's okay.
[37:47.380 --> 37:51.100]  Um, you can actually do something similar in monkey sphere.
[37:51.740 --> 37:54.420]  Uh, but I think this would be a nice thing.
[37:55.700 --> 37:59.460]  Because then you could say, well, if I trusted the site then, if I thought...
[38:00.320 --> 38:10.920]  If I believed that my connection to the site then was authentic and I was talking to the real site, and I trusted the site to predict what it was going to do, then I'm okay.
[38:11.900 --> 38:25.340]  Um, you could also address the multiple colos issue, potentially by having a mechanism for a site to say, well, if you're in Russia, you can expect to see this key, and that's okay.
[38:25.920 --> 38:28.220]  If you're not in Russia, you shouldn't see it.
[38:28.840 --> 38:40.100]  Um, or a site could try to promise to publish revocation information when there's a key change, so that you could expect to look for that, um, okay.
[38:41.180 --> 38:46.620]  This is all speculation, because there isn't actually a draft or a proposal for that mechanism.
[38:46.960 --> 38:55.360]  Um, but I think it's interesting to think about sites trying to tell users more about what to expect in terms of cryptographic keys.
[38:55.540 --> 38:58.020]  I think that could potentially be a very powerful mechanism.
[38:59.820 --> 39:05.640]  Um, and so in monkey sphere, end users can also say these kinds of things.
[39:05.640 --> 39:08.340]  Like, that's totally a great key for that site.
[39:08.340 --> 39:09.820]  I'm totally happy with it.
[39:10.480 --> 39:29.780]  Um, the PayPal people are a little bit anxious about this, because they say, well, site operators are the real authorities about what their keys are, and they can change them at any time for any reason, and you shouldn't necessarily expect that some outside party would know what the key ought to be.
[39:29.780 --> 39:33.980]  Um, and so that's a challenging conceptual issue.
[39:35.260 --> 39:45.860]  So, basically, if you want to actually have private communications with the site, you need the site operator to have a way to reliably communicate to you what the public key for the site should be.
[39:46.640 --> 39:53.360]  Uh, lots of people want to interfere with whatever kind of process we may have to facilitate that process.
[39:54.360 --> 39:59.980]  At the same time, a lot of people are trying to improve HTTPS and also to make it more widely used.
[40:00.660 --> 40:05.220]  Um, so if you run a site, it would be really cool if you could turn on HTTPS.
[40:05.560 --> 40:07.220]  You can also tell us about it.
[40:07.340 --> 40:09.440]  We may be able to put it into HTTPS everywhere.
[40:10.200 --> 40:20.060]  Um, you can run HTTPS everywhere and suddenly get a lot of your browsing in HTTPS that you might not have explicitly thought to do securely.
[40:20.680 --> 40:24.980]  Um, you can try out some of the plug-ins that implement some of these ideas.
[40:25.420 --> 40:26.920]  Uh, send bug reports.
[40:27.580 --> 40:28.720]  Try out MonkeySphere.
[40:28.880 --> 40:29.700]  Try out Perspectives.
[40:30.100 --> 40:34.840]  There's one called Certificate Patrol that will warn you when things change, kind of SSH style.
[40:38.480 --> 40:40.680]  Um, and, uh, I think that's about it.
[40:41.060 --> 40:44.680]  So, thanks a lot, and I'd be happy to have any questions that anyone might have.
[40:55.180 --> 40:55.580]  Hi.
[40:55.760 --> 41:03.680]  I was wondering if, uh, self-scientist certificates, if you could speak a little bit about that, especially for people who may be running homebrew informational websites.
[41:04.140 --> 41:04.440]  Thank you.
[41:05.580 --> 41:08.220]  Yeah, self-scientist certificates are this enormous controversy.
[41:09.600 --> 41:17.460]  Because web browsers recently have taken a lot of steps to try to discourage the use of self-scientist certificates.
[41:18.500 --> 41:22.580]  So, Firefox changed their interface in the last release of Firefox.
[41:23.080 --> 41:32.240]  Um, someone described it as, you get the scary screen, and it asks you, would you like to go on to the other scary screen?
[41:32.720 --> 41:35.180]  Uh, or give up.
[41:35.460 --> 41:39.400]  And then if you say you want to go on to the other scary screen, then it's scarier.
[41:39.400 --> 41:45.480]  Um, so they really, you know, don't like self-scientist certificates.
[41:45.920 --> 42:02.220]  And the core of this controversy in the status quo is not really about centralization or decentralization, but it's about defending against passive eavesdroppers versus active man-in-the-middle attackers.
[42:02.760 --> 42:13.060]  Um, because if someone is just running Wireshark, then if you have a self-signed certificate, you're still completely protected against them.
[42:14.080 --> 42:20.980]  If someone is running an active man-in-the-middle attack, then you need a way of finding out if the key is authentic.
[42:21.620 --> 42:37.300]  And in that case, self-signed certificate by itself without having some other tool or some other information, um, whether monkey sphere or you remember the hexadecimal or you call someone up on the phone, or you have cert patrol and you do SSH-style key continuity,
[42:37.960 --> 42:41.160]  without some other tool, you would be vulnerable to an active attack.
[42:41.940 --> 42:57.980]  So there's this trade-off, actually, that's come up in a lot of crypto between protecting against the passive person who's just listening and putting some infrastructure in to protect against the active attacker who's changing packets, who's modifying communications.
[42:58.360 --> 43:11.880]  Um, one cool solution to this has been off-the-record messaging, OTR, um, which is a retrofit for IM, to add crypto to IM.
[43:12.480 --> 43:30.060]  And what they basically do is start out unverified, start out with a way to defend against, uh, passive eavesdropper, and then if you want, you can do an additional verification step to protect against the active eavesdropper.
[43:30.680 --> 43:41.000]  Um, it seems like that's easy to do because the protocol is interactive, and because you can send messages back and forth even in the middle of the conversation.
[43:41.460 --> 43:43.920]  It seems like it would be harder to do that on the web.
[43:44.620 --> 43:50.140]  Um, so I think I've just evaded the question because I've just said that self-signed certificates are very complicated.
[43:50.660 --> 43:56.900]  Um, but, I mean, the basic point is that there's a trade-off between the passive and the active adversary protection.
[43:57.240 --> 44:06.900]  And browsers have been moving in the direction of trying to protect us against the active adversary, potentially at the expense of passive adversary protection.
[44:07.820 --> 44:22.500]  Um, I'm not going to try to say whether that's good or bad, but I agree that it could be annoying if you're trying to exist solely outside of the CA system, and you have people who are not trying to exist outside of the CA system.
[44:23.900 --> 44:25.360]  Uh, sorry.
[44:25.560 --> 44:27.200]  I have points rather than questions.
[44:27.580 --> 44:34.780]  Um, the first one, the STS, the problem with STS in that if you haven't been to the site before, it cannot know that the site should be HTTPS only.
[44:35.280 --> 44:37.540]  There is a list, uh, which I'm trying to start up.
[44:37.660 --> 44:38.440]  It's in Chrome at the moment.
[44:38.600 --> 44:43.180]  If you type PayPal.com into Chrome right today, it will not let you go to the HTTP site.
[44:43.300 --> 44:43.620]  Ever.
[44:43.960 --> 44:44.840]  Even from a fresh install.
[44:45.120 --> 44:52.840]  If you want to be on that list, if you run a site, um, please email me or just do a Google search for Chromium STS and you'll find the site with all the details.
[44:54.600 --> 44:59.260]  Um, Citigroup, uh, the fact that they run these 10 certificates, they're not just being stupid.
[44:59.420 --> 45:03.440]  I believe that their SSL accelerators do not have an option for exporting a private key.
[45:03.960 --> 45:11.100]  So they buy them, they come loaded with a private key, and never again should it leave that box, which is an interesting trade-off, but I think that's why they do it.
[45:12.780 --> 45:15.560]  Um, HTTPS for your site is probably slightly slower.
[45:15.920 --> 45:22.900]  I hope by this time next year that the latency, uh, hit will have been eliminated in Chrome.
[45:23.140 --> 45:28.940]  I can't speak for other browsers, but with Chrome, you should be able to do a zero round-trip SSL connection by this time next year.
[45:29.700 --> 45:34.620]  Uh, and for the, uh, the self-signed certificate part, certificates are now free.
[45:35.320 --> 45:37.920]  Um, StartSSL.com will give you a certificate for free.
[45:38.080 --> 45:39.940]  So there is little...
[45:40.560 --> 45:46.860]  There's a very small barrier these days to getting a real certificate, and frankly, the barrier for your users for going through the scary pages is probably higher.
[45:48.080 --> 45:48.580]  I think that's all.
[45:48.640 --> 45:49.380]  What's your email?
[45:50.040 --> 45:54.240]  Um, I am AGL, above ground level, at chromium.org.
[45:54.240 --> 45:59.280]  Uh, and if you have any security problems, if you run a big site, we want to help you.
[45:59.580 --> 46:01.640]  We can only affect Chrome.
[46:01.760 --> 46:03.620]  We might be able to affect Firefox a bit, and maybe Opera.
[46:03.840 --> 46:05.740]  But we want to make our users more secure.
[46:05.920 --> 46:08.280]  So if you have any issues, please do email me.
[46:08.380 --> 46:08.900]  We are responsive.
[46:10.420 --> 46:16.080]  Um, so I'm really grateful for all of your work on HTTPS, and I'm really excited about it.
[46:16.080 --> 46:20.320]  And, um, thank you for everything that you're doing to make HTTPS better.
[46:20.840 --> 46:26.180]  And all of those points are exactly correct and very useful, and I'm sorry that I didn't mention them before.
[46:26.600 --> 46:27.960]  But, thank you.
[46:28.700 --> 46:29.180]  Um,
[46:34.060 --> 46:46.460]  what is your opinion of, uh, EV certs, and would there be any benefit to making browsers, uh, require sites, like, such as PayPal, but, or Mozilla, that has used EV certs in the past to always use them?
[46:46.460 --> 46:59.060]  Um, my colleague Chris Palmer gave a talk about many of these same issues, where he said a very, um, cynical and witty thing about the EV cert issue.
[46:59.420 --> 47:07.160]  So, I don't think I can be as cynical or as witty as Chris Palmer, so I refer you to his presentation for that.
[47:07.480 --> 47:07.800]  All right.
[47:09.000 --> 47:09.880]  Extended validation.
[47:10.200 --> 47:13.400]  Um, but just imagine something cynical and witty.
[47:13.600 --> 47:13.920]  Okay.
[47:16.020 --> 47:17.060]  In, in the interim.
[47:17.700 --> 47:20.340]  Uh, comment about, uh, PayPal and then a question for you.
[47:20.780 --> 47:22.640]  Um, just about PayPal's policies.
[47:22.860 --> 47:27.580]  I don't know if anyone's familiar with this, but if you are a merchant, their, um, signing up policy is very liberal.
[47:27.720 --> 47:28.320]  They'll just take you.
[47:28.680 --> 47:31.460]  Um, and then their compliance policy is very strict.
[47:31.660 --> 47:36.840]  So, if you're an adult merchant or doing anything kind of questionable, you can process like $10,000 and then they'll shut you down.
[47:36.840 --> 47:37.880]  Um, and keep your money.
[47:38.080 --> 47:39.700]  So, that's how they've been very successful.
[47:40.240 --> 47:42.240]  Um, but anyway, off of PayPal.
[47:42.700 --> 47:44.160]  Um, about self-signed certs.
[47:44.400 --> 47:52.900]  Do you, have you seen or, um, understand or know of any interest in the community for us to actually create our own certificates in this way and actually be responsible for it ourselves?
[47:52.900 --> 47:55.140]  In the same way like MonkeySphere, but for SSL.
[47:55.980 --> 47:58.060]  Well, MonkeySphere actually does work with SSL.
[47:58.320 --> 48:03.360]  So, I think probably what you're looking for ultimately there would be MonkeySphere.
[48:05.000 --> 48:16.200]  I'm very interested in MonkeySphere, but I mean in the sense of a, a, a community-run, um, root certificate authority in the same way that, that exists out there but is run by us and not at some corporation.
[48:17.440 --> 48:25.220]  Um, I'm not really, but I'm not sure that, that would address the particular concerns that I have.
[48:25.400 --> 48:38.880]  I think it might address some concerns, but, uh, I don't think that the particular thing that makes me concerned about these certificate authorities is that they're for-profit businesses or even impersonal corporations.
[48:39.800 --> 48:45.460]  Um, potentially the certifying role is something that could be done well by an impersonal for-profit business.
[48:45.460 --> 48:48.180]  Um, to the extent that it can be done well by anyone.
[48:48.760 --> 48:55.540]  Um, I think it's an interesting idea and I wouldn't really oppose it, but I don't think that it would address the concerns that I have.
[48:58.330 --> 49:03.730]  Um, Amazon.com is sort of usable over HTTPS.
[49:03.970 --> 49:11.210]  Uh, until recently searches were, were working, but now they just redirect to plain HTTP.
[49:11.670 --> 49:14.970]  But if you know the ASIN, you could go to product page.
[49:15.730 --> 49:18.110]  But you won't know the ASIN if you haven't done the search yet.
[49:18.350 --> 49:18.710]  Correct.
[49:18.710 --> 49:20.290]  Unless you, like, have it memorized from some other source.
[49:20.350 --> 49:21.570]  Or, or you get it from another source.
[49:22.230 --> 49:31.410]  Yeah, um, I guess I'm thinking, I, I definitely agree that there are lots of parts of the Amazon site, even the Amazon U.S. site, that are usable in HTTPS.
[49:31.410 --> 49:34.670]  Yeah, you could also view the cart in HTTPS.
[49:35.230 --> 49:39.710]  Yeah, I mean, Amazon has done a lot of good HTTPS support on their U.S. site, too.
[49:40.190 --> 49:46.190]  I'm just thinking basically about the browsing experience when you first show up at the site, if you start to browse things.
[49:46.730 --> 49:52.310]  Um, for your initial search, if you don't know the ASIN and you don't have things in your cart and so on.
[49:52.310 --> 49:52.870]  Yeah.
[49:53.210 --> 50:03.730]  In, in the current iteration of the site, um, I mean, I tried writing a rule to do all Amazon URLs in HTTPS, in HTTPS everywhere.
[50:04.110 --> 50:06.630]  Um, and in the current iteration of the site, it does break the site.
[50:06.790 --> 50:07.390]  It does, yeah.
[50:07.850 --> 50:14.130]  Um, so, but I'm optimistic, certainly, because Amazon's non-U.S. sites all let you do everything in HTTPS.
[50:14.550 --> 50:17.210]  So, I hope that will become available again for the U.S. site.
[50:17.390 --> 50:17.690]  Okay.
[50:19.430 --> 50:19.830]  Hi.
[50:20.150 --> 50:20.650]  Thanks, Seth.
[50:20.650 --> 50:26.290]  Um, this, uh, so I'm, I work on the MonkeySphere project and just thank you for mentioning it to folks.
[50:26.830 --> 50:32.070]  Um, I wanted to, uh, just make a couple observations about, uh, uh, just two observations.
[50:32.470 --> 50:37.570]  Self-signed certificates, um, actually are the equivalent of your SSH host keys.
[50:37.790 --> 50:49.150]  So, if you're comfortable connecting to SSH servers and just either verifying or not verifying the fingerprint and then relying on the key continuity, then accepting a self-signed certificate is the exact same thing but with a website.
[50:49.150 --> 50:52.730]  If you have cert, um, if you have cert, um, if you have cert control.
[50:53.450 --> 50:54.190]  Because the...
[50:54.190 --> 50:57.090]  No, no, if you accept the certificate and say store this exception permanently.
[50:57.410 --> 51:00.930]  That action is the same thing as saying yes to the OpenSSH prompt.
[51:01.690 --> 51:06.570]  Um, yeah, I guess the warning, the phrasing of the warning is a little different.
[51:06.750 --> 51:09.450]  The phrasing of the warning, the user interface is a totally different thing.
[51:09.450 --> 51:13.950]  I'm just saying that if you choose to do that, that that is, is fundamentally equivalent.
[51:14.630 --> 51:25.850]  Um, and just, just as an observation for folks who are currently using SSH one way and web browsers the other way, if you're, if you feel uneasy about one or the other, think about how to reconcile those feelings because it's the same thing.
[51:26.370 --> 51:32.110]  Um, and then the second observation is, uh, about the scary page that you get when you see an unknown certificate.
[51:32.590 --> 51:36.530]  Um, one way to work around that is to get a quote real cert, right?
[51:36.710 --> 51:39.090]  From one of these unaccountable certificate authorities.
[51:39.290 --> 51:45.550]  But another way around that, if you're doing an SSL stripping style attack, and I haven't seen anybody actually implement this, but if you're interested, you should do it.
[51:46.150 --> 51:58.510]  Um, if you can do the SSL strip thing, then you can actually feed a mime type that is a certificate authority certificate that will prompt the browser to import that into their root certificate store.
[51:58.510 --> 52:11.030]  So you can not just, not just replace the certificate with your own certificate, but if you can convince the user to actually import your own certificate authority, you can now man in the middle all of their communications by doing that one thing.
[52:11.330 --> 52:17.390]  So, and that actually, that workflow is much simpler than the difficult workflow for looking at self-signed certificates.
[52:17.670 --> 52:21.250]  So there's a, there's an issue with the browser's choices of UI there.
[52:21.690 --> 52:27.650]  Yeah, that would be another great UI experiment to see what percentage of users would add a new root certificate.
[52:27.650 --> 52:34.250]  if a site first gave them a story about why they should, and then, um, ask them to.
[52:34.730 --> 52:35.690]  That would be interesting.
[52:36.930 --> 52:40.010]  I agree, it is remarkably easy to add a new root certificate.
[52:42.050 --> 52:48.690]  You touched on the, uh, government's influence on certificate authorities, and that could probably be a whole lie talk unto itself.
[52:49.030 --> 52:54.270]  But what do you see for the potential implications on trying to secure HTTPS as a result of that?
[52:54.270 --> 53:03.090]  Especially like the intelligence community obviously has a, um, a strong desire to be able to be a man in the middle by signing their own certificates.
[53:03.670 --> 53:05.490]  Um, so where, where do you see that going?
[53:06.650 --> 53:12.270]  Well, I think that's basically one of the points on my list of reasons that people are nervous.
[53:12.730 --> 53:14.010]  Um, oops.
[53:14.210 --> 53:14.590]  Yeah.
[53:15.270 --> 53:21.630]  Uh, so I guess I'd just say that I'm nervous.
[53:22.570 --> 53:32.790]  Uh, I mean, I, it's basically, here are some reasons why people are worried about the unaccountable power of certificate authorities.
[53:33.070 --> 53:40.470]  And one of them is that governments all around the world are probably applying various kinds of pressure and influence on some of the certificate authorities.
[53:40.470 --> 53:47.970]  Um, that's not the only reason that people would be anxious about whether the certificate authorities are doing the right thing, but it's one reason.
[53:48.330 --> 53:49.670]  Just one among several.
[53:51.290 --> 53:56.330]  Um, I'm lazy and I missed the first half of your, uh, presentation because I was sleeping.
[53:57.030 --> 54:07.890]  But, um, maybe, maybe you touched on this already, but can you comment, you, the previous guy kind of touched on it a little bit, but can you comment on the politics with CA inclusion on the various browsers and how that, how that all works?
[54:08.210 --> 54:10.130]  Or how you expect it to work in the future?
[54:10.790 --> 54:24.390]  Um, you could take a look at the thread about the proposal to add the China Internet Network Information Center, CNNIC, in Mozilla, and it would give you a microcosm of those politics, I guess.
[54:24.570 --> 54:26.070]  How do you expect it to go in the future?
[54:26.510 --> 54:29.130]  What, what is your, uh, what do you think?
[54:29.130 --> 54:32.790]  Uh, well, someone in the first row just called out worse.
[54:33.210 --> 54:36.130]  Um, that sounds, sounds like a good answer.
[54:36.390 --> 54:43.790]  I mean, it's, um, it's quite difficult because browsers have a lot of very complicated incentives about this.
[54:44.070 --> 54:51.790]  Because, for example, no browser really wants to be the only major browser that left out a particular root CA.
[54:52.230 --> 54:58.330]  Because then there would be sites that, um, don't work in that browser, but work in other browsers.
[54:58.950 --> 55:17.470]  And, in fact, one of my big concerns about attempts to fix many of these issues is that if a, um, site doesn't work because the browser successfully protected the user against an attack, a very likely user behavior in response is to say, I hate this browser.
[55:17.690 --> 55:19.250]  It gave me this crazy error.
[55:19.250 --> 55:21.150]  I'm going to open Internet Explorer.
[55:21.350 --> 55:22.230]  I'm going to open Internet Explorer and it's going to work fine.
[55:24.010 --> 55:24.570]  Thank you.
[55:25.570 --> 55:25.990]  Sure.
[55:26.270 --> 55:27.210]  So, thank you very much.
[55:27.210 --> 55:27.310]  Thank you very much.
[55:27.650 --> 55:28.170]  Thank you.