Hi, Professor Gerald Friedman, Department of Economics, University of Massachusetts at Amherst. And we're here today to talk about the 1%. And we'll talk about the 99% another time. But the 1%, they get about 12%, 14% of national income. They're doing pretty well. They're worth a discussion all by themselves. I recently, I think I posted this on the course PowerPoint, saw a picture of Paris Hilton's dog's house. My dog doesn't have a house, Bay Wolf here. He lives with us. If he had a house, it would be a shed in the backyard or something. Paris Hilton's dog has a mansion, a little small scale. But basically, you can have a whole family living there. And I don't mean a family of little Chihuahua type dogs. But of course, Paris Hilton is due to inherit half of a fortune of about $700 million. So I suppose she could afford to have a mansion for her doggy. It's good to be rich in America these days. It has never been this good. Nowhere do you have it as good as for rich Americans. I mean, there are rich people in other countries who can take advantage of the fact that everybody around them is really poor. The richest person in the world, I believe, is a telecommunications magnate in Mexico. And he can hire a lot of people, really cheap. But in the United States, you get the benefits of all our hospitals and universities, arts organizations, relatively clean air. And you get a huge amount of money. Give you a sense of that. Before 1984, Forbes magazine did not publish a list of the richest Americans. Starting in 1984, they started publishing their list. Sign number one, that the rich are pulling away from the rest of us. They now have a magazine listing who they are. It took $250 million to make it into the Forbes 400 list of the 400 richest Americans in 1984. $250 million sounds like a lot of money. But keep in mind, it won't get you anywhere nowadays. Mitt Romney has $250 million, so there, phew, doesn't matter. He thinks he can be elected president. By the time you see this, you'll know whether or not he made it. But to make it into the Forbes 400, you need close to a billion dollars now. And the average fortune in the Forbes 400, $1.2 billion. That's the average median fortune. That would have put you among the very richest people just 30 years ago. The rate of increase in the minimum fortune to make it into the Forbes 400 is way greater than the rate of increase in median household income. But of course, that's easy to do, because median household income for the rest of us is barely budged since the mid-1970s. While the rich have been getting most of the increase, and the higher up you go, if you look within the richest 1%, the richest 1 tenth of 1% have been pulling away from the rest of the 1%. And within the 1 tenth of 1%, the 100th of 1% have been pulling away from the rest of the 1 tenth of 1%. Who are these people? What's striking is a lot of them would claim that they're self-made. Of the Forbes 400, about 40% inherited their money, and did nothing else about it. When Conrad Hilton dies, and Paris moves into the Forbes 400, which actually she may not do. She may not have enough money if she's split with her sister. But if she did move into the Forbes 400, she would be one of those who just inherited it. 60% are, quote, self-made. Now, let's not get too excited about this. So-called self-made means that they're from the upper middle class, or from rich parents, but not super rich. Bill Gates being a good example. I mean, he went to private school. His father was a major patent attorney. They had good money, but not enough to, they weren't in the scale of the Forbes 400. That said, Bill Gates was $54 million. Zuckerberg of Facebook is held up by many people as an example of a self-made man who contributed to the world economy, and is going to work off with billions and billions of dollars when they sell Facebook. OK, good example. Private school, affluent background. He won the genetic lottery. His parents treated him well, sent him to Harvard. He had lots of opportunities. A lot of people go to Harvard. And don't get billions of dollars to show for it. So there was something special here. That raises the issue. Those who defend the 1% will say what they're getting is a fair return to all that they contribute to society. Zuckerberg will have billions of dollars, yes. But if he hadn't developed Facebook, we would all be a lot worse off. Well, actually, I question that. I kind of find this too difficult to work by Facebook page. And it takes too much time. And these notifications, I don't want to hear about it. But I'm busy. But OK, that said, you'd say the world would be a lot worse off without Facebook. Most people feel that way. He's one of the ones who contributed to that. OK, do we need to give the rich billions and billions of dollars to get them to innovate and create good things for us? And are we better off for having done that? Well, the evidence is pretty clear. And this is being one of the major issues that economists have been discussing for 40, 50 years. Higher levels of inequality are not associated with faster economic growth. Most countries have done just fine, even better than the United States, with faster productivity growth, faster income growth, without such high levels of inequality. Within the United States, the states with the highest income and the fastest income growth are states with less inequality. The greatest inequality is found in relatively backward areas of the United States, like Arkansas and Mississippi. Not in the more affluent productive areas like California and Washington state. High equality is associated with better levels of human capital development, better cooperation among people, and less waste on private security guards and all the nonsense that goes with protecting your privileges. Think about all the money we spend on security in this country. If we didn't spend all that on security, we'd be a lot better off. We need that security because we have such inequality. Without such inequality, we would have less security, less money spent on security. We wouldn't have to compete as much with each other. And that higher cooperation might actually generate higher per capita income. At least that's the experience of the rest of the world. So we'll pick up next time and talk about the 99%. Thank you.


Hello and welcome to the session. In this session we are going to discuss the following question which says that Solve for x and the equation given is For raise to the power x plus 1 the whole minus 2 is equal to 1,055 Now let us start with the solution of this question Now we are given an equation that is For raise to the power x plus 1 the whole minus 2 is equal to 1,055 and we have to solve it for x First we add 2 on both sides of the equation and we get For raise to power x plus 1 the whole minus of 2 plus 2 is equal to 1,055 plus 2 which implies that for raise to power x plus 1 the whole is equal to 1,057 Next taking common logarithm on both sides of the equation we get log of For raise to power x plus 1 the whole is equal to log of 1,057 We know that log of m raise to power n to the base b is equal to n into log of m to the base b Now using this property here we get x plus 1 the whole into log of 4 is equal to log of 1,057 Further we divide by log of 4 on both sides of the equation and we get x plus 1 the whole into log of 4 whole upon log of 4 is equal to log of 1,057 upon log of 4 which further implies that x plus 1 is equal to log of 1,057 upon log of 4 Now by using calculator we get the value of log of 1,057 as 3.02 and the value of log 4 as 0.60 which implies that x plus 1 is equal to 3.02 upon 0.60 Now it further implies that x plus 1 is equal to now dividing 3.02 by 0.60 we get 5.03 On simplifying further we get x is equal to 5.03 minus of 1 which further implies that x is equal to 4.03 Therefore we get the value of x as 4.03 which is the required answer This completes our session Hope you enjoyed this session


Western media run blatant atrocity propaganda for the Ukrainian government. This article contains reports about child rape which might be intense for some people. The Ukrainian government is quickly learning that it can say anything, literally anything at all about what's happening on the ground there and get it uncritically reported as an actual news story by the mainstream Western press. The latest story making the rounds is a completely unevidence claim made by a Ukrainian government official that Russians are going around raping Ukrainian babies to death. Business Insider, The Daily Beast, The Daily Mail, and Yahoo News have all run this story despite no actual evidence existing for it beyond the empty assertions of a government who would have every incentive to lie. A one-year-old boy died after being raped by two Russian soldiers, the Ukrainian Parliament's Commissioner for Human Rights said on Thursday, reads a report by Business Insider, which was subsequently picked up by Yahoo News. The accusation is one of the most horrific from Russia's invasion of Ukraine, but it is not unique. At the end of the fourth paragraph we get to the disclaimer that every critical thinker should look for when reading such stories in the mainstream press. Insider could find no independent evidence for the claim. In its trademark style, The Daily Beast ran the same story in a much more flamboyant and click-friendly fashion.  The one and only source for this latest spate of the Russians are raping babies to death stories is a statement on a Ukrainian government website by Ukraine's Human Rights Commissioner Lyudmila Denisova. The brief statement contains no evidence of any kind and its English translation concludes as follows, quote, I appeal to the UN Commission for Investigation Human Rights Violations during the Russian military invasion of Ukraine to take into account these facts of genocide of the Ukrainian people. I call on our partners around the world to increase sanctions pressures on Russia to provide Ukraine with offensive weapons, to join the investigation of rascist crimes in our country. The enemy must be stopped and all those involved in the atrocities in Ukraine must be brought to justice, end quote. This is what passes for journalism in the Western world today. Reporting completely unfounded allegations against US enemies based solely on assertions by a government official demanding more weapons and sanctions against those enemies and making claims that sound like they came from an it's always sunny in Philadelphia bit. We cannot say definitively that these rapes never happened. We also cannot say definitively that the Australian government isn't warehousing extraterrestrial aircraft in an underground bunker in Canberra. But we don't treat that like it's an established fact and publish mainstream news reports about it just because we can't prove it's false. That's not how the burden of proof works. Obviously the rape of children is a very real and very serious matter and obviously rape is one of the many horrors which can be inflicted upon people in the lawless environment of war. But to turn strategically convenient government assertions about such matters into a news story based on no evidence whatsoever is not just journalistic malpractice but actual atrocity propaganda. As we discussed previously, the US and its proxies have an established history of using atrocity propaganda as in the infamous taking babies from incubators narrative that was circulated in the infamous 1990 Naira testimony which helped manufacture consent for the Gulf War. Atrocity propaganda has been in use for a very long time due to how effective it can be at getting populations mobilized against targeted enemies from the Middle Ages when Jews were accused of kidnapping Christian children to kill them and drink their blood to 17th century claims that the Irish were killing English children and throwing them into the sea to World War I claims that Germans were mutilating and eating Belgian babies. Atrocity propaganda frequently involves children because children cannot be construed as combatants or non-innocents and generally involves the most horrific allegations the propagandists can possibly get away with at that point in history. It creates a useful appeal to emotion which bypasses people's logical faculties and gets them accepting the propaganda based not on facts and evidence but on how it makes them feel. And the atrocity propaganda is functioning exactly as it's meant to. Do a search on social media for this bogus story that's been forcefully injected into public discourse and you'll find countless individuals expressing their outrage at the evil baby-raping Russians. Democratic Party operative Andrea Chalupa known for her controversial collusion with the Ukrainian government to undermine the 2016 Trump campaign can be seen citing the aforementioned Daily Beast article on Twitter to angrily admonish the New York Times editorial board for expressing a rare word of caution about U.S. involvement in the war. Before writing this, the members of the New York Times editorial board should have asked themselves who among them wanted to have their children including babies and infants raped by Russian soldiers because that's what's happening in Ukraine, Chalupa tweeted. See that? How a completely unevidenced government assertion was turned into an official looking news story and how that official looking news story was then cited as though it's an objective fact that Russian soldiers are running around raping babies to death in Ukraine and how it's done to manufacture consent for a geostrategically crucial proxy war and to bludgeon those who express any amount of caution about these world-threatening escalations? That's atrocity propaganda doing exactly what it is meant to do. And that wasn't even the extent of obscene mass media atrocity propaganda conducted on behalf of Ukrainian officials for the day. Newsweek has a new article out titled Russians Targeting Kids' Beds and Rooms with Explosives, Ukrainian Bomb Team, which informs us that the leader of a Ukrainian bomb squad has said that Russian forces are targeting children by placing explosive devices inside their rooms and under their beds. Then at the end of the second paragraph, we again find that magical phrase Newsweek has not independently verified the claim. The Newsweek report is based on part of an embarrassing ABC News Australia puff piece about a Ukrainian team which is allegedly responsible for removing land mines in areas that were previously occupied by Russian forces. The puff piece refers to the team as a unit of brave D-minors while calling Russian forces barbaric. ABC uncritically reports all the nefarious ways the evil Russians have been planting explosives with the goal of killing Ukrainian civilians, including setting mines in children's beds and teddy bears and placing them under fallen Ukrainian soldiers. Way down toward the bottom of the article, we see the magical phrase again. The ABC has not been able to independently verify these reports, but they back up allegations made by Ukraine's president. Oh, so what you're being told by Ukrainian forces back up what you're being told by the president of Ukraine. Doesn't get any more rock solid than that, does it? Great journalism there, fellas. The Ukrainian government stands everything to gain and nothing to lose by just saying whatever it needs to say in order to obtain more weapons, more funding and increasingly direct assistance from Western powers. So if it knows the Western media will uncritically report every claim it makes, why not lie? Why not tell whatever lie you need to tell in order to advance your own interests and agendas? It would be pretty silly of them not to take advantage of the opening they're being given. The mass media have been cranking out atrocity propaganda about what's happening in Ukraine since before the invasion even started, like when they reported in February that Russia has a list of dissidents, journalists and vulnerable populations, such as religious and ethnic minorities and LGBTQI plus persons, who it plans on rounding up and torturing when it invades. Funny how we just completely stopped hearing about that one. And this is all happening at the same time the Western political media class continues to shriek about the dangers of disinformation and the urgent need to strictly regulate its circulation on the Internet even after U.S. officials came right out and admitted that they've been circulating disinformation about Russia and Ukraine. I guarantee you none of these completely evidence-free claims will be subject to censorship by the fact-checkers of social media platforms. The fact that both Silicon Valley and the mainstream news media accepted it as a given that it is their job to manipulate public thought about this war tells you everything you need to know about how free and truth-based the so-called liberal democracies of the Western world really are. We are being deceived and confused into consenting to agendas that could very easily lead to nuclear armageddon. And if we ever raise our voices in objection to this, we are branded Putin propagandists and disinformation agents. It's getting very, very bad. Turn around, people. Wrong way.


Hello viewers. Welcome to my channel. You are going to learn about how to insert rows and columns and Google Sheets. Select the row where you need to insert the row, then right click on it and select Insert one row above to add a row above the selection or insert one row below to add a row below the selection. Now I select Insert one row above. You can find that one row is inserted above in the same way I try to insert one row below. Now you find one row added below. In a similar way select the column this time. Right click on it and select Insert one column left. Now you can see that one column adds to the left. That this time I select Insert one column right. Column adds to right. Using a keyboard shortcut to insert rows and columns.  Press all plus h plus i plus c to insert the column. You have learned in this video about how to insert rows and columns in Google Sheets. Thank you for watching this video. If this video is useful, consider to subscribe my channel and don't forget to like and share the video. Thank you.


Hello everyone, welcome back to another Illustrator 2023 tutorial. I'm going to show you how to rotate images, rotate shapes, how to change your anchor point position or your access point position and also how to rotate your canvas. It's a really, really, really useful set of skills. Let's rotate everything.  You can just see here if you hover over with your selection tool over here, top left, black arrow, when you hover right outside you see that I can rotate the image very similar to what you can do in Photoshop. The second thing you'll notice is if I hold down the shift key, I can rotate in 15 or part of me 45 degree increments. So you get nice fixed amounts as opposed to the loose free transforming type style where you get parts of degrees. Okay good.  I'm going to click right here and then I'll see what about anything right here and now watch I'm rotating around that anchor point. So this is how you change the anchor point. Finally, for those of you that want to rotate the canvas, especially for you artists that are doing some drawing or tracing or whatever you're doing, head over here to the hand tool, hold it down and then switch now to the rotate view tool or shift H but you can just get it this way. Now watch I'm just rotating the actual canvas. That's all you need to know inside Adobe Illustrator 2023.


Fun fact, I recently actually changed my name, so I was hoping I would not get any more Game of Thrones references. So thanks, guys. Just kidding, it's fine. So I'm here from the Chrome security team. And I'm here to talk to you about HTTPS and why we think HTTPS should be everywhere and what we're doing to help you migrate your application. I want to start with a scary story. So imagine that you are a developer working on the Google search home page. Cool job. And Google is famous for being such a perfectionist about the search home page. Down to every pixel, down to the shade of blue for the best user experience, maximizing conversions, maximizing the number of eyes on ads. So if you were a developer working on this project, imagine how horrible it would feel if this is what your users saw. So what we're looking at here is some iteration of the Google home page with this really ugly third party ad injected. And this might be injected by some unwanted software on the user's machine, or it might be someone on the network like a Wi-Fi provider or an ISP injecting ads. And how horrible would it feel if this was your site that this was happening to? I mean, this is terrible. It's bad for your business, because fewer users are going to search. They're going to get distracted by this ugly ad. They may not have as many impressions on the legitimate Google ads. And it's a terrible user experience. It's distracting. It's ugly. And it can actually cause direct harm to the user because they're going to click on this ad, maybe even thinking that it's from Google. And as a result, they might end up with unwanted software on their machine, for example. So this is pretty bad. And I can imagine that if you put all this time into your user experience, this is not what you want to happen. But maybe you're thinking, OK, it's just like an ad. It's maybe it doesn't matter that much. There's this ridiculous disclaimer that I'm sure two people in the universe have read and actually made sense to them. So the question is, what other harm can come from a lack of security and privacy guarantees on your site? Let's look at another example here. This is a famous demo from a security conference called DefCon. What you're seeing here is an attacker eavesdropping on a Wi-Fi network and displaying for all the world to see all the sensitive user data that goes across the network in the clear. In this case, it's passwords. You can also imagine it might be credit card numbers. Or even the content that a user is reading can be sensitive and something they wouldn't want broadcast. If you're reading about a sensitive medical condition, you don't necessarily want anyone on the network to see that that's what you're doing. So today, what I'm going to be telling you about is a protocol called HTTPS, which can help you guarantee the security and privacy of your users and also the integrity of your content. And I'm sure you all have seen HTTPS before. When you go to Google and you see HTTPSGoogle.com in the address bar and you see that green lock, I'm going to be talking a lot about the green lock today. What we're doing on Chrome is trying to make it as easy as possible for you to migrate your site to HTTPS because we think it's important that every site today uses HTTPS. Let me tell you first about the properties that HTTPS gives you to help motivate why you want this on your site. First, an attacker should not be able to read the data that goes between the browser and the server. This is a pretty straightforward property that hopefully all of you want for your users. If your user enters a password into your site, an attacker shouldn't be able to see it, a credit card number. An attacker shouldn't be able to see the content that a user is reading on your site. In other words, no snooping. Everything should be private between the browser and the server. The second property that HTTPS gives you goes back to that ad injection I showed. And it's about tampering with content. When you use HTTPS, an attacker can't modify the content, such as injecting ads that goes between a browser and a server without that being detected and the connection being closed. And the third property that HTTPS gives you is that you know who you're talking to. So if you type HTTPSgoogle.com into your address bar, the server presents a cryptographic proof of identity saying, this is who I am. I'm Google. And it proves that you're talking to Google rather than some attacker who's trying to impersonate Google. So these are the three properties that HTTPS gives you. And hopefully, I've convinced you that these are properties you want on your site, whatever type of site you may be running. It's good for your user's privacy and security to protect their private information. It's good for ensuring that the content that you deliver is what they actually see, not some modified or tampered with content by someone on the network. And increasingly, as Alex alluded to, it's what you're going to need to do to use the increasingly powerful web platform. So what I mean by this is new powerful web platform features. Within the next year or so, Chrome is going to start requiring HTTPS to use those features. And this makes sense if you think about it, because using these features can compromise users' privacy and security, which is why we do prompts like this to make sure that the site that you're talking to is the site that can have access to your camera, not just anyone on the network. So in order for questions like this to be meaningful, we need to require HTTPS for using these powerful web platform features. Now, you're all web developers. You may have even set up HTTPS before. I hope some of you have. And these days, it's actually not too hard. The first step you do is you buy a certificate, which is that cryptographic proof of identity. And you configure your server to use that. And there are a number of tools out there today to help you with this. So I'm showing you one here called SSLmate. That is a really easy command line tool to help you buy a certificate and configure your server with it. And this is not what I'm going to be talking about today, because there are these great tools out there. And it's hopefully not too complicated to get HTTPS set up out of the box. What I'm going to be talking about today is the next step.  It's easy to look at this list and just feel totally depressed. It's easy to think, why should I do this? I have no hope of actually getting a solid HTTPS configuration that's going to give my users the privacy and security benefits that they need. That's what we're working on in Chrome. We're working on projects from developer tools, web platform features, reporting mechanisms to help you discover problems that your users are hitting in the wild. All of these projects are designed to make it easy to migrate to HTTPS, because we want every site to do that. So this is what I'm going to be talking about today. The projects that we're doing to help you get set up with HTTPS with a solid configuration. And I'm going to divide this into three sections. First, I want to talk about that lock icon, the overall indicator of the security status of your page. Because if we want developers to migrate to HTTPS, they have to understand what they're shooting for. And I'm going to tell you about browser tools we're building to help you understand that. Next, I'm going to talk about some web platform features that help you migrate your application in a way that you get the green lock. Because especially for large scale sites, it's not just a matter of turning on HTTPS. It's very much a matter of migrating your application. And the web platform can help you with that. Finally, I wish I could tell you that the green lock is all you need to think about. But it turns out there are a set of best practices that we recommend you follow even after you get to the green lock. And so I'm going to tell you about some of those and what we're doing to make it easy to roll those out. So let's start here with understanding the lock icon. And first, I want to show you that it's hard to understand.  It's green, or it's red, or it's there, or it's not there. But it's actually really complicated. And I get confused about it all the time, and I work on it for my full-time job. So first of all, we have the neutral state. So this is what you see when you visit an insecure HTTP site. It's this kind of neutral page indicator icon. And there's really no indicator of security or lack thereof at all. So right off the bat, I hope this is a little confusing to you. Because why is it neutral? There's no security here. Why should this be neutral? It's saying to the user, everything's fine. Don't really need to think about it. But in fact, it's not fine. There's no security or privacy whatsoever. So what we're doing, and you may have heard about, is that over the next year or so, we are going to be gradually introducing a negative security indicator for this state. So that when you don't have HTTPS, your site will be marked as kind of a negative state rather than a neutral state. Because we want users to expect HTTPS as the norm and see insecure HTTP as an exception. So that's a little bit of a tangent. I'm showing you the neutral state as it is right now. Then there's the green lock state. This is what you're shooting for. This means you have HTTPS set up. Everything is good. From Chrome's perspective, we can mark this as a secure connection. All right, then there's this kind of intermediate state. And this is when you have HTTPS. So the page was retrieved over HTTPS. But Chrome noticed some problems with it that is stopping us from marking it as fully secure. And there are a number of conditions that can lead to this state. You might also be used to seeing this as a lock icon with a yellow badge. That was how it was shown until recently. But we recently started marking this as neutral instead of that yellow badge because we thought it was less confusing. So this is this kind of intermediate compromise security state, a number of things that can cause you to fall into this state. And then a similarly confusing one is what we call the red slashy lock icon of doom. And this means that something is really wrong. So in this case, your certificate might be expired, or you might have the wrong certificate, or there might be some really insecure content on the page. There are a large number of things that can cause this to happen. So understandably, when developers see these lock icons, they get confused. They might not know what the lock icon means, and they might not know why that's showing up on their page when they expect to have a nice shiny green lock. That's why we are introducing a whole new panel in developer tools whose sole purpose is to help developers find and fix problems with their HTTPS configuration, understand what's going wrong, and get to a shiny green lock. So this is on Canary now and on Dev Channel. And I'm going to show you a little sneak peek here. This is what it looks like. You can see it's its own panel in developer tools. And let me just walk through a few of the things on here. First, we have the overall security status of the page, kind of lining up with the lock icon. In this case, we're looking at a page that's in that kind of intermediate state where the page was loaded over HTTPS. But there are some problems that Chrome noticed that prevent us from marking it as secure. Now, another thing that we're really excited about, that we can use the security panel for, is helping you keep up to date. Because as much as we wish that HTTPS were something you set up and then you kind of forget about it and you're good for the rest of the time, that's not the reality. You have to keep up to date because there are constantly new crypto systems being broken, new algorithms being standardized. And the security panel is where we're going to help developers keep up to date so that their configuration stays modern. Another thing we see here is information about the security properties of sub-resources. And this is really important because if an HTTPS page loads sub-resources over insecure HTTP, that can compromise the security of the whole site. So we're going to use the security panel to show you information about sub-resources that might have been loaded with different security properties than the main resource of the page load. And you can see there's that link there at the bottom to click into the network panel so that you can see more details with the network panel that you're familiar with. So as I said, this is on Canary now. And also, as I said, its whole job is to help you figure out this landscape and make sense of it. We really hope that you try it. And if you do, feel free to shoot me an email or a file bug if you have any feedback at all because you're the audience for this feature. So the security panel is what we're doing to help make HTTPS more comprehensible to developers, help them understand what the green lock icon means and how they can get there. But especially for large sites, the security panel is not going to be the whole answer. So imagine that you have a site with hundreds of thousands of pages of content. Many of you probably do. And there may be problems on some of those pages, maybe just a few of them. And it's really hard to track those down when you migrate your whole site to HTTPS. You're not going to open every single page and look at it in the security panel for problems. So I want to tell you about some web platform tools that can help you here. What we hear from developers, especially on large sites, is that a problem called mixed content is one of their main challenges when migrating to HTTPS. Mixed content is this problem I was just talking about, where you have a main page loaded over HTTPS, but you have sub-resources loaded over insecure HTTP, which can affect the security of the whole site. So those insecure sub-resources are called mixed content. What you're seeing here is the Chrome UI when the page is loading, say, an image or other what we call passive content over insecure HTTP. So you can see you're in this intermediate state. You don't get a lock icon. We don't give a lock icon when you have passive mixed content on the page. And we have these strings to help tell the user that there's something wrong. Maybe they shouldn't trust this site fully because there's a problem with its security. So this is what happens for passive mixed content. And you can imagine if you have hundreds of thousands of pages with a bunch of images on them, it can be hard to track down any image that's loaded over insecure HTTP. Here's another type of mixed content, active mixed content. So if your page tries to load a script over insecure HTTP, Chrome and other modern browsers will just block it outright because it's just too dangerous to run an insecure script on the page. So you'll still get the green lock icon. And you might not even notice that anything is wrong here. But a user might run into some subtle way that your page is broken.  And if they click on this shield icon, they'll get an option to load the insecure script. And if they do that, then they're going to end up in the red slashy lock icon of doom. And this is what you don't ever want on your site because it means something is really broken. And Chrome can't make any security or privacy claims to the user. This is the case of active mixed content. And again, it can be hard to find this on your site if you have a huge site. So the web platform offers you a way to get notified of mixed content whenever it runs on your site. And this is handy because if your user runs into any of these situations, you want to get notified about it so that you can find it and fix it. The mechanism for this is called content security policy. And content security policy is actually a much more general mechanism. But I'm just going to talk about a few specific uses of it here. So content security policy. It's a header that you send on an HTTP response from the server to the browser. And what the header says is that you want to receive reports whenever content is loaded from not HTTPS. So you can see it has this report only in the header name. That means it's not going to actually affect how the page is loaded or runs in the browser. It's only going to mean that when non-HTPS content is loaded, you'll receive a report about it. In other words, if a user lands on mixed content on your site, you will find out and you can fix it. I want to give a shout out to this cool service called reporturri.io. And this is a service that can collect and help you analyze your mixed content reports. So you can sign up, and then you get a URL. And you can put that URL in your content security policy header. And then your reports will go to this site, which will help you analyze and collect them.  OK, cool. So we have a way to find out when a user runs mixed content on our site. There's one step further that you can go. Suppose that you actually don't want any mixed content to ever run on your site. You want it to be blocked entirely. But if that content is loadable over HTTPS, even if the URL itself in your HTML is HTTP, wouldn't it be great if the browser just loaded it over HTTPS and didn't wait for you to go find and fix and update that link to HTTPS yourself? It turns out you can use content security policy for this, too. So in the same way, you can send a header from the server to the browser. And this header says that you want to upgrade insecure requests. So you notice it doesn't say report only anymore, because this is going to actually affect the behavior of the page as the browser loads it. What this is going to cause the browser to do is, any time it sees a sub-resource with an insecure HTTP link, it'll automatically rewrite that to HTTPS. And you can imagine this can be really helpful. So for example, you have a huge site, and you don't want any mixed content to run on your site. But you load a lot of your sub-resources from a CDN. And if you know that a CDN supports HTTPS, you can just send this header to make sure that those sub- resources automatically get upgraded to HTTPS, because it can be a massive engineering effort to go actually find and update all your links. So these are some web platform tools that can help you get to that green lock. And we want to make it as easy as possible for you to get there, because the green lock is kind of the bare minimum, saying that you have the security and privacy guarantees of HTTPS for your users. But as I warned you, at the beginning, it doesn't end there. There are a number of best practices that you can use to get even stronger security and privacy guarantees or to avoid kind of loopholes in your application that allow an attacker to get in.  The first tool in my grab bag is super simple. Protect your cookies. If you run a site where users log in, the session cookie that you set on login is among the most sensitive data that goes between the browser and your server. Because if an attacker steals that cookie as it goes over an insecure connection, they've basically stolen your user's entire identity on your site. So it's really important to protect your cookies and prevent them from being sent across insecure connections. And this secure attribute on cookies basically does exactly that. It says to the browser, this is a sensitive cookie. Don't ever send it except over. And it's a secure HTTPS connection. So once you set up HTTPS, you should add this secure attribute to all your cookies. It's super simple. Trick from grab bag number two. Also really simple. I call it always HTTPS. Imagine that your user lands on a site. And that site links to your site. But the link is over insecure HTTP. If the user follows that link, it's kind of game over. Because an attacker can intercept the response and do whatever they want. And at that point, basically, all bets are off. What you want is for that link to always go over HTTPS. So any time a user visits your site, it's HTTPS only. And this header called strict transport security is exactly how you guarantee that. So you tell the browser, I want to be always HTTPS. And the browser will remember that. And any time a request goes to your site, it'll be over HTTPS, even if the user is following a link that says insecure HTTP in the HTML. Also pretty simple, right? There's one more problem that I want to tell you about instead of best practices to address it. But it's a little more complicated. So let me explain the problem here.  What is a certificate? It's a cryptographic key pair, which has been signed by another cryptographic key pair, which has been signed by another and so on, chaining up to what's called a root certificate authority. And this chain is a certificate chain. That's what we call it. The problem that we're trying to address here is that there are actually hundreds of root certificate authorities that are trusted by every single laptop and phone and browser and OS and so on. So if any single one of those hundreds of trusted root certificate authorities is compromised, goes rogue, has an evil employee, that rogue CA can actually issue a certificate for your site. And by default, it'll look just as legitimate as the real certificate for your site. So basically what I'm saying is that there's a large attack surface here. If any trusted root certificate authority is compromised, that can start issuing certificates for any site. And we call that a mis-issued certificate. What we want is for the browser to be able to recognize a mis-issued certificate from a legitimate certificate. It should see this certificate, which has been issued by an evil CA. And it should somehow be able to know that this is not the legitimate example.com certificate. This would be great. This is a real win for security. And Google has two efforts underway to address this problem. I'm going to tell you briefly about the first, because it's a whole talk in itself, and then a little bit more about the second. The first project is called Certificate Transparency. Really cool, ambitious, exciting project. And the goal is to log all certificates publicly. In a way that can't be modified or tampered with or removed later. So the end goal here is not necessarily that a browser would be able to recognize in real time a mis-issued certificate from a legitimate certificate.  They're public. Anyone can monitor them. So you can monitor them and watch for certificates that have been mis-issued for your site. And then you can take action on that, like revoking, asking the CA to revoke the certificate. So this is a really big project. If you want to kind of take matters into your own hands now, there's another tool that we have called public key pinning, which we tend to recommend for more security sensitive sites, sites that have a little bit more operations experience with HTTPS. And it'll become clear why that's who we recommend it for in just a minute. So let me explain what this is. And again, the goal here is to get a stronger form of HTTPS by allowing the browser to recognize a mis-issued certificate from a legitimate certificate. Public key pinning is a way for a site to describe to the browser, this is what my certificate change should look like. And if you ever see a certificate change for my site that doesn't match this description, then that's bad. Close the connection, don't allow it. Something fishy is going on. It's pretty cool. It's like many of the things I've talked about today. It's an HTTP header that the server sends in a response to the browser. And it contains this kind of syntax that describes the certificate change, what the certificate change should look like. Now, the problem is that, unfortunately, this is a little bit hard to do right. And it's quite easy to make a mistake. So this way that you describe a certificate chain, it's hard to do it in a way that all clients will reliably match your certificate chain to that description. And what happens if you get it wrong? If you get this description wrong, it's sort of like performing a denial-of-service attack against yourself. Because users are going to see these pins. They're going to say, oh, this is what the certificate change should look like. And then this actual chain is not going to match that description as they see it. And then they're not going to be able to access your site. So that is a sad situation. And that's why we tend to recommend public key pinning for sites that have more experience operating HTTPS and are particularly security sensitive. So they will really benefit from the added security that public key pinning provides. However, recently in Chrome, we rolled out a new feature that helps make this more accessible to sites that don't have giant operations teams, for example. So this new feature is called violation reporting for public key pinning. It's sort of like a practice mode. So instead of rolling out with this public key pins header, you roll out with the report-only version of it. And you specify, like with mixed content reporting, you specify a URL. What this means is you're not saying this is what my certificate change should look like and close any connections that don't match this description. Instead, you're saying, hey, I'm in practice mode. This is what my certificate change should look like. But if I've messed up and there are clients who can't actually validate my certificate chain in a way that matches that description, then don't close the connection. Just send me a report about it so that I'll know that there's something wrong and I need to make an adjustment before I roll out for real. So this makes it easier to deploy public key pins without fear of dosing your site. And even after you go into enforcement mode, so you can see I've dropped the report only here, this is a real pin that will be enforced and cause connections to be closed, you can leave the report URI in there. So if something is going wrong, you'll get a report about it even after you've gone live with real public key pins. All right, I've talked to you about a lot of things today, about developer tools to help you understand the HTTPS landscape, about web platform features to help you get to a green lock, and about a set of best practices to make sure that your users are really getting the best of HTTPS. I want to pop back up a level, because even though we're trying really hard to make this easy for you, it is going to take time and energy on your part. So I want to remind you why it's important. So I showed this scary story about some injected ad just totally messing up your user experience. And this is terrible for your business, it's bad for your site, bad for your user's experience, and it can directly harm your user, because they might think that this content is coming from you, and take actions or make decisions that they wouldn't otherwise. Moreover, it's the way the web is going. Chrome is going to start requiring HTTPS for powerful web platform features, because it's the only way for your site to use these features without exposing your users to harm. So that's why we think HTTPS is the future. We want to see it deployed on every site, and we want to make it as easy as possible for you to migrate. All right, thanks so much for listening. If you have any questions, feel free to contact me on email or Twitter. Thanks.


Okay, so we're here with Maze Hunt and let's see how this is going to be done. Okay, so for the benefit of everyone, I'm gonna be skipping Scenes here which we are going to be Talking so starting off you're gonna be leading this ghost into a chase up until You are able to This blue thing here Just skipping all these This is actually a banner guys a banner. It's a barrier. Sorry. It's a barrier which you'll be activating I'm just gonna skip this before you go to the next barrier. I would suggest you have a detour here and get this one this blue thingy here Just gonna skip a story here and And once you get this the experimental manual you're gonna be awakening this guy here, so He's gonna be chasing you Yeah, I have to lead them to the barrier here Once today you enable the barrier you won't be able to reach you then go up and Get this manual as well skip then once you're done with that this ghost will be Following you as well up until this Banner here so enable banner as well then You can go free That is it guys Successful clear for MZ03 so thank you. Stay safe. See you in the next one


Alright everyone, the title of my talk is indeed Black Ops to PKI. I think I owe everyone an apology for not having the talk title in the DEF CON description. I just really felt, you know, I don't need another like couple months of drama around what the talk is or what's actually in it, like forget it. I'll just say nothing, have a nice quiet month of July, it'll be great. Anyway, so hi, I'm Dan, not actually a black hat, sorry about that, but this is my 10th talk here at DEF CON. I do kind of a foundational thing like SSH and DNS and same origin policy and DNS and pattern recognition and DNS. So there might be a bit of a theme to the work. This year I'm really kind of looking at authentication. There's something of a crisis going on right now with authentication. Vulnerability is an ode, get all the press, but according to the actual data, 60% of actual real world compromises, not volns, not ode, but just no passwords, bad passwords, default passwords, stolen passwords, my passwords. Yeah, drink does not even begin to describe fail. Oh dear, so here's the deal, passwords are used because they scale really well one at a time.  So passwords over time, passwords over multiple hosts.  So there are two schools of thought about what to do about this. The first school of thought is we can totally make passwords work if we machine generate them and we cycle them fast and we literally use LeetSpeak as a security technology. It doesn't matter what you do because ultimately as Shania noted, you're still vulnerable to a key log no matter how good your actual password is. So what a lot of people want to do is they want to eliminate passwords entirely and if only we could get humans out of the memory business. We have hardware that has lots of memory, gigs of memory, computational power, why can't it do it? And what we were supposed to be using to do this was public key infrastructure with X509 based technology. We've been hearing this for a while. The kind of vibe I keep hearing is if only we cared enough we could stop using passwords. Everyone would have smart cards, it would be great. Just people need to care. I found on the internet the greatest image of all time that explains what's going on here. The only description I can come up for this photo is if we just had a big enough care bear, we could totally ride this pony. No. Look, business has cared enough about PKI to invest in hundreds of millions of dollars in it in the last decade. It's not working. I have a theory. I think what's not working, it's not the business guy's fault anymore.  X509 is just not the appropriate technology to solve the problems we need to solve to fix authentication. So, I do think we need to rethink the foundations of internet security. I want to point out I'm not one of those guys who says we should build a second internet. That's unlikely. Yes. I was trying to be kind. Look, it's like building a city without roads or highways in the middle of a forest saying, but it'll have great mass transit. It does not make up for the fact that it's not going to work. You have to integrate with existing life. But by the same token, what we're doing now, it's not working. We should talk about why. So, the warning is, of course, look, there's a lot of business stuff going on. The first couple minutes of this talk aren't that late. So, as a preview, I did show up at DEF CON with a cert for DEF CON. It is real. I can't tell you who issued it, but Jeff knows. You can bug Alex Sodorov as well. And it could actually be a cert for anything. In fact, it could be a universal wild card certificate as well. So, at the end of the day, we do end up bypassing the system. Now, let me give you the kind of basic version if you're not that familiar with X509. X509 is basically the digital version of, or when it's implementation wise, of passports. Look, you got a private key, you got a face. You got a public key, it's your passport photo. You have a subject name, your name, a certificate authority, which is the country you live in, a certificate, which is a passport. All we're doing is saying, look, if you have the face that's in the photo, and it's on a card issued by your country, then you have the name of the person on the passport. X509, that's all it's doing. This is the digital version of allowing someone else to assert your identity via a combination of a difficult to fake element, your face, and a name that actually can be used as a handle to communicate with you later. So, it pretty much has only one really good success story, that'd be SSL. This is the technology behind HTTPS or the web. There was a heroic work done in the mid to late 90s that said if you want users to put their credit card number on the internet, they need to use actual good cryptography. This was miraculous that this actually happened. It by far has been the greatest success story for actual strong cryptography. That being said, there's only about a million SSL endpoints. There are hundreds of millions of nodes on the internet, and most of them have no encryption, or actually arguing whether or not cloud-based applications should have to encrypt a link from the client to the server. So, don't think this is a battle that's been won or doesn't need to be refought. Now, here's how you actually end up acquiring a certificate. This is basically a blob of data that asserts that you are your website, so you have a certificate for a website, www.defcon.org. This is a cryptographic assertion that you are indeed talking to DEF CON. The first thing that happens with getting a certificate is you've got to go to DNS. Everyone always forgets this phase, but at some point, Jeff Moss had to go get a certificate from... He had to go get a domain name of www.defcon.org. And when he did that, he actually registered himself as the administrative contact for DEF CON. Next step is to generate a public and a private key pair. These are mathematical objects, large prime numbers multiplied. They are the equivalent of web server needs to have a face, and your web server needs to then take a photo of that face. The public key is provided to a certificate authority along with the name of a website registered in DNS. Now, this is done with what's called a PKCS number 10 certificate signing request, or CSR. The certificate authority. Okay, it's received a public key, it's received a name. How does it know it should actually assert an identity? Why should it go ahead and say that Jeff is DEF CON, or that I am DEF CON, or that Len is DEF CON? Well, the way this is actually done is they send an email to the address that was in DNS at the beginning. There's an exception, hang on for a bit. This is basically them saying... This is basically them saying, is this passport photo actually you? Well, let's go to DNS and find out. Next step, click the link provided in the email, so you get an email at that address, you click the link and that asserts a link between what was registered in DNS and that you are now able to go ahead and get a certificate for that name, and then you get the cert. Now, I'm oversimplifying a little. What I just described is called domain validation. There are many certificate authorities that offer much more stringent validation. They'll do what's called a done's business lookup. They'll do phone calls. There's apparently great news for me. I can go till 8 o'clock. I can relax. But I have no beer. Can someone... No. So, just ascribe it's called domain validation, there are certificate authorities that are much more paranoid about actually issuing a certificate because they're basically vouching for you. They're saying, yeah, you are DEF CON. You are Yahoo.  And we're going to do serious lookups. We're going to use a done's business lookup. We're going to call you.  But it doesn't matter. X509 has a fundamental limitation in that it cannot exclude without great pain. Now, what do I mean by that?  All of them can issue names, even if someone else... All of them can issue certificates for a name, even if some other one of them already has. There is no exclusion. So this is the direct equivalent of Zimbabwe being able to issue American passports. I'm not saying I have a problem with Zimbabwe, but I'd like America to be the only one who can issue an American passport. I'm just saying. So even if your CA runs you through the ringer, that doesn't mean that every other one will. The security of the whole of any X509-derived system is equal to the security of the weakest link. Unfortunately, anything more is security theater. So there are many good, many responsible, very responsive CAs out there. X509 does not allow the good CAs to offer a better product than the not-so-good ones. The technical term, this is a race to the bottom. But now let's look at DNS. DNS, by complete contrast, is very good at excluding. The root. First off, there's one root. Not 50, not 100, there's one root. There's a classic quote about certificate authorities, where the CA system is only as secure as the money they refuse to take. The root will not actually take your money. You can't register something in the root. They are an adjunct to the state system, and you can't just buy yourself a country. So that's just the reality of it. So the first level, very exclusionary, very good. The second level, the registries. Yes, you have COM, yes, you have NET, yes, you have ORG. But there's one company who is responsible for each top-level domain. Verisign has exclusive control over COM. Affiliate has exclusive control over ORG. When one of the top-level domains had a serious problem with large amounts of malware, this was not a problem that was distributed across lots and lots of different organizations. This was not a problem where there was no accountability. No, that registry had to fix their stuff or their product was going to be blocked, and so they fixed it. That's awesome. The third thing that the DNS system has, which is very elegant, look, we have these things called registrars. These are the actual companies that you interact with when you're trying to put something into DNS. If I register www.doxbear.com through Network Solutions, they have exclusive control over my domain. If they screw up, if I decide they're not very good, I can go ahead and move that domain over to Enom or over to any of another bunch of companies. And Network Solutions, I'm no longer exposed to whatever vulnerabilities they might have. Look, this is the ability for me to manage my risk. Recently, I think Microsoft had their New Zealand sites hit.  Microsoft was in the position of being able to move their domains from the crappy place with SQL injection to potentially somewhere else and not have to worry about the problem anymore. That is also awesome. We need the ability to have accountability in the systems that we use. I love the CA system. You wouldn't believe it, but it's awesome having a lot of people out there who are trying very hard to deploy a secure product. But at the end of the day, they can't help me like this. I can't say I only want this CA to be the only CA who can issue names for me. The underlying technology has a problem. Now, it is actually possible to do Exclusion in X509. It is possible to basically run your own certificate authority. This is what every enterprise is told to do. Run your own enterprise CA and that's how you'll manage your trust in your organization. On its own, it's very expensive, very difficult to maintain, and every single time it hits the exact same failure. Oh my God, there are other people out there and they need to authenticate them too. So how do I deal with all of the other private CA's that are out there? How do I federate? The one successful federation in the world for X509 is the Federal Bridge CA. My God, it works. This is amazing. The people behind it who made it work deserve a medal. The rest of us need a system that you don't deserve a medal if you actually get it to work. Interruptibility with other organizations was thought to be an optional thing. We won't often need it. And it turns out it's just not true. In theory, you only need to authenticate your own organization. Usually your house key is only used for your house. Reality, cross-organizational authentication is the rule and not actually the exception. We have partnerships with other companies. We have interactions with other groups. Who thinks a large company is just one large company has never actually worked in a large company? You are dealing with group after group after group. So this is one of the reasons why passwords work.  This X509 stuff isn't. So X509 cannot delegate either, at least without great pain. Every time I need a new certificate for a node in my organization, I have to go ahead and talk to an external CA, another company, and I have to get a certificate for that particular node. Every single operation that's completely internal, I need to keep jumping across the fence to some outside company. This is expensive. This is operationally inconvenient. There are potentially information disclosure issues, and it interacts very poorly with devices. There are hordes of devices in all of our organizations, all of them have DNS names, none of them have anything more than self-signed certificates. So we were supposed to have this thing called name constraints, and what name constraints were supposed to let you do is they were supposed to let you sign for star.docspara.com or star.this.com or star.that.com. They were supposed to allow you to get a delegated portion of the namespace, and that would be your portion and your tool to work with. There's very weak support for this in the field, so you can't actually buy it. The technology just wasn't deployed sufficiently enough to depend on. Now, there's another option you could do. You could get a wildcard certificate, get one certificate, same certificate for all of star.docspara.com, and now you put the same crypto key on every device in your organization.  That is a technological limitation that has just failed. DNS delegates fine. The root delegates to verisign for calm. Calm delegates to my servers for docspara.com.  I don't have to talk to other organizations. That is why all my devices are in DNS, and very few of them are in SSLX509. Now, it is, in fact, possible to delegate X509. There is serious demand. Here's what happens consistently. You have a company. They spend a couple million dollars, or some absurd amount of money, on their own internal certificate authority, and then they find they don't work with anybody else. They say, what do we need to be able to work with everybody else? And CAs come back and they say, well, you kind of just have to come and talk to our website. Companies are like, no. We want our certificate authority to work with other companies. CAs say, well, that would be really insecure. I signed certificates for Bank of America and this and that. And the company says, I don't care. I want it to work. So the CA says, fine. Sign a contract promising you won't abuse the big magic cert, and we'll just give it to you. I promise is not an acceptable security policy.  You can just buy one. It's not that the companies don't take security seriously. It's that the underlying technology forces this particular failure mode. So 2008 was not a good year for this system. Mike Zestman did a whole bunch of work against production certificate authorities. Bypass Komodo's security check by claiming that he had this really cool internal server called www.live.com. Thus it wasn't subject to validation checks. Also bypassed StartCom's checks with some web bug. Well, I broke it as well. As I told you, SSL ultimately takes a dependency back on DNS, and we know how that ended up. But interestingly enough, Avi Pilosov, actually, he did his whole thing with BGP last year. And so he showed that he could actually sniff arbitrary traffic from arbitrary locations on the internet if he had ISP level access. Well, that means he can sniff SSL validation emails as well. So, he wins. But the big hack last year was Steven Soterov versus MD5. And what their trick did was pretty cool. When a certificate authority or country deems you worthy of a certificate or passport, it signs, creates a passport with a hologram, your public key, your photo. Now, signing requires two steps. First, it requires securely hashing the certificate. This is summarizing it to a small number of bits. A hash is considered secure if it's difficult to find two files with the same hash. Secondly, once you have this summary of bits, that's what you go ahead and sign with a certificate authority's private key. So it is actually the summary that, you know, like a photo is a summary of your actual face. That's what the signing is sticking a hologram on top of it. Now, the problem was that RapidSSL, one of the CAs out there, was using MD5 as its hashing algorithm. Now, MD5 is not secure. We've known this since 1996. We're still using it. So, Steven and Lenstra actually went ahead and created what was called a chosen prefix collision attack. Now, in this attack, given two different beginnings, they were able to create a blob that if you attached it to both of these beginnings, which could be anything, would cause them to unify into the same hash, into the same summary. So the attack was that they had a certificate authority, sign a certificate that looked completely innocent. It was a completely valid certificate for, you know, some very long domain name that Stevens and Sodorov had. Sodorov then went ahead and shifted out the innocent content, replaced it with an intermediate certificate that could sign for anything, replaced it with a God cert, if you will. And because of the chosen prefix attack, the summary of the innocent version was equal to the summary of the God cert. Doing this also required some really interesting timing work to get the serial number of the CA also correctly predicted. Now, there's more where that came from. Finally, we can actually talk about the actual security data. So the more where this came from, it turns out X509 is really, really fragile at pretty much every depth that it's examined, pretty serious ambiguities and risks are found. Consider hashing functions. We all know at this point that MD5 is a valid signing algorithm for X509 certificates. What you may not be aware of is that MD2 is also supported. MD2 is a predecessor function to MD5, now known to be even less secure than MD5. If a certificate happens to be signed with MD2 RSA, everything except the new TLS will accept it. Now, this shouldn't matter. Steven Zinzodorov required a certificate authority to actively sign specially formed blobs with MD5 RSA in order to exploit the insecurity of MD5. There's nothing signing with MD2 RSA anymore. There hasn't been for like eight years, so everything should be okay, right? Well, I have a theory. I call it the final destination theory of cryptographic vulnerabilities. Now here's how it works. Cryptovolns tend to be subtle, telegraph years, maybe even decades in advance. We don't know when they'll burn us. We don't know how they'll burn us. We're pretty sure we're going to get burned. It'll probably be epic. Thus, final destination. So we'll begin by taking a look at this. It turns out one of Verisign's core root certificates is actually self-signed with MD2. Really? It was 1996. We were young. We needed the bits. We really didn't do security very well in the 90s. Let's talk about why this matters, because this is not obviously going to lead to a problem. This is a self-signature. This is a self-signature in a root certificate. The signature means nothing, or at least approximately nothing. Len Sassman and I have an argument about whether it actually means nothing. But here's the deal. In normal X509, your public key and subject name are signed because by somebody else. This is an assertion by somebody else that you have a particular identity. When you have a self-signed signature, you're saying, I am me, and I can prove it because I say I am me. This means nothing. This has no actual security implication. The only reason I think this is there is because parsing libraries from the 90s really wanted to see a certificate there, and so they put one there. Why sign with MD2? Turns out it was the 90s. According to Peter Gutman, it may have just been that was the only thing they could get their magic hardware to do, thus proving the general rule of hardware.  RC2313 actually says, MD2 is the slowest of the three, and thus the most conservative. Not exactly what it's saying, but it's pretty close to if it's slow, that means it must be secure. Subject of insecure hashes. There are many ways a hash can fail. There's collision attacks where you can generate two things immediately that have the same hash. That happened in 2005. This is what Zhayun Wang did. There were the chosen prefix collisions, creating something that when appended to two things with different hashes, causes them to have the same hash. This is what Stevens and Sodorov did and worked very well. There's a third class of attack, and this is called pre-image attacks. Pre-image attacks say, given a hash, create something new with that hash. In other words, hi, I've got this summary from 1996. Create something with this exact same summary. Shawan, you can't do this, at least with no attacks that are being found. MD5, you can't do this. MD4, you can't do this. MD2 is starting to be another story. Here's what you do. This is the actual implementation of the attack. You generate the GodCert. You generate a new intermediate certificate that can sign for anything. That's nice. It's got a chain back to a root. Something has to assert it is valid, or the fact that it's a GodCert means nothing.  What we're going to do is we're going to give our intermediate certificate the same MD2 hash as the actual root. That means we can take the self-signature on the root, the self-signature that has at least almost no legitimate reason to be there, and we can give it a use. We can make it the signature on our faked intermediate. We can make it better. So, now the intermediate appears to be signed by the root. It has the root signature across the same MD2 hash. You have two certificates in the row with the same signature and the same hash. Works very well. Does depend on there actually being an MD2 pre-image attack. Is there one? There will be. In 2004, the complexity of doing this was 2 to the 104. In 2005, the complexity of doing this was 2 to the 97. In 2008, Soreness Thompson found an attack with 2 to the 73 complexity. Now, our best computations out now are around 2 to the 63 complexity. There's a trend going on. I actually went ahead and visualized the trend. We have two options. We can wait, as we always do in cryptography, until it absolutely blows up in our face, or we can actually do something about a cryptographic vulnerability before it fails on us for the first time in history. Yeah, we've got it.  We're all a little embarrassed about this whole, like, MD5 still being used thing. How about we at least kill MD2? And I said, okay. So open SSL, it's dead. It's out of 1.0, beta 3 for certificate validation. 098 CVS, has it also disabled. The 098 from August will also have it just completely out. NSS, the CryptoCore Firefox, this is already dead in Firefox 3.5. It's part of their 3.12.3 library. So that's good. Firefox 3.0 is getting fixed soon, some point in the next couple months, maybe. Red Hat has already updated their operating system with the latest NSS as well. Verisign, they're on board. They're going ahead and they're reissuing that certificate with a SHA-1 self-signature. Nothing's using the self-signature, but hey, at least we can get rid of MD2, finally. Opera's waiting on Verisign. Apple, Microsoft, they are testing their fixes. Google has Android disabling MD2, and GNU TLS got rid of MD2 years ago, so they're just laughing. Open source suckers, no. Now, we get to do some really, really messy things with this particular compromise. When this hits, this particular root certificate has the client authentication extended key use. SSL normally is used to authenticate a server to a client, but for very high security applications, SSL can authenticate a client to a server. This particular root has the capability of being the trusted root behind such authentication. So what that means is that you can basically say, yeah, my username is anyone, and just get in, just let me in, because my fake root says so. Then you might say, but Dan, no web server would ever trust this random Verisign root for authentication. Actually, by default, Microsoft IIS trusts this random root for authentication. You can ask, go up to IIS, use the OpenSSL as client tool, and if it has client authentication enabled, you will get this dumped at you. This is a list of CAs that are allowed to assert arbitrary identities. So the Class 3 Public Primary Certificate Authority is actually on this list. Remember what I said about exclusion?  Any of these CAs can actually do authentication to this particular host, and if we actually, when we get our pre-image attack working, this will be part of the list. This was not a capability we had with the MD5 certificate. Now, granted, the MD5 certificate actually exists, but it actually cannot operate as a client authenticator. Now, I'm kind of picking on Verisign by pointing out their root certificate. It is funny to see MD2 in your root store, but Verisign was not the only company using MD2 RSA. Lots of companies were using it up to like 2000 or 2001. Now, all the certificates have expired by now, but that doesn't matter. As Stevens and Sodorov showed, if you can alter a certificate, you can change the expiration dates. It works fine. So it doesn't matter that they've expired, but it does matter that they're gone. You know, it's been like eight years since anything has actually used this. There's not many left. There's one MD2 root that I found that is kind of epic, and most of you are not going to have any idea why this is awesome, but those of you that do will know exactly why. Rubicon, this is not... Rubicon, this is not... So there was, a few years back, one conference. One conference where the attendees, one hacker conference where the attendees were let out with their hands behind their back. That conference was Rubicon. It is rather amusing that that was the only one of the few MD2 search that I found that could still be used. So does this need to be fixed immediately? Now, it needs to be addressed, but we don't need to panic. I went to talk to Bart Praniel over at the University of Leuven. He's Len Sassmann's advisor. Len was working with me at the beginning of this and has been a great support throughout. So his response was, there's not likely to be a public pre-image attack of less than two to the 63 complexity within the next six months, even with this knowledge dispersed. So I said, cool, told the companies we don't need to pull the emergency sync button. Relax, let's actually fix the bug, but we don't have to fix it in some kind of crazy thing like we did last year. I guess my friendly request, which would be kind of lame to do, but I'll do it anyway, please try not to break MD2 completely in the next six months. Is that you and Wang? Please? It is an offline attack though, so it's not the sort of thing that would actually lead to a lot of traffic showing up at certificate authorities. It can be done, you know, stick 20 grad students in a room for six months. So, do you have something you need to say? Apparently there are, MD2 shows up in SMIME email encryption. Crap. Okay. I'm gonna drink for them. So, manipulating existing certificate authorities, how do we do that? The MD2 attack has no link to present day certificate authority operations. Verisign has not done anything operationally with MD2 for years. Is it possible to bypass protections in present day certificate authority operations? Well, you gotta consider this is the quote that actually spawned this entire talk. From Meredith L. Patterson, I'm gonna go home and figure out the precise grammar of a certificate and see just what I can put in there. I'm like, that's a very interesting thing you just said to me, Meredith. Because there are two kinds of parsing vulnerabilities. There are those that cause a system to misuse memory. Those would be your traditional exploits. And then there are bugs that cause a system to parse a different message than was intended. Those would be what we call semantic exploits. It doesn't crash, it just reads the wrong thing. Now, you gotta realize there's some semantics going on here with a certificate. A certificate authority and a browser are talking to one another. They are saying, the CA is saying, browser, I tell you that this public key is linked to that subject name. And the browser has to hear, CA, I hear that this public key is linked to this subject name and it has to be the same name. What if it isn't? That'd be bad. That would mean a CA would hear one name and the browser would see another. So how do we know that what the CA says is what the browser hears? Well, there is a field called language theoretic security that attempts to explore this sort of semantic question. This is formalized by the other guys on this talk, Patterson and Sassman. And it describes how to build parsers that will always parse the same message in the same way. Now, I know you're thinking, you know, we should shouldn't we just be able to take this for granted. How much code is different, how much does code become different in C when you pipe it into different C compilers?  Same message, different parse tree, different output. This work was actually first used in 2005. They actually built a system called Dejector for eliminating or at least dramatically reducing SQL injection attacks. X509 was developed a long time before such formal validation models. And it shows. So, let's walk through the CA pipeline. The user generates their public and private key, submits it in the PCCS-10 certificate signing request.  There's a country, a state, a city, an organization, an organizational unit. The only thing the browser cares about is the CN, the common name. If a CA approves of a common name, it can do one of two things. It can do the more secure thing where it generates a certificate with only the elements that have actually been validated, so by actually making the DNS request. This is what's called scrubbing. And that would be the secure thing to do. The easy thing to do is to just say, okay, everything looks good and sign the subject name as it sits. This is actually what OpenSSL makes very, very natural. There are three ways of using OpenSSL to build a CA. You can simply sign whatever request comes in and then see if you like the output, and they actually from their command line will output a nice string for you to audit. You can dump the request to text and then parse that, and that goes ahead and has this nice line that you parse with the subject. Or you can go ahead and dump the generated certificate and then see, you know, here's your CN and see if you like that. Now, there's a pretty obvious thing you can do straight out, which is well, there are strings. We can just inject the appropriate strings to make it look like a new CN is there. So this is the organization string, organization name, and then we're going to have it have the printable string, bad guy ink, slash CN equals www.badguy.com. So now, when the CA does their dump, what they get is signature okay, subject equals bad guy ink, and then this injected slash CN equals www.badguy.com. Now, OpenSSL has four modes for emitting text. It is clearly meant to have its text processed. All of the non-default modes are secure. So, now the exploitability depends on how the text auditor is actually handling its, uh, now one thing you might notice is that we have a couple of CNs here. We have the injected CN which came first, and we have this real CN, the bank CN. Interesting question. What does the parser do when there are multiple CNs? This isn't just a question for what the text parser does. This is a completely valid question for what happens if you submit a PKCS-10 request with multiple common names, and that gets through to a client. That's a really good question, because literally every possible thing has been implemented. Um, OpenSSL will give you the first one. IE will take them all. Firefox takes the last one. First, all-inclusive, last, fail. So, what, of course, should the correct policy be? Well, this is wonderful. If you go to the RFCs and people were scrubbing through the RFCs for, like, weeks, they finally found one RFC that specified correct behavior. In parentheses, most specific. They don't actually define most specific anywhere in the RFCs, but they do say the words most specific. So, I said OpenSSL usually gives you the first CN. It doesn't have to. The OpenSSL developers realized the situation and, uh, they went ahead and made their API such that you could run it in a loop in this particular manner, and it would give you each common name until it exhausted. However, nobody actually uses this API. Everyone just calls X509 GetTextByNid. You see this in every project that we looked at. Clause, Open1x, WGet, Bacula, Neon, OpenLDAP, any CA that was based on using X509, NameGetTextByNid would only see and would only validate the first common name. So, what would you do with this? Well, we want wild cards, but there's an interesting limitation with wild cards. Netscape says if I see a cert with a star, cool, the certificate is valid for every name in the world. Internet Explorer says I'm pretty sure if I see a certificate with a star, the certificate authority was probably hacked. I'm just chicken. I'm not going to do it. So, it will allow a star, but it wants a couple labels first. So, you can get star.duxpera.com, but you can't get just star. So, what you would have is you would have a PKCS10 request with three labels. The first CN is for www.attacker.com that's for the CA to see and validate because they'll send attacker.com an email and attacker owns attacker.com. So, it's great. The second one will be www.bank.com specify a particularly interesting target and IE gets to see that. And the third one will just be the star and that'll be what Netscape gets. So, what is a CN anyway? X509 is written to a specification called ASN1, which I'm pretty sure was designed to make small puppies cry. It's designed to be very fast to parse. It's actually very fast to crash under fuzzing. 2002, the PROTOS project actually fuzzed SNMP and pretty much destroyed every router on the planet.  Ideally, they're all built on ASN1 stacks that got hardened back when we dealt with all the SNMP vulnerabilities. Ideally, people have been warned but we are a little worried about just fuzzing against ASN1 stacks here. This is cool. One of the other things that can happen with any sort of text injection layer is SQL injection. This stuff is put into a database and we work on it. It turns out the CAs figured this out a few years ago. Quite literally because of little Bobby tables. XKCD actually helped secure a bit of the internet. Awesome. Apparently after little Bobby tables came out, a lot of people were introduced to SQL injection by that comic strip and the certificate authority guys were like you know, we could totally get something with a common name of drop the entire certificate database. We should do something about that. I thought that was kind of cool. Cheers for XKCD. Now, this is cool. In ASN1, common name, that's the nice handle. That's what we speak as English speakers. But language is hard and localization is difficult.  So what ASN1 does is it actually has all of these what are called object identifiers identified by number. So say instead of common name it's <IP_ADDRESS>. It's a hierarchical namespace. Now what does this actually look like on the wire? What are the actual bytes? Well there's something called ASN1-BER Basic Encoding Rules. And this is a tag length value file format. Very simple introduction. You have an OID, which means your first byte is 6. So if you have a tag, 6 length, some number of bytes, and there are like three different ways of encoding a number of bytes because it's ASN1 and it hates you. The actual numbers are encoded in base 128. So this is how it works. If you have just a 06 that means the number is 6 and then there's a period after. If it's 86, it means the number is still 6, but this is one digit of a multi-digit number, with each digit being in base 128. So 86 is 6 and there's another digit coming. And it's big endian if you're curious. So let's look at a simple OID. <IP_ADDRESS> is 6 which is the object identifier. 3, length 3. 2.5 is encoded as a 55 because they're trying to save a byte. And then 4 is just 4 and 3 is 3. So 6, 3, 55, 4, 3. Very nice, very simple. Get a little more complicated. Let's do 1, 2, 8, 40, 1, 1, 3, 5, 4, 9, 1, 1, 1. That'd be RSA encryption. Okay, well, tag is 6. Length is 9. Now you have a value of 2a which is 1.2. 86.48. Great summary of what's going on here. This is 6 times 128. 86 minus 80 is 6. So 6 times 128 plus 72 is 840. And there's the 840. And then we have the same for the big number. And we have 3 ones. So 0, 6, 0, 9, 2a, 8, 6, 4a, 8, 6, f, 7, O, D, 1, 1, 0, 1. 0, 1. I missed a 1. Sub attacks. Leading zeros. One can have a tag of 6, and a length of 3, and then 55, 0, 4, and then instead of just 3 we have 83 which is 0 times 128 plus 3. So it's still 3. This has been seen before. We saw this in a few LDAP attacks. But suppose we actually had 2.5.4. 0, 0, 0, 0, 3 and then had that equal to www.bank.com. What would this actually be seen as a common name? OpenSSL tells us to go pound sand. It still actually does render out <IP_ADDRESS>, but it's a semi-collision. It does not actually resolve back to CN. So no text parser would actually see it as a common name. Netscape also sees <IP_ADDRESS>. Object identifier <IP_ADDRESS>. But it does not resolve that back to common name either. IE just sees the common name. Cool. So now we have multiple things that can be in an X509 common name that are valid that will be seen as the certificate authority making an assertion of browser domain identity. This is not the only way we can do this. Another thing we can do is do what's called a semantic integer overflow. Now integer overflows are one of the most common vulnerabilities in software today. Programmers tend to forget that if an arithmetic operation gets large enough, it will actually loop back to zero, or loop back to the beginning. This is a common problem for memory allocation. You have situations where it's essentially, I need more memory, I need more memory, I need more memory. You know what, I don't actually need that much memory. And the system, the rest of the system assumes it has some ungodly amount of memory and everything fails. So we have an arithmetic operation. This is essentially what ASN 1 is doing with base 128, multiplies and adds. What happens if we make it add past 2 to the 64? What happens if we have 2.5.4. 2 to the 64 plus 3? Well, what happens is OpenSSL has a big num library. It deals with it fine. It actually does not have a boundary enforced by hardware. Netscape overflows. But it overflows just like it overflowed with the leading zeros. It renders to <IP_ADDRESS> but it does not actually render back to a CN. I.e. you just win. You get another CN. So 2.5.4, 2 to the 64 plus 3 is another way of expressing common name. I want to point out one of the reasons we had ASN 1 do it this way is because they didn't want to have to worry about canonicalization. They're like, look, there's uppercase common name, lowercase common name, all sorts of spaces and tabs. Why don't we just have a numeric representation of a number and that grammatically will be simple? Well, this implementation bug tends to throw that out the water. Now that being said, most CAs extract a common name and throw away the rest. Well, good. Is there anything malicious that we could get into a common name? Can't throw out my common name because that's actually what they're validating. Well, what's in a common name? You have an object identifier and a printable string and strings are simple. It's a tag, 13, a length, some number of bytes and then just simple ASCII text. What could be wrong with that? Well, it turns out there's 13 different forms of strings in ASN 1 and you can use the other kinds. Two of the really interesting ones are BMP strings, which are a variant of UTF-16, a Unicode variant, or then there's Unicode string, which is 4 byte Unicode, it's UTF-32. That means when I'm saying 2 byte and 4 byte, I mean saying 2 bytes per character or 4 bytes per character. Now, why is this interesting? Well, first off, there's a trivial read AV in OpenSSL's PKCS 10 parser. There's nothing more fun than messing around with this in one editor by hand and then seeing, oh, well, it just crashed. I wonder if this is exploitable. It turns out it's not. But here's what was happening. They were saying, we are going to advance through this string until we hit the exact byte where we are at the end of the string. And then if they had a 4 byte character, they would advance 4 bytes. So what this meant is, let's say your string was not actually a multiple of 4, it would want to terminate on the 8th byte but there's only, you know, 7 bytes in there. Or what is it? You basically miss the, you'd miss the terminator, excuse me. Little tired, need to drink. It's not actually exploitable. You miss the terminator, but you don't actually write any memory after missing the terminator. So it just reads off into a guard page and you have no fun. Ah. Now, fun with printable strings. There are two ways of ending a string with text. You can have an explicit length field, which is what ASN1 has. Or you can have a null terminator, OXOO. So-called C strings use null terminators at the end of them. What happens when you put a null terminator into a common name? OpenSSL deals with it fine. It actually converts that null into backslash XOO. So you end up with, say, www.defconn.org backslash X00 www. OXOO.com As far as the CA is concerned, this is a host inside of the OXOO.com domain. It will do domain validation against OXOO, which as the attacker I actually own. However, the browser, the browser stops at Defconn. So you end up with a Defconn certificate. If this is Netscape, and if I was in a particularly bad mood, or if I was Moxie Marlin Spike, who found the exact same attack, good job, man. I would have instead gotten this cert for just star null dot OXOO.com and just had a cert forever, if that would be great for every site. But I actually didn't feel like having those kind of bits on my hard drive. Something about my hard drive is getting leaked. But I still owe a beer. So, we actually have a lot of progress on getting null and CN fixed. Moxie was like, wow, you know, this is not actually vulnerable in Firefox 3.5. No, we've been working on that, dude. So, actually I do want to say, Moxie probably has the best exploit for all of this. Do you mind if I tell them? So, you might say, okay Dan, you can impersonate a website. What's the big deal? Well, it turns out Firefox downloads code updates over SSL. So, yeah, if you're on LAN, if your, you know, DNS is cache poisoned, if anything is in path, you launch Firefox, it goes to the internet over SSL and says, hey, is there any new code for me? It should have worked fine, but one of these other certificate authorities has screwed them. So, even though Mozilla has a reasonable certificate authority that would never do anything bad, whoever Moxie was dealing with actually was more than happy to issue a certificate that ultimately was valid for Mozilla as well. So, most CAs should be clean, but we really do want this stuff at this point, but we really do want this fixed client side. So, the latest NSS already blocks nulls. Firefox 3.0 will have it soon. Opera should be covered soon, and IE and Safari are testing their fixes at the moment. So, at the end of the day, what am I suggesting? What am I saying here? Should we just move everything to DNS sec and tell the CAs to go find a new line of business? No, no, you're not going to believe this, the suckers are actually useful. One of the really nasty problems that people keep trying to define a way, keep trying to decide isn't actually a security risk, are semantic name collisions. We have our elite attacks with null terminators, but you know, www.bank-of-america.com works fine for users. They don't care. They also don't care about certificate warnings, by the way. We have a lot of dreams about, like, users really were dreaming about a universe containing nothing but us. A universe containing nothing but us is an even more terrifying concept. So, there's a problem. Somebody needs to be out there able to assert that www.bank-of-america.com that should not get a certificate. Someone needs to be in a position to be able to say that this is a collision, a semantic collision, even though it's different characters, no human is going to see the difference. If you think it's easy, think about other languages, think about other countries. We've got the equivalent of these dashes in China for one of China's largest banks. The only people with boots on the ground, with local knowledge, with actual brand awareness, are actually these certificate authority companies.  It doesn't work wonderfully well because it's just not the right technology for it, but it allows the CA to express their special knowledge that they actually made sure this name doesn't look like any other name and in return the browser changes the user interface a little. You get a green bar. Now Extended Validation has gotten a lot of flack lately.  It doesn't do anything about that. If you have a badly issued certificate the badly issued certificate can actually interfere with the Extended Validation version. This is by design.  So the perfect is the enemy of the good. The browsers did not actually design a barrier between EV and DV. So people are surprised by this. It was talked about publicly by a couple of guys, by Colin Jackson and Adam Barth two years ago. It was in my slide deck last year. Some CA's really did get out of sync though. They ran their mouth. They said, no one could ever exploit this. My assessment of Alexander Sodorov actually did some really cool demos with exploiting that lack of a security boundary. But there is no security boundary. So, there can't be. So what do we do? We do need to get the damn DNS root signed. Sorry, it has to happen. It will spawn a bunch of development where we can start using the really nice traits of DNS. We can start using the really nice traits of DNS to exclude insecure suppliers and to delegate authority effectively. We bootstrap other protocols, from SSH to IPsec to PGP to SSL. We put the hash of all of these certificates in DNS. And now consider, since DNS sec inherits DNS's exclusivity, you still have a cert. It still has the X509 GU that still gets the say extended validation. But other certificates will not work. The DV certs from every other vendor will actually be excluded. So you will have the best of both worlds. You will have the certificate authority being able to use the actual useful content they bring to the table. Or you can the actual useful stuff they bring to the table while being able to exclude insecure suppliers. So in summary, X509 is messy. Operationally, its lack of segregation and delegation makes it really expensive to use. Force is really painful decisions to be made. Technically the technology is really fragile. The orgs are doing the best they can. We got to give them better stuff to work with. That's what I'm working on with DNS sec. So, that's what I got. Nope, open for questions.


Well the after school sport initiative program is one that the Ministry of Community Sport and Culture Development has funded over three years, a million dollars a year, and the funding comes from our sports legacy fund, our 30 million dollar sports legacy fund. What that has allowed us to do was take a look at an initiative that really would assist young people who have barriers to participate in sports. Well it's just great to see the children's excitement and see them racing into the gym. We've been able to expand now so that we're delivering five days a week and we're having a couple of additional days that are going to be added to the initiative and it's just amazing to see their confidence blossom. The opportunities have increased immensely as a result of this funding and the differences have been notable since we've been participating in this initiative. So without this funding we would not be able to be offering the after school opportunities four days a week for our kids. So we service through this funding we service in excess of a hundred children after school that we would not otherwise be able to service and those children would not be engaged in these activities for a variety of reasons that are barriers to their family in our communities. We tailor a program to address the unique needs of the children mainly by listening to them rather than pre-designing a program and implementing it whole scale. We ask for their feedback as we're actually creating and developing programming. The community forum actually really facilitates growth within the program. It's one of the only times we get that chance to interconnect with other programs and see the conflict resolution and the obstacles, ways we differently overcome barriers so it really provides that kind of integral organic feedback. This forum provides that unique opportunity for people around the province who have adopted this initiative to come together, share ideas, whatever it is it is important that they all share these ideas to make sure that those struggles or challenges they have can be removed as quickly as possible and for those areas that they have found success in they could share so they could implement them in their areas. So this is a great community forum. This is a great opportunity for them to come together and speak open and freely about making this initiative that much better.