 how are we doing? Do we have? Yes, we do. All right. So how many people have been watching the closed captioning all weekend? Yeah? Do we like that? I've had a lot of people ask me what software is that? That's not software. That's meatware. There's actually a person on the other end of the wire that is typing that in. And they've been obviously very patient and probably doing typing things that they normally don't type out in a regular day to day. So why don't we take this opportunity and ask our person doing the transcriptions, what have you thought of the conference so far? Well, thank you very much. Since this has been going on, it's really helped out and it's really added to the conference experience for everybody and we're really glad that you guys have been putting in the time to help us out. So let's give them a round of applause one more time. Great. Next, Jeff and Rob, we're going to talk about web browsers and encryption. And we're at a spot where a lot of people, certainly our muggle friends at home, still look for the little green lock. If it's got the green lock, it has the same security banks use. Therefore, it's secure, right? Military grade. Yes. And we're going to talk about why that may not be the case and maybe some things that we can do to make sure that when you see that little lock, that it might mean a little bit more that it's locked. Let's give Jeff and Rob a big hand. That's not premature. What's it? I hope that's not premature. Yeah, I know. I'd hold your applause till you see what happens. First, I'd like to say I'm sorry to the person typing everything I'm about to say. So welcome to the TLS Canary, which is our project that we started doing. And it is the theme of keeping your dickpicks safer. I don't mean to look relaxed, but this is really the only way I can talk into this mic. So we're going to have a little intimate conversation going on here. So a little bit about us. I am Ebel Rob, Rob Bathurst. You may see me walking around. I'm the director for healthcare and biomedical security for a antivirus company called Silence, except it's not McAfee, Symantec, or any of those other things that don't mean to insult your company, but your product kind of sucks. So I will turn it over to Jeff real quick. I'm Zephan. I'm Jeff Thomas. I do stuff with computers. And he is barely awake, I assure you. So I'm glad you all decided to make it here in a semi-conscious, hungover or fully awake kind of state. This is one of the greatest quotes in all of reporting, I think, that there could be. How many of you saw the actual interview that this was taken from? Was it not amazing? I mean, it was truly the best thing. I was riveted the entire time. Because aside from the quantum project and everything else the NSA runs, I truly want to know whether my dick pics are being collected. The answer is always yes. The answer is always yes. So, you know, we want to talk about, you know, better ways to take those dick pics that are being collected. So analysts aren't bored and generally intrigued. What angle you should take them at? If it's better from the side or up top. You know, always put a penny or something next to it just to, you know, enhance that. So realistically, you know, why are, you know, why this, why this project? You know, things we like ourselves, obviously. Some of you, a very small percentage, but you know, you're out there. And systems that are not built on blind trust. I mean, the whole reason we started looking into this and the whole reason that we built this project is because a lot of the infrastructure behind the internet was an add-on and in addition, well after the fact they're like, oh, yeah. Okay, so I can see that webpage, but I really need to transmit something securely. Well, we could re-engineer it or just tack it on. It's fine, it's fine. So we'll just use the same communications mechanisms and protocols and we'll throw some things in it that will sign some stuff and yeah, it's all great. And you know, I'm sure there's no other system out there like that other than, you know, the PKI. Other than everything. Oh, well jeez, I was trying to give them a benefit of the doubt. You know, things we don't like ourselves, which is why we put on this talk, more of you, and you know, things that fail without warning. You know, I'm okay for systems that have failures and flaws and errors as long as they warn and yell and scream when those errors actually occur unlike most things. So why? You know, I'm sure a large percent of you are familiar with the Did You Know tar? It was compromised by a lone Iranian hacker. An entire registrar, one guy. He's just like, you know what? I'm bored today. I could look at 4chan or I could go hacking and issue a bunch of certificates for no purpose other than boredom. You know, 531 of them I believe was the count that we came up with and it was used to intercept Gmail users in Iran. And only Iran. You compromise an entire registrar or entire certificate authority. And that's all you do with it. I'm not sure. We'll call that technical failure? Try again. Because about that time frame there's some things going on and intercepting Gmail is what hackers do when they're really bored. Yes, this was on a board Saturday night. He's like, you know what? I hate these people and I just want to read their e-mail. You know, second thing, Turk trust, right? Two intermediate route certificates were issued out of this. They were used to man in the middle, wildcard. Google.com. Wildcard Google.com. I mean, how could that ever be a bad thing, right? I mean, obviously Google doesn't mind. And it was detected by some of the technology built into Chrome with the pinning they do with their certificates. So only their applications will trust it and we'll talk about pinning. But you know, just a quick precursor of what we'll be talking about. You know, Google has done a lot of work in this. And you know, what we're doing is not to detract from anything we're doing. Anything they're doing is just their projects going to take a long time to get to the end. And obviously issuing the man in the middle certificates for Google with a wildcard was for totally legit purposes. Like this. Another instance we were able to pull up is the Brazil Ministry of Minds, the Brazil Ministry of Minds and Energy. Allegedly. Allegedly. Allegedly. Allegedly. It was used to target individuals and organizations with the same thing. You know, it's the same theme we keep going over. Your entire certificate system is based on trusting someone. Seriously. Like that right there is the epitome of everybody that like, don't worry. It's safe. It's full of kittens. And there's nothing that could possibly go wrong. And you know, what we'd like to point out is these are just the attacks that are public. Ones we know about because someone detected them. Google detected them. Microsoft detected them. Or there was some system out there. Some organization looking out for realistically their own self-interest. They weren't looking out for you. They were looking out for reputation damage. They were looking out for protecting their systems. They're going to say they're looking out for you but realistically there's not a lot of systems out there to protect you as an individual and it'll give you the power to figure out what's going on. You know, CAs are run by companies, agencies, people, organizations, staffs. You know, how many of you work in a corporate environment where like, we're just going to load our certificate on it and it's cool. You know, you'll get some email from it. It'll be gray. We can contact whenever we want. And don't worry. We're not doing anything we shouldn't. But all people regardless and all organizations are vulnerable to coercion, corruption, common mistakes, issuance of bad certificates because they got lazy that day. And so those are things you really need to look at with this type of infrastructure. And it's just computers and software and a bunch of signatures and hashes and things that get moved around and the way the system is built is we just blindly accept that. And from an attacker's perspective, and I'm not saying the board Iranian hacker by himself, but you know, from an attacker in general that may want to do a mass collection or a government agency or something like that, CAs are high value. They are absolutely high value because if you can get to the root CAs or even the intermediary CAs, you have a tremendous amount of power over anyone who has to connect and authenticate through those CAs which is basically everyone. We've also extended certificates to be used for other purposes such as software signing, things that can actually be embedded in your operating system. Being able to subvert those has a proven track record of allowing you to do some very nasty things. Or even as we're going to bring up an example, your citizenship to a country is controlled by a PKI certificate. So, you know, what is a certificate? And you know, I'm not going to bore you with all the details of what a certificate is, but in general it verifies ownership of a key associated with the resource. It's issued by a certificate authority at some level that is trusted, trusted. And they are used on your computers, they're used in applications, they're used on your cell phones, they're used for software updates, they're used for, you know, basically anything that we're like, we need to establish a unique identity of some kind. At a high level. You know, so how does it work? Well, again, it's all built on trust. It doesn't actually work and it's super broken, but I can't go out and say that right away because then it sounds like a pessimist. So, legit certs are signed by a trusted CA. In this case, like a GeoTrust or a Verisign or, you know, the large ones that collect lots of money for doing this, you know, time and time again. Our browsers that are trust by any or trust anything that is signed by these CA's by default, because they are inside of our root of trust inside the browsers, cell phones, et cetera, et cetera. Sessions get negotiated by magic. I say that because my talk is not to talk about how broken TLS and SLL are as a protocol, just the infrastructure around them. And then after you get that lock symbol or you get that, you know, it's all good. You're free to send your very secure dick pics through them. And that's really what we're here for. And from the user's perspective, they've been trained. If you see the green lock, I mean, this is a considered progress in that if they see the green lock, they know it's okay to type in their password. They know it's okay to do their banking or whatever else they're doing online. Yeah. So if you get on the DEF CON open network and you see the green lock, you're good to go. Nothing bad is happening. You know, Bali's just wants to make sure that you have the room number and credit card associated with wherever you happen to be all the time. You know, so, you know, we call this, you know, the chain of fools, right? It's, I'm trusted by the world as the root CA for whatever I'm doing. You pay me some money. You know, it's a lot of hard work to sign those certificates. So I sign your search. I take your money. Your search now trusted by anyone who trusts me, which by the way is everyone because I'm in your root store doing whatever I do. And now you can say you're whoever you ask to be. You know, in the case of the men and mill attacks on the wild card for google.com, a computer that uses that as a, you know, a reference for trust or if you're being funneled into that proxy, you're not going to know. Your browser is going to give you the same, hey, it's all good as the search that Google issues. And that's because to your browser, any of the 200 certs that it has loaded in its root store is legitimately okay to say that Google is this definite computer over here not collecting your data whatsoever. So this is the example I brought up earlier. You know, I got a, you know, credit Citrix for this picture that kind of proved my point. I think they were trying to sell one of their products to the Belgian government to help them do the CA infrastructure and verification. But you have the global signed root CA. You have the Belgian intermediary root CA's. And you have a bunch of these citizen CA's down here that verify the citizenship of the individual down at the very bottom, the army of people. So if you were to take control of one of those Belgian CA's or one of the citizen CA's that has the ability to say, this person, this EID is legitimate and they are a citizen. You know, what implication does that have for border control? What implication does that have for actually verifying whether or not somebody is who they say they are? Because you know, you've been trained not to be able to trust the physical picture. You've been trained not to be able to trust the paper in front of you because how easily forged it is. You know, if you had control of one of these CA's, it's like six lines of code and you've generated a citizen. You know, I say this in a very broad kind of way, but that's the world is on fire perspective in this type of example. This also highlights a level of trust that we put in technology and this system, this very complicated system of systems in that we can, they feel they can rely on it to make high level decisions or to do a high level of verification of someone's identity and someone's citizenship. Yeah, and it's not like you can harden these CA's and stick them away and you know, put them somewhere nowhere and can touch them because at some point it has to connect to another system, to another system, to another system that's going to tell you where the one with the keys is hiding. You know, and then you can target that organization and do, you know, I'm sure there's been 50 other talks already about that type of stuff which, but you know, that is the root and the sequence of trust that is the world we live in today. So, you know, again, I'm going to do a basic overview of things. We have HDP, POP3, MUN, SMTP, FTP. They're not in encryption mechanisms. They were never designed to be encryption systems. They were communications protocols. Yeah, at the beginning, you know, everything is all about how do we talk. You know, anytime an application developer built a program, it's like, how do I get A to B? Okay, I got A to B. My design goal is done. Shit, security's here. Okay, I need to go A to B in a somewhat secure way. So we'll just use SSL certificates and TLS and, you know, it's cool. It's fine. It's fine and, you know, we'll just forget about it. There's some security strapped on. It's great. But at the core, at the core of the problem at the end of the day, everybody's just concerned with how do I get A to B? How do I get the dick pic here to here and how do I make it look good? Like, I mean, that is really the concern people have. You know, so how do those secure tubes work, right? You know, it's SSL. It came from Netscape. Like, seriously, this stuff was tacked on. If you watch Moxie's talk back in 2011, he found the actual doctor from Netscape and not the MD kind, the PhD kind that actually wrote the original SSL libraries and everything else. And he admitted, yeah, we just tacked it on. Like, somebody's like, hey, we need some security. We'll just band it to the side and that was 1.0. You know, since then you've had the RFC 6101, 6176 and the TLS-13, which is the new new draft coming out. And if you really want to read them and need some bedtime reading, by all means go ahead. And it's also, it's not hyperbole to say that SSL is the reason we have the internet we have today, where business can be conducted because people actually feel safe putting their credit card online and giving it to a website. Because they know, they know, they see the green lock and that their credit card can't be stolen. Yeah, and you know, anyone who says that marketing doesn't deserve money has not been paying attention. Because seriously, you can sell ice to an Eskimo if, you know, you have the right marketing guys. So, you know, why is it old and busted, you know, from a protocol perspective? It's, SSL has a problem with using identical keys for messages and encryption, lack of protection from the handshaking. You know, I'm not going to list out specifically what version uses what, but it's vulnerable to truncation attacks, weak cypher suites, you know, problems with RC4 and something about a poodle. Something about a poodle and a beast and a something fire sheep and it just, creative names really, but yeah. And you know, TLS, they're like, oh, TLS TLS is the solution, it's not SSL and it took researchers, I don't know, like a year to be like, and it's just as broken as it was before. But it's broken in new and interesting ways. And ultimately it still rides on the same certificate authority infrastructure. Right, it doesn't matter if we create TLS 55, it's still using the same certificates issued by the same things with the same problems that we were discussing before. So, interception. I can't play the music. I know, we're going to do like the serious gopher, like the dun dun dun, but unfortunately like it's not quite conducive to what we're working with. But iOS, you know, when I did an inventory of iOS, it trusted about 226 certificate authorities. About. I didn't get an exact count at the version I had last looked at, but you can go to Apple, they list all the ones they look at. My favorite is the Hong Kong post office. So if the Hong Kong post office wants to be Google one day, they can be Google. Firetrucks, Firefox trusts about 180. You can go to that link again, they will list all of them. It is nice from a transparency perspective that most of these manufacturers of various systems actually list out the certificate authorities in their route. Unfortunately, it's still a shit load and there's more that get added every day. Countries can be like, you know what, I need you to trust these five organizations and the browser for interoperability sake has to put them into their route. It's very rare, and I think Microsoft was one of the first people to do it, to actually pull certificates out during a refresh. You know, one of the things to consider too from an issuance of certificate authorities is they're subject to many laws. They're subject to local laws, state laws, federal laws, international laws, you know what have you. If an organization decides that, you know, for lawful purposes they want to do some form of interception, they do all their government forms and you tell me SCA in the world is going to be like, no, you know, I'm just not going to comply with this. And, you know, it only takes one. It only takes one globally trusted route authority to issue a bad certificate for lots and lots and lots of people to have a very bad time. And if you've never looked at the list and you want to feel a little more paranoia, I do recommend, go to one of these links. Go to the, just google it, look for yourself. You can see which certificate's Chrome trusts, which certificate's Firefox, which ones are embedded in Windows and the other various OS's, and you can see just how many route authorities there are and the global span. They're in so many different countries, under so many different jurisdictions. It's, it's, it'll, it'll make you worry. And, you know, some of you also consider that, that we didn't actually bring up in a, because it's kind of a corner case, the computers you're using, the manufacturers can put their own certificate on it and basically tell that system to trust it no matter what. For updates and everything else, Lenovo. Nobody would ever do that. But that type of activity, whether malicious or not, if implemented incorrectly, can wreak havoc in, in terms of what gets trusted, you know, if you could possibly be intercepted while not actually realizing what's happening. So, there is a subversion of secure communications in, in the sense that there's basically two categories. There's the legal reasons to do it, you know, you all go to work and you decide, I want to use a work computer and there, they make you sign some forms and they're like, okay, we can monitor everything you're doing. You hit a blue coat, you hit some other appliance, it proxies it out, yes, you realize you're being watched. Doesn't stop people from browsing porn. I mean, seriously. But, I spent the past five or six years of my professional life recommending that a lot of places do this, because it's a good thing if you have to protect a corporate network and you have good policies in place, you're subverting, you know, the security that's inherent into the communication protocol. Right. I mean, it'd be ideal to have it in to in, but that doesn't work for most corporations, you know, which is why you get to load balancers, you front end off load everything out and now all of a sudden it's only secure from this point to this point, or it's only secure until it hits the perimeter and now it's no longer secure. So, while you're browsing Gmail or anything else, it's all in the clear text on the inside of the network. And, you know, the last potentially, you know, reasonable expectation is a government request, although, I mean, that has its own geopolitical issues that are not really, you know, something I want to get into. Which leads us to the next category. Which is the next category, the not so good, but maybe secretly legal. You know, the government request versus government demand. Criminals, you know, the low-niradian hacker that wants to break into something and my personal favorite, advertisers. It's much easier if you're not secure to target more ads to you, which makes more money for them, which makes more money for other people and so on and so forth. But they have a secret agenda, or not a secret agenda, to make sure that they're able to support ads. I didn't know money was secret. Well, they like to play it off as it's better for you in the freemium economy. But, you know, a good example of this is actually no script. No script, I believe, or ad block plus one of the two is working on what constitutes a good advertisement and what can go through because it's not obtrusive. And these are systems that we are relying on to protect ourselves from malicious drive-bys and all kinds of other attack techniques that we're hoping these block, but then we're like, well, it's okay because this advertiser is only, it's a static content. There's nothing bad that can occur here. And that's the same type of approach we're taking with the PKI and everything else. It's okay because somebody else has our best interest in minds. And the depressing reality check, most people are just conditioned to click okay and then when something bad happens they look like this guy over here. You know, their credit. This happens, we all, you all know this, that people, or the weak link always. Yeah, I mean, this poor sheep's credit card was used in Bulgaria and the bank won't give him back his money and that's how it looks in the end. So solutions, right? You know, I stand up here and it's a doom and gloom perspective for everything and anything. The Convergence Project, which is what we mentioned earlier, Moxie did back in the day. I highly recommend going to look at it. It's some great work. It takes a different approach to what we were really attempting to do in our Band-Aid. And then, you know, the more encompassing project, the Certificate Transparency Project, Google, you know, they have some power. I'm just going to put it out there. But the certificatetransparency.org, while not fully implemented or public in any way, in the sense that they have something that you can just grab and easily insert into everything you're doing. They do have it built into Chrome. They do use a certificate extension for things they control for the HSTS, which allows them to do a form of pinning that allows them to say, this is definitely a trusted certificate that I issued and I know nobody is subverting it and it belongs to me. I highly recommend you go look at it. One of the problems with the current infrastructure. All right, thank you. What was that? It was HDKP. B. HPKP. Thank you. Sorry. You mean you can't remember everything? I got all my stuff stolen at Mandalay Bay by a very enterprising thief. Hey, we haven't gotten to that slide yet. But I haven't gotten to that slide yet, so I'm a little frazzled. I've had to rewrite a bunch of plugins in the past 24 hours. So one of the problems with the current infrastructure is that a certificate can be issued in secret. There's no way to see that a certificate has been generated. So the 531 and the previous examples and God knows how many others that have been generated exist and they won't be noticed until something goes wrong, until a user notices that the certificate is by the wrong civilian authority, which just doesn't happen, or they try to hit Google, which uses certificate pinning, which is a great way to detect when some chicanery is going on. The cool thing about the certificate transparency project is that certificates can't be issued in a vacuum. All the peers that are involved in the system, the interactions are visible and public. And because they're public, they can be verified or they can be noticed when something bad happens. Exactly. Go look at it seriously. Very cool. In the end, it's going to be that or a project like that that really fixes a lot of the issues associated with the infrastructure we're using. So pinning, basically it's a, every application inside should be using a form of pinning, but it is a little cumbersome to actually get done, but at the core of it is trust this and only this certificate to say that I am who I am. This model works really well with mobile apps that are dedicated to your Facebook app on your phone or Twitter. It's easy to pin a certificate in the app because the app developer is the one providing the service so that they can actually embed that and it's truly end to end. Yeah, and it is great. Like when it works it works. Unfortunately it is relatively hard to configure if you go out to like a WAS, they tell you how to do the pinning and it's this giant web page and you know from a normal administrator's perspective whose day job is not to deal with this type of thing, it's going to turn into the one of those I could but type of situations, which is what in the end we really do not want. Implementation varies, obviously the Google I had mentioned and incorrectly acronymed and then as the example I had mentioned before the Hong Kong post office cannot issue a cert for your send my dick pick application, which is really what we're here for in the end. So, Gaviats, we're not developers, we're hackers. I write scripts to achieve an end goal. I write code to achieve an end goal. I don't write code to do enterprise products, which is why we are you know putting this out there in an open format so others that may want to contribute to the project can really contribute. We have no power. I do not represent Google or Microsoft or the IETF or anyone like that. We are simply trying to find a temporary solution to a what seems to be permanent problem that we can go with. Canary, our application and our project is not the solution, but it is a far leap better than what is currently out there in the silently failing you never know who you're trusting type of approach we're we're using today. And yes, I got robbed and there are some various ideas as to how that occurred, but the end result is that stuff got stolen out of my room and I lost my laptops and had to rewrite like three or four hundred lines of plugins last night. I obviously should have backed it up to Gitch or a repo of some kind prior to not realizing my stuff would be stolen. So if it looks a little hodgepodgey in some of the upcoming things it's because I was up most of the night writing them. So our goals, we want to protect your dick pics from board analysts. If you need dick pic consulting, it's not us, but we'll try and protect them if somebody were to get a hold of them in transit only. User awareness, we want to make sure that you realize the site you're going to in the certificate chain you're looking at is actually the legitimate one that you are going to, you're going to in the one you want to be at, and really stopping shady shit. I mean come on, like this, the whole infrastructure we're on is meant to be a good idea and turned into a horribly abused idea. It's meant to be trustworthy. Yeah, it's meant to be trustworthy. So what the tool does? The tool is built in kind of a client server model and we built it that way so you could specifically leverage our infrastructure and build your own plugins and do whatever you want to do and we'll show that here in a second. At the base it does a certain different comparison between what you see on your end of the browser, the plugin, the application, and what our distributed system of server sees. So you go out and it basically will keep that, it will collect your search chain locally, send it to our server, compare the search chains if they match, hey you're good, if it doesn't match, hey you might have a problem. You know, that is version one. That is what it does. It tells you, hey you have a problem because what you're seeing is not what the rest of the world sees. This may be where the name came from. If the canary dies then you have a problem. Yes, no one wants to kill the tiny fat cube bird but if he dies he dies. So what it doesn't do, protect you from compromised sites. I cannot tell you that facebook.com is jacked up if facebook.com is jacked up around the world. It does not protect you from subpoenas, warrants, people kicking down your door, someone hacking the end, you know, someone controlling the AS from a BGP routing perspective and it will not encrypt or protect your dick pics at rest. That is not what our application does but I'm sure someone else is willing to sell you something that will. Yeah, all canary does is provide multiple perspectives. So if your link is being hijacked or intercepted or routed through a transparent proxy you can submit a query to canary which one of our distributed servers will be outside of your jurisdiction and compare what you see to what the globe sees, what the world sees. And if they're different then there's probably something going on, something wrong. And we are going to release the server code on to our repo so if you want to spin your own up you can spin your own up and if you're like well obviously some nefarious organization could just spin up a bunch of these servers and put them somewhere they control control but realistically I'm not that interesting so I doubt they might do that but if everyone adapts to it maybe they will who knows. So the goal is a globally distributed network outside the jurisdiction of one individual organization power agency control area you know what have you. It is scalable it's designed to be able to accept many many many many requests per second and the return is basically a one or zero it's good or it's bad. That's that's v1 we're going to eventually hopefully build in you know a certificate history chain so it keeps track of if any of the changes occurred anywhere in the chain or you know some of the more features for round robbering around robbering across the globe and stuff like that. If any of you heard of the SSL Observatory very cool project one of the developers actually I contacted them about using some of their code we didn't end up using it but what they do is they scan the internet looking for SSL web servers and gather those certificates and keep them in a database and they've been doing that for a long time so they have multiple snapshots and running history of SSL certificates or TLS certificates and this canary has a potential to do the same thing but rather than doing the active scanning we're relying on user queries to to build this database so it's going to be focused on the most commonly used the most popular websites. Yeah and it's not meant to be a scan over time as Jeff was saying it's meant to be as it happens because I don't want to compare this here from a month ago I want to know exactly what you're being presented at this particular moment. So this is the JSON structure this is basically it and again we'll release this but this this is all it takes to submit a query to our server and get a response back whether or not it matches. I'd also like to take this time to thank Redbeard. He is our silent third presenter here he was instrumental I'm learning go because of him it is a very cool language so I am not learning go. He was instrumental in helping us get this done on time. Yes I cannot thank my friends enough you know Jeff and Redbeard and Forkis and you know various other people who helped my recoverer from the enterprising thief and you know helped actually make this to be possible so I just want to say thank you to the man and the beard up there. If you look at the JSON struct it's very straightforward we don't want your information we don't want to log and if you look at the code if there is no logging other than a query was made but all you have to do is whatever language or tool you want you can construct this JSON struct that just has these fields in this form we go out and grab the from the same website that's presented in the query grab the TLS certificate compare it to what you gave to us if it matches we'll return it yes oh I zero if it doesn't match we will turn a one and it's as simple as that. Yeah the only IP it ever the only IP or name it ever keeps is the target that we have to pull the server that the certificates from it doesn't keep yours it doesn't keep a history on anything else and once we've you know pulled it we just keep the host name in the certificate chain and we don't really care about the IP anyway so if you want to move on so this is essentially a version this is the plug-in I was writing last night essentially it's a firefox plug-in it turns out the NRO does not have a very secure website apparently so your dick pics could potentially be stolen when I mostly because our system also detects it's hdb versus hdbs and it's going to warn you the same way hey this is insecure but it basically it throws a red banner up around it gives you a javascript alert because I don't know how many of you programed firefox extensions but essentially javascript or python or c depending on what you're trying to do with it this particular add-on use javascript it's like hey the cert doesn't match you know there's no cert attached to it hey your dick pics could get taken by these guys although I really want to meet you if they redirect a billion-dollar intelligent satellite to get your dick pic I think you would be a very interesting person to have beard with just saying phrasing look you know beer is beer so and essentially the the the next version is it we said it's a binary comparison right so it goes up it hits it it says yay it says nay so if you hit the next one this is a good place to submit your dick pics and the only difference being the green border in this case again I wrote the pro plug-in to do red or green green border says yes we've taken the certificate chain it matches what I see it matches what the server sees and when it did the comparison it's like cool if you want to put your dick pic here it will it will be protected by you know the same certificates that you're seeing that we're seeing and this is this is where real developers can can actually contribute because in uh we know firefox and we can see there's there's hooks for intercepting uh SSL calls we can intercept the query the web request before they go out and if the certificate chain doesn't match then we can block them but when you're dealing with a uh android or ios it's a lot more difficult to intercept transitions before so if you open up your browser and try to log into your bank or to whatever uh your password could be transmitted before uh canary knows that something is it's gone wrong so your credentials have been compromised your activity has been logged and it it didn't serve its purpose yeah and it the browsers are okay uh there's stuff actually built in from netscape libraries uh that can allow you full control over some of the stuff with chrome some of the stuff with firefox but it really is as as jeff was saying uh the the applications where you know ios has a tight control over execution in network hooks that it becomes uh more after the fact warning that where we're trying to work with and get around so uh why use it right you know the whole of everything uh you know why use it it's here to provide awareness it's here to provide hey something isn't right i'm looking at a problem i'm looking at this site and it's not matching is it just me is it the rest of the world what's going on um we don't want silent failures we want bright screaming red flaming lights on fire failures uh where it's become really obvious it's super lightweight uh the whole point is for you to take the code examples take whatever we have take it throw it in do it yourself uh or use what we have uh we don't cache data requests we don't uh we might start caching observe certs uh but that really has less to do with you and more to do with the you know general infrastructure the internet um and we will never store your personal requests this is the ssl observatory light part of it where it's it's more of a intellectual curiosity and the to be able to speed up if it does start becoming popular god forbid uh being able to speed up the queries and also do correlation and uh history see and when something changes if it changes before the certificate expires and just general tracking yeah so why not use it i mean really come on i mean that that's what we're here for that's why i spent all last night writing this crap right and he spent all week um you know no reason i can think of not to use it unless you don't trust us i wouldn't really trust us but you know that's why we're making an open source that's why we're putting it out there for everybody go trust yourself look at the code figure it out doesn't work for you um does it work for what you're attempting to do does it work for you know the goals you're trying to achieve uh some people just don't care and i can't change that opinion other people like myself like to know when their stuff's being messed with yeah we didn't write this for just the general masses of users but if you are truly concerned if you have a reason to be concerned like if you disagree with your government and want to you know change it somehow some governments don't like that and some governments take uh affirmative action in that get it to um uh limit your capability and limit your ability to communicate in private and and or if you're just on the defcon network yeah that too either or so uh this is where you can find it uh the tlscanary.net uh is where we're gonna end up tossing uh you know instructions kind of use your guides here and there what it's meant to do some observations right now it's just some plain text and then github is where you can pull the source from that will be uploading uh probably tomorrow or tuesday uh but that's gonna have to serve your laptop back when i get my new laptop shipped in um but uh it should uh it'll contain client codes or code our firefox example hopefully our chrome example um and some of the code we're working on to try to do the uh applications uh on the the uh iphone android platforms it is designed to be a very lightweight if you want to spin up an uh amazon instance uh ac2 instance and run the code yourself and use your own private canary great have fun it works the the request structure is so light and what it's pulling is is not even html content it's just literally certificates um so it's a very low transaction overhead if you want to run it yourself so scotch and questions uh it will say that a self signed cert does not match what i see globally unless the server you're hitting is also the one that has the self signed well yeah if if you present it to the self signed certificate and we see the same one we tell you it matches we don't care that's not our problem yeah if you trust it and you all we're saying it's it is a one-to-one and that's that's what matters uh from the application perspective so this is uh pretty cool stuff guys i was wondering if uh kind of goes along with ocsp except for the fact that ocsp goes with certificate authority this is kind of more to gathering intel across the community and sharing that information and i was wondering if you guys thought about publishing this as part of an rfc to kind of standardize this as a method for additional checks because it would be really cool if this information is intel starts getting out there to where people can start making decisions on certificate authorities and go wait a minute those certificate authorities are bad we need to start disabling those certificate authorities and looking at those monitoring those guys and say which ones are doing proper things and which ones are not doing the proper things and those ones those are not doing the proper things we just get rid of them sure i i mean that the potentials out there and you know it's all going to be open source so the query structures and what we observe and everything like that is meant to be wholly transparent um so if somebody with that authority wanted to go through and do that effort we'd be more than happy to support you know that and provide whatever information we'd have to provide this is a band aid this is this is a it is a band aid and we'll acquire someone with power to actually implement those type of process in protocols and then procedures i personally personally rather see something like the uh the google transparency project move forward something that and we're happy if someone from google is here and wants to integrate this we're cool with that too uh something that that actually solves the problem and doesn't just you know put a band aid on it so that lets you detect when the problem is being exploited firstly thank you for helping to protect my dick pics well that's what we're here for right you know if you're shlong transverses the internet unsecurely it hurts all of us so my question is is did you guys contemplate uh doing revocation checking also uh as part of the canary exercise so uh I I do have revocation checking actually built into the extension uh the canary project on its own is merely meant as a cert comparison tool uh the revocation checking could be built into the server but it's one more check that would slow it down whereas uh if you're already utilizing the extension libraries uh it can do the revocation check before it pulls a cert chain so in in the example of the firefox extension it would just check it say it's bad not even bother sending the the thing up and we're not replacing we're just augmenting I'm curious in a compromise case where you have a a mix of good state and bad state how do you ultimately know what reality is are you just going by numbers seems like uh since you're not logging all any kind of identifying information or tracking information for users that potentially maybe you know you're a lone Iranian hacker can go and send you five x the amount of data from there the botnet that they personally run well so uh if if for instance in the case and I think I'm hearing you correctly is you know in in the case of a mix some things are bad and some things are good type of scenario you have to have basically a weighted algorithm that says 65 percent of the world sees it this way and if I have 300 sensors what are the odds that 300 of my you know 65 percent of my 300 sensors are bad um and and there is something we're considering putting in is like the confidence of how good this is from what you're seeing it's just in the v1 that it's not something we put in um but we were thinking about that problem it's just one of those at what point and what sample size do I need to actually achieve a confidence there's also the implications of two jackasses being an arbiter of what's good and what's bad other than you send a query we do our verification and it's very simple this JSON struct is very simple it just presents the uh certificates the signature the serial number we verify if they match and send it right back I think my point is just that fundamentally in saying you will not log session information you're limiting yourself there's a lot of nasty tricks you can do I said we won't log your queries I don't care where the queries come from but when we do our own grab we grab the certificates on our own those will probably end up being cached at first just for efficiency and for for load balancing and for for spreading the load but in the long term I'd like to do something like what SSL observatory has already done and start building our own database and looking at how certificates change over time it's just purely academic and also to try and enhance the service and make it you know better all right well we're out of time come find us in the bar if you want if you're still here I appreciate your time and hopefully your dick pics will be safer in the future