 All right, next up we have a really cool talk on lost and found certificates by Ian Foster and Dylan airy. Please give them a warm welcome Thank you very much. I'm Ian. I help run to our cons. Hopefully all enjoying it a bit This is my copers in our Dylan So this is Ian. He made a cert graph he's a DNS researcher and You can check out more of his stuff from the URLs there And I'm Dylan I wrote truffle log and some other stuff and you can check out my github So basically the problem that we're talking about today is What happens when an SSL certificate? exceeds the lifespan of a Domain's ownership. So basically you you buy a domain you get a valid SSL certificate and then the domain expires or transfers ownership the original certificate is still valid and so this this phenomenon Can last for years in certain cases if you get a say three year SSL certificate and prior to 2013 there's absolutely no way to get any kind of visibility into this issue or tell that any previous owner of the domain May still have a valid SSL cert So this example that we've demonstrated at the bottom here um Alice can register domain name for food account for one year and get a three hour cell certificate for that domain name at The time of registration then the domain name can become unrestricted say Alice doesn't renew it And later Bob can I sure it and guys own a cell certificate all while Alice is three SSL SSL certificate is still valid completely unaware of where to Bob and so I just want to talk about certificate and transparency, which is a publicly auditable log of all trusted certificates by certificate authorities is designed to catch misbehaving certificate authorities and Currently it's about a half million certificates and growing and right here. We have a screenshot of a Certificate transparency search tool CRT SH showing examples searching for certificates for Google.com saying that you can see Their log of date the date how long they're good for and some other information if click on it can view more information So basically we can use this to get some visibility into this problem, which we didn't have before These certificates from previous owners will often get logged in certificate transparency And and we can use that to tell if a previous owner still has a valid SSL certificate It's not perfect and a lot of the old certificates take years to show up and sometimes they never show up but it's way more visibility than we had before and new certificates that are minted are actually required to show up in a certificate transparency logs So using this method we looked for notable examples of this problem And we were able to find some one that's pretty notable is stripe comm stripe is basically an online payment processor that They basically conduct credit card transactions for a lot of different e-commerce websites If you've bought stuff online, you probably at some point have interacted with stripe And what we found is when they bought stripe comm the previous owner of stripe comm still had a valid SSL certificate The certificate has since expired But for a little while there was some overlap and we thought it was worth mentioning because it's pretty notable And so next we set traffic on how big is this issue? So we search certificate transparency for certificates that overlap multiple domain registrations And so what we ended up doing is look at about three million to three million randomly selected domain names And they're associated seven point seven million certificates Which is about just one percent of the internet and to figure out domain name changes We ownership changes we looked at expression dates the email contacts and who is the registrar name servers and some other information And for this we use the certificate transparency logs historical Who is historical name servers and our capital orgs way back machine this analysis was not perfect There were some false pauses and false negatives But the should be low enough amount to our school is an idea the picture of how big this issue is And we found that about 1.5 million domain names on the internet or just less than half a percent of the internet have Certificate for a pre-existing domain name so means that these there are certificates that are made before the domain name was registered And are valid into its registration time and about 25% of these certificates have not expired yet I mean they are still valid and these owners of these certificates can actively right now man SL man the middle the other to the current domain in users And we are calling this new Phenomenon by gone SSL which is an SL search We are defining as SL certificate that is created before and supersedes its domain names current registration date So we try to figure out now could this be any worse? So as many of you probably know certificates have many domain names which are called alt names And this means that certificates can contain some by gone domain names and some they're not so in this example here We have a certificate for food a calm bar a calm Bar calm is only ever had one owner Our food a calm is what we're calling a by gone domain a mean is change owners and the certificate is valid for both of these domain names so again, we look for notable examples of this and We're choosing to sort of blur out most of this and not say which CDN because this is still an active issue But for one of the CDNs we looked at they actually had 700 customers put on the same certificate and it's common for CDNs to share certificates among customers but this one was notable because they put 700 on the same cert and They weren't paying any attention to whether or not domains transferred ownership So the one highlighted here actually was available for purchase it had expired and we could have You know easily bought it and then it would have become a by gone SSL certificate So basically we're left with two choices here like should we have the right to revoke these certificates as the new domain owner? if we say no You can imagine a scenario where a new company or startup shells out a whole bunch of money for like the perfect domain just for them And then they check the certificate transparency logs find out that the previous owner still has a valid cert And they have to live with it. There's nothing they can do It might be a three-year cert and they might have to just for the next three years Live with the fact that the previous owner still has a valid certificate Can imagine scenarios where bad guys may go out and purchase a whole bunch of desirable domains? Maybe single word demands and they could just squat on them and only selectively hand them out to e-commerce websites and They can set all that up so that they can get valid certificates and commit financial crimes And if we and if we say that they don't have the right to revoke these certs Then we just have to live with that reality and there's nothing we can do about it If we say yes, and we grant new owners the right to revoke these certificates Because certificates share multiple domains and because you can have a certificate like in the case of the CDN where you have many customers with legitimate domains and one One domain that's become bygone This would basically give Strangers on the internet the power to revoke these certificates and break the production websites of the other 700 customers on the cert in that case Or in the case of a company Maybe the company just gets a certificate puts five of their own domains on it And then one of those domains they no longer want to use it expires But the other domains are still actively using the cert This would give a stranger on the internet the power to take down all the other Websites using that certificate So you try to dig a little deeper and learn more about this and we learned about the CAB browser form And this is a group of representatives from both Certificate authorities on browsers that get together and create the set of rules that dictate how CAs and browsers operate And if this contracts that rules is broken browsers distrust certificate authorities And this set of rules is called the baseline requirements for the issuance and management of publicly trusted certificates It is very long and very dry, but in in section 9 6 3 on where it talks about Reporting revocation of SL certificates mentions that if any information in the certificate becomes inaccurate or incorrect that the certificate authority should revoke these certificate So there's a little bit of ambiguity with that What what it actually means for a certificate to become inaccurate? I don't actually know if it's if somebody issues a certificate and then they put some information in it and then That domain transfer is ownership. Is that information in accurate now? That's I think one could argue either way But this new section that we found four point nine point one one kind of puts the nail on the coffin It says basically if domain name registrants failed to renew their domain and certificate authorities become made aware of this Within 24 hours, they must revoke the certificate That seems really Explicit and cut and dry that being said we did speak to some CA B Members and they they were very upfront and they told us that these you know These documents are by and large created by lawyers not by engineers and they can be In some cases self-contradictory and in some cases some of the sections May be referenced by other sections in weird ways So the best we're understanding our interpretation is we can revoke these certificates But that's caveated by the fact these documents are really complicated and made by lawyers So going back to the prior example here We have a certificate for Buddha calm and far calm This means that the certificate food calm can be revoked because I share with food calm which has changed ownership so it means that Potentially anyone who finds a certificate can revoke bar.com's as a certificate causing a SL error for their users, which would be a denial of service And so looking at our same data set for examples of this where domain names cherry Serious cell certificate on my other domain with the salt name found that seven million domain names approximately are vulnerable Which is just over two two percent of the internet and that's a forex increase in our previous analysis and of these certificates 41% are still valid have not expired That means in theory maybe of these seven million domain names 41% of these can actively actively use if the certificate being used You can reach up to the CA and have them be revoked in theory so basically This this made us realize like those 300 or sorry three million certificates that are still valid if Ian and I wanted to we could potentially revoke all of them and The certificate authorities would have to revoke them within 24 hours of us asking them to We can break large swaths of the internet and more particularly CDNs that put multiple customers on the same certificate if they're not paying attention to domains transferring ownership We can render those CDNs Pretty unusable by just continuously spinning up new domains and revoking certificates with them so we're calling this issue by Ghana's SL and We we think it kind of deserves sort of a new class of vulnerability definition It's got two variants. The first is the one that we initially talked about by Ghana's SL man in the middle and that's what happens when you get a Certificate for a domain that you own and then you transfer ownership of that domain where it expires and You still have a valid SSL certificate for it when someone else picks up the new domain And that gives you the ability to man in the middle of the new owner And the other variant is by guys held on the service when we were just talking about here Where if a certificate has a subject alt name for a domain name that's no longer owned or can be taken over Then that new owner of that domain name can reach out to the CA and revoke that certificate For the formal domain name which can affect the non vote non by Ghana's So man the middle domain name causing a potential denial of service if the shared certificate is still in use So if you remember back to the example with 700 domains on it I mentioned that one of them was available for purchase. We purchased it it was like $11 and That to the best of our knowledge gives us the right to revoke the certificate and break the websites of the other 700 people using it So for our live demo, I'm gonna be tagging over to an email client and in real time I'm going to ask that they revoke this SSL certificate I'm just kidding. I'm really gonna do that but But we we totally to our understanding have the right to do that and they would have to do it within 24 hours Based on our understanding. So for our pre-recorded demo we reached out to a couple of certificate authorities to actually test this and We didn't do this with real CDNs. We just created certificates with subject alt names for a bunch of domains that we owned But we didn't make that immediately transparent to the certificate authorities So in the first case here, I reached out to digicert and I said hey this certificate that has some alt names on it Well, I just bought this domain and my domain is on that certificate Can you please revoke that old certificate? and They were really good about it within 24 hours. They actually did revoke the certificate and The other domains that we had that were using it in production broke if you tried to visit them they had HSTS enabled and you couldn't Render or visit them in any way because the SSL certificate was invalid or it was revoked Now the next one we reached out to was Amazon Amazon was also pretty good about it, but the issue what we had there was we didn't want to actually make an Amazon account and Really the only good way to get support from Amazon is to have an Amazon account So the previous owner of the certificate had an Amazon account We just wanted to reach out to some support and say hey, please revoke that So we we looked for an email that we could reach out to that might be able to route us to the right place The one we found was their ec2 abuse email that one was public and with a little bit of back and forth explaining the situation That actually worked. They were able to route us to the right place We had to verify ownership of the domain, but within a couple weeks. They also revoked the certificate Now on the other side of the coin we reached out to Komodo and we asked them to Same thing we asked them to revoke certificate And every single time we reached out to them via support chat and via email They basically told us this wasn't possible if we weren't the original people that created the certificate They weren't going to help us and in the bottom there You can actually see with one of the support chats. They told us You can forget about the old SSL certificate. Don't worry about that one, but you can buy a new one. No problem. We'll we'll sell you a new one So basically they they wouldn't help us and they tried to use it as an upselling opportunity to sell us other services So next we try using let's encrypt which is a little bit of a different type of CA They rely almost entirely on automation for tearing certificates revoking certificates for anything else using the ACME protocol And so their current policy and specified by ACME is to require proving ownership of all the domain names before you can revoke it so reach out to their CPS contact to Talk to them about this and they recognize that this is a conflict with the agreement in the CA browser form where you should revoke with just proving ownership of a subset of the domain names and However, it's not going what they'll do, but they are considering changing the policy to be more Compliant or to change this so in the future. This might be an automated way You can revoke these these lots encrypt certificates by proving a subset In the meantime, if you are vulnerable if you have a domain vulnerable to this there and you only have a subset of the domains There's no way you can get lots encrypt to revoke the certificate So next I'd like to point out a tool that wrote a while ago called cert graph and cert graph is an open source intelligence tool to call the graph of the certificate alternative names and this works basically you give a domain name and it will Find all certificates for that domain name and each of those all names and all the certificates Find all certificates for all those domain names and keep going and going until it creates a complete graph so in this example The purple node which is for EFF to org is the domain name I've provided it it reached out and found these certificates in the red nodes that are about that domain name And then offer those all names are the other green nodes that are related domain names it found And so you can use this tool I wrote it for doing domain name enumeration through a cell certificates It can use both connecting the sites over HTTP or using certificate transparency or SMTP or other protocols as well But you can use it to for deter finding Sites that are vulnerable for by gone SL to now of service Which can be very useful if you want to find sites that are vulnerable either yourself or for Target to announcement to about I'm a bug bounty and at the bottom here I just have the on the kind of options you provide to this to a numerate these domain names So you sell it to go depth one you need to create the entire graph just the graph of your target New York State driver Google which is using Google certificate transparency search engine Includes certificates very sub domain names includes certificates for CDNs And look at the DNS records of all the names found to see if they are unregistered and till D plus one will also Look up the top level domain name for a given domain and found so examples say WWW.EFF.org it would also check for EFF.org not just one level up But the actual domain name at the registrar level And so using this tool we found one example here with sales for so here I ran the tool on the domain name sales force comm it's up there the purple node and it created this graph And it all ended up here at Squarespace, which is no connection to sales force And so what happened is they're linked here via this chain of domain insert through do comm and the story here is that do comm Was once owned by sales force and they had a sales certificate for it And then they lost control of that domain name Squarespace bought it up But that all name was still being served by sales force's domain name giving one sales force Try Squarespace the ability to revoke a sales force comms production WWW.SalesForce.com a sales certificate and causing downtime for them Alternatively sales force comm could have man the middle Squarespace because they had a valid a sales certificate for one of their domain names And actually if you look at that graph the certificate that do comm is Shared with on sales force isn't just for sales force comm It's for a whole bunch of sites that circle of green dots on the left there if Squarespace wanted to they could Take that whole cert down and all of those websites from Salesforce would stop working Yeah, so they're a little deeper in this here We see on the left is the historical on DNS for do comm we find this isn't just unique to for this particular domain name Is not just unique does where space or sales force this domain name here has been hosted at Microsoft's name servers AWS and few others so at the period in time when that previous graph is taken we've highlighted in these red boxes In this example and the right we have a screenshot for that SL Certificate in question for both do comm and a wildcard do comm and all these other Salesforce domain names Taken from this year to essay certificate transparency search Basically what we were finding was for some of these single word domains They transfer ownership a lot and they usually transfer ownership from big companies So we think that this domain was actually owned by Microsoft at one point And it was owned by Salesforce and it was owned by Squarespace And all of that was potentially within the lifespan of one SSL certificate Which further strengthens the argument that a bad guy would potentially be able to squat on desirable domains And also for the point I believe last we checked this domain name was um available for purchase them wants to buy it So another tool that we we wrote this one specifically geared at finding just this problem is This by gone SSL tool that uses Facebook's API to again search certificate transparency logs And it's configured to look for both by gone SSL denial service and by gone SSL man in the middle All you have to do is give it accurate information on when you first registered a domain And to give it a complete list of all domains that you own and it'll tell you if any of your domains share certificates with Domains that you don't own and it'll also tell you if there are any SSL certificates that predate the date that you purchase the domain Another tool that we worked on writing is we added by gone a cell detection to SL made certain spotter and Search spotter is a certificate transparency log monitor So you'll run it yourself or you can use their hosted version and it looks at all the Certificate transparency logs looks for a cell certificates and alert you if a certificate is logged for a domain name that you're monitoring So you provide a watch list in this example here We have insecure design definitely or a torque on the net will compete it or again the valid at date Which would be the date that you have acquired access to this domain name and then it puts this little Bygone SL equals true flag in the domains output information if it finds that the certificate was generated before that valid at date But and also valid after and they you should be aware of the certificate You probably don't have control over it and might want to get it revoked And so at this point might be thinking like what can you do to protect your domain names or your own sites and The answer is kind of complicated The best you can do is use the expect CTH speed header with the enforced flag to ensure that only CT log search will be trusted for your domain name So that means that if a certificate is found or served for your site that is not insert surgery transparency it will not be trusted and One limitation of this is that this only protects users on their own Who first connect your legitimate site their first connection to your site is through somebody's man the middle of you There's nothing you can do unfortunately at this time And then of course if any previous in certificate it already exists for your domain name and it isn't CT logs It would still work with this case That's why it's important to monitor CT logs and reach out to the issuing CAs and have those certificates revoked for your domain names And so it's an all good thing to our next thing CT has only been acquired for non-EV certs since April of this year So prior to that certificates issued prior to April this year do not need to be in CT to be trusted by browsers There's so that prior existing cert is not in there. You don't know what's not in there. It's a double negative set But that being said there are certificates issued before April this year that are still in there For example, I had a certificate from 2009 show up in CT logs very recently So at any point in time So it gets me back ported or backlogged into CT So it's important to clean on our CT logs You can use our search bar and buy on a cell tools or your cert graph And then we also have some asks for the general internet Basically when you register a domain the registrar could do a check and certificate transparency for you And they could let you know ahead of time if a previous owner Still has a valid certificate. We think that would be a nice feature also CAs could shift to Models with a shorter lived SSL certificates or shorter life spans So let's encrypt kind of is paving the road for that their certificates can only be 90 days But other certificate authorities issue certificates that are much longer And we think that if they also cut down their lifetime, it wouldn't remediate the issue completely, but it would make it much less severe We think that also if you Do request that you revoke a certificate certificate authority should do due diligence and notify all the other alt names on the certificate When they do the revocation so that way denial of service doesn't just come from nowhere At least you have a little bit of a heads up We think that certificate authorities also shouldn't issue certificates that Exceed the lifespan of the domain registration. So when you register a domain There's an expiration date on that and we don't think certificate authority should give you certs that exceed that and right now There's no protection or limitation and and they will just give you a certificate that exceeds that that expiration date and then the last bullet here bullet point here really goes to CDNs Like we mentioned before in some cases. It's pretty extreme CDNs putting 700 customers on one cert We think that they should really move to a model that that puts each customer on their own cert And if you're using subject alt names, whether you're a CDN or a company you got to be really careful with it Because again based on our understanding Your customers basically have the right to revoke these certificates and in some cases render your services pretty unusable And that concludes our talk. Thank you all very much We have more patient on our demo site in secure design here are links to the tools we talked about and if you want to email us about this We have by going to sell in secure design. Does anyone have any questions is a question in the back Year So what if your account is still valid and you're still paying for the services just your domain name expires Basically So basically the the comment was that when And in some cases some CDNs will revoke certificates or stop using certificates when customers stop using their services Which is helpful and then the other point that we pointed out is you know What happens if customers still using their services, but the domain just expires And CDNs could monitor that based on the expiration date But one thing that's harder to monitor in that case is actually when the domain doesn't expire it just transfers ownership There's really not a good way for CDNs to know when that happened There's like a couple of high-level heuristics. You can tell based on who is and based on Some other stuff that we mentioned before But they're probably gonna run into the same problems that we do that there isn't a really good central source or authority that can tell you That a domain transferred ownership But that is good to hear that some CDNs are building in some protections against this Other questions yep Yeah, the screenshot we had earlier with all the stuff was bored out with 700 actual live customers Oh Yes, so repeat the question. Oh, sorry the question was are there any people who are still vulnerable to this after We have informed them that they were vulnerable to this And there may be some that I've not been mentioned The question basically is have we ever seen this being exploited in the wild by a malicious actor Not to my knowledge and not to mine either I think this is novel new But if there are any bad guys in the audience that want to prove us wrong by all means Basically the comment there was like if you take over a domain Like it wasn't intentionally transferred, but you take over domain and you get a certificate That also kind of manifests itself in the same capacity that like you're in this awkward state of like well Komodo won't revoke that certificate because you're not the one that created it And there are cases like that that we can definitely point to where someone was able to temporarily hijack a domain and generate a real SSL certificate. Yeah, so that's definitely happened a few times But I don't know the example or someone's done that and then revoke the other the actual users as cell certificate That'd be nothing. It hasn't happened. I just don't know that any gambles that Other questions cool think we're gonna cut off very much. Thanks everyone