Lost and Found Certificates
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Foster, Ian
Ayrey, Dylan
When purchasing a new domain name you would expect that you are the only one who can obtain a valid SSL certificate for it, however that is not always the case. When the domain had a prior owner(s), even several years prior, they may still possess a valid SSL certificate for it and there is very little you can do about it. Using Certificate Transparency, we examined millions of domains and certificates and found thousands of examples where the previous owner for a domain still possessed a valid SSL certificate for the domain long after it changed ownership. We will review the results from our ongoing large scale quantitative analysis over past and current domains and certificates. We'll explore the massive scale of the problem, what we can do about it, how you can protect yourself, and a proposed process change to make this less of a problem going forwards. We end by introducing BygoneSSL, a new tool and dashboard that shows an up to date view of affected domains and certificates using publicly available DNS data and Certificate Transparency logs. BygoneSSL will demonstrate how widespread the issue is, let domain owners determine if they could be affected, and can be used to track the number of affected domains over time.
 I have a warm DEF CON welcome for Ian Foster and Dylan Avery. Er- Er- Erry? Erry. Erry? Sorry. Lost and found certificates. So just as a quick introduction, as mentioned, this is Ian. He's a motorcycle hobbyist and DNS nerd. And this is Dylan. Let's go bike enthusiast and cat owner. Did you say cat owner? Yeah. It's true though. So basically the problem that we're going to be talking about today is what happens when an SSL certificate from a previous owner is still valid for the next owner of the domain. So the previous owner gets a real SSL certificate that they're allowed to do for their domain. The domain either expires for transfer ownership and then the new owner of the domain, they maybe don't realize that the previous owner still has a valid SSL certificate. And prior to 2013, there was really no way whatsoever to get any visibility of this. And really, like when you think about it, it seems kind of silly that this is even an issue. Yes. An example we have here at the bottom, we say Alice registered a domain name, in this case FUTA-COMP for one year and gets an SSL certificate, in this case three years more than the one year domain name. Our registration FUTA-COMP is unregistered because Alice doesn't renew it. Then Bob later registers FUTA-COMP, gets his own SSL certificate, completely unaware that Alice's SSL certificate is still valid for her domain name and she can encrypt traffic to it. So in order to help try to identify these certificates, we have certificate transparency. This was created as a public, publicly auditable log of all SSL certificates to help catch misbehaving certificate authorities. It's currently about half a billion certificates and growing. And basically, we can use certificate transparency to identify this issue, which gives us way more visibility than we had before. So basically, if the previous owner has an SSL certificate and it gets logged in CT, we can see it and we know from that that there are still certificates for our domain that we don't have control of. So we look for really notable examples of this and we were able to find some. One particular example is for Stripe. So if you're not familiar with Stripe, they're a really big online payment processor and a large percentage of transactions that you may have conducted online on e-commerce websites may have actually used Stripe under the hood. What we found was that the previous owner of Stripe.com still had a valid SSL certificate when Stripe bought it. And now the crossover was relatively short, but it didn't have to be. It could have been a five-year cert. It could have been all the way up to today. So we try to set out to figure out how big is this issue. So we search for certificate transparency to look for certificates that overlap to multiple domain ownerships or registrations. And the hard part of this is trying to figure out when a domain name changed hands. There's no easy way of doing this. The best way we could look at was historical who is, historical name servers, and the way back machine. And we surveyed three million random domain names from the Internet and their associate 7.7 million certificates, which makes up just about one percent of the entire Internet. It's a fairly small study, which should give an idea of what the entire Internet looks like. And we look for changes like expression date, email contact, registrar changes to try to determine whether or not a domain name has changed hands or not. And this type of analysis is not perfect. They're both false negatives and false positives. But it should still give us a good idea of what we're looking at. And we found that in our data set, about 40.45 percent of the domain names had previous SSL certificates, which strapped to the Internet is about 1.5 million domain names. And of the certificates for these one and a half million domain names, about 25 percent have not expired and are still valid right now. And so we are calling this problem like on SSL, which is we are defining as an SSL certificate created before and supersedes its domain's current registration date. And this is just another way of saying that the SSL certificate spans multiple domain name registrations. So could this be any worse? So as many of you might know, a certificate can be valid for multiple domain names. In this case, we have a certificate for both Food.com and Bar.com. And a certificate can be good for domain names and they have changed ownership. And some of the domain names may have not changed ownership. In this example, Bar.com has always had the same owner. In Bar.com, they have changed owners one or more times during the existence of this certificate. So if it's not immediately clear, a lot of CDNs will actually shove a whole bunch of customers on the same cert. And in this kind of extreme case, we found one instance of the CDN putting 700 of their customers on a single certificate. And we've made the decision to blur this out because this is still a valid issue. But if we were to show the domains used on the certificate, I promise everyone in this audience would recognize some of them. And what we found was the one unblurred domain there was actually currently unregistered and expired. And it was available for purchase. So basically, we have two options here of whether or not we can revoke these certificates. You know, the question is like, should we have the right to revoke these certificates? If you say no, then you can imagine shelling out a whole bunch of money for a new domain, maybe for your new start out. And you find that there's an old SSL certificate in CT that's going to last for another five years. And you just can't do anything about it. You just have to live with that fact. You can imagine a scenario where a bad guy might squat on a whole bunch of desirable looking domains and just selectively only give them out to e-commerce websites so that they could maintain SSL certificates and man in the middle of that traffic and steal financial data. On the other hand, if we say yes, if you can revoke these certificates, you get these situations where certificates have both bygone domains on them and non-bygone domains on them. A lot of cases are still used in production. And if you give the new owner the right to revoke these certificates, then all of a sudden they have the power to denial of service the websites that are still using that certificate for legitimate reasons. So it's really a lose-lose scenario. So we dug a little deeper and we learned about the CA and browser form. And this is a group of people made up of representatives from both web browsers and certificate authorities who create the base-on requirements for the issuance and management of public certificate certificates, which is just a long document that specifies how CA's and browsers should operate so that the certificate authorities can be trusted by the web browsers. And inside this very long document, section 963, subsection 5, it talks about revocation and the reporting of revocation. And it does specify that. If any information in a certificate becomes inaccurate or incorrect, that the certificate authority must revoke the certificate. So on the previous slide, inaccurate, that's kind of an ambiguous term. We found this other section, though, 4.9.1.1. And this one, in my opinion, is a lot more explicit. It basically says if the domain name registrant fails to renew the domain name, then if the certificate authority becomes made aware of that, that certificate authority has to revoke the certificate within 24 hours. Now, we're caveatting us with the fact that we were warned by CAB members that this document is very ambiguous and sometimes self-contradictory. The people that draft this document oftentimes lawyers, not actually engineers. That being said, to the best of our knowledge, we have the right and the power to revoke these certificates and we have the power to do so within 24 hours. So going back to the previous example of the certificate pool of food.com, bar.com, where one domain name is changed owners and one is not, this now means that if bar.com is still using the certificate that was available through bar.com, the new owner of food.com could reach out to bar.com certificate authority and revoke the certificate and cause a download service on them, or at least their users will get an SSL warning. And so looking at cases of this where domains share a certificate with other domains that are in ships at numbers skyrockets or cause a four times increase up to 7 million domains on the internet are potentially affected, about 2%. And of this sample set, about 41% just under half still haven't expired and are still valid and potentially still being used. So I mean at this point Ian and I are realizing we can break stuff, like a lot of stuff. Ian and I had the power to revoke something like 3 million certificates and the CAs had a legal obligation to do so within 24 hours. And most of those certificates, well I shouldn't say most, a lot of those certificates were still being used in production. So it would have broken all kinds of websites, all kind of places, a lot of the websites are definitely ones that you all are familiar with. And so we thought that this basically, there's no real clean fix to this, so we have to just introduce a new class of vulnerability. And there's two flavors to this, the first flavor is the one that we first introduced. It's when you get a new domain and you notice or don't notice, you see in the CT log that the previous owner still happens to have a valid SSL certificate. We're calling that variant the bygone SSL man in the middle variant. And the other type is the type I was just talking about which is the bygone SSL denial of service where you share a certificate and are still using it with an alt name which has expired or been acquired by someone else and that gives them the power to revoke the certificate that you're using. If they were to do that, that would take down your site. So if you remember back from a couple slides ago, there was that CDN that showed 700 customers on one cert. We now realize that if we bought that domain and reached out to the certificate authority, we could say, hey, the previous domain owner failed to renew, you have to revoke this thing. And we now have the power to revoke it and break 700 customers' websites. Now for our demo, I'm going to be tabbing over to an email client and in real time revoking the cert. Not really. But we totally have the power to do that. So for our pre-recorded demo, we have a couple of certs here that we did reach out to the certificate authorities just to see whether or not they would actually revoke them. So for the first example here on the left for Digisert, I should mention this cert had a subject alt name on it and the subject alt name was using that certificate in production. We reached out, we said, hey, one of the domains on this certificate belongs to us. Can you please revoke the cert? And the way we framed the email, it seemed like we didn't own the other domain. And within 24 hours, Digisert verified that we did own the one domain, didn't verify that we owned the other domain. They had no problem revoking the cert. So another example here, we reached out to Amazon and I should mention also, usually certificates have a little field on them called the CPS contact and the CPS contact is basically the email contact you want to reach out when you want to revoke the certificate. That's the contact that starts the 24 hour timer when you reach out to that. So we did that for Digisert. For Amazon, they actually didn't have a CPS contact on their certificate and it's kind of hard to reach out to AWS if you're not like a customer of AWS. So we tried to do this the best we can without actually creating an AWS account. And we found this public email, ec2abuse, at amazon.com. And that's the one we reached out to. It took a little bit of back and forth and a little bit of routing. But eventually that got us to the right certificate people. It took a couple of weeks, but again, they had no problem revoking the certificate for us. So this is our pre-recorded demo that failed. We reached out to Komodo and the same thing. We reached out to the CPS contact to ask them to revoke the certificate. And to this day, they still haven't revoked the certificate. They basically said, you're not the original owner. Like you didn't generate that certificate. We're not going to pay attention to you at all. And on the bottom there, you can see they actually tried to use it as an upselling opportunity saying, forget about the old certificate. We'll sell you a shiny new one. You just forget about the one that the previous owner still has. So next we tried the revoke certificate using GluttonCrip, which is a slightly different type of certificate authority. They use the ACME protocol to try to automate as much as they can with no human interaction. And currently if you use the ACME protocol to try to revoke a certificate, they require you to prove ownership of every domain name in the certificate in order to actually map the verification happen. So we reached out to their CPS contact and asked them about this. And they recognized that, or specified that this is their current policy, that they require you to prove ownership of all domains in the certificate to revoke. And they recognized that it is a slight conflict with the CA browser form and that they are currently considering a change of policy to prevent this. There might exist a case where someone has a certificate for a domain name that you might have that domain name for, because you lost the domain name required from them. So at GluttonCrip we were not able to revoke the certificate, but it could be possible. And if GluttonCrip implements that, it's also worth pointing out that that'll be real-time replication. It won't be like 24 hours while the CA reaches out kind of thing. Because their whole system is real-time automated, if you use GluttonCrip and one of your domains on your certificate comes bygone, instantly somebody on the Internet will be able to revoke your certificate. Very true. So now I'll talk a little about cert graph. This is a tool I made a while ago. It's an open source intelligence gathering tool that crawls the graph of the certificate alt names. It works by you give it a domain name, it finds all the SEL certificates of that domain name, goes through, gets all the alt names of all the certs, gets all the certificates for all those alt names, and continues to grow and grow until you get a complete graph of all domain names and certificates for a given domain name or property. It was built the idea of domain name enumeration for red team targets, but it's very useful for trying to find vulnerable domain names for bygone and sell denial of service as well. This is an example of a graph generated with this tool on the FS website. So one particular example we found this was at Salesforce. So we ran this in Salesforce.com, it created this nice graph, it's squarespace.com, which is nothing new to Salesforce. And this was because Salesforce.com used to own do.com, lost that domain name somehow, Squarespace got it, not sure it expired, they transferred, but they kept in the Salesforce.com SEL certificate, the one that read dot in the center of the circle of green on the left, that SEL certificate was good for do.com, and it was good for do.com far after they owned it and after Squarespace had it. So Salesforce had a valid SEL certificate for another company at this time. And this gives one Salesforce ability to potentially on the middle squarespace.com and also special case of a calm could have revoked sales forces as a certificate taking down their site. And if you look on the left side, all those like green in circle domains around that certificate, those are all the websites that would all of a sudden break if Squarespace decided to revoke this thing within 24 hours. Yeah. So this is digging a little deeper into the do.com example. We can see on the right is the certificate in question on the top part. We have been read the dates that was valid before and after you can see those between the two owners and all the domain names those valid for sales forces and do.com. And then the left we have historical and S lookups for this domain name on the screenshot was taken after the domain name had been transferred to where it currently is right now. I believe it's like a for sale auction sites. Some of us can go by that domain name if they want. But on the circle red part is when Salesforce had the domain name in the past, so you can see historical name services being hosted at Microsoft, AWS and a few other places as well. So we wanted to also introduce the tools specifically crafted for finding this. So circraft is a nice visualization tool. We created a new tool that uses the Facebook certificate transparency API to both detect by gone SSL denial of service and by gone SSL man in the middle. Now, let's caveat it with the fact that you have to give it accurate information. So to detect by gone SSL man in the middle, you need to give it a complete list of all them or you give it the list of all domains you own with an accurate date on when you first registered it. So maybe you renewed it a couple times and the created date on the who is record doesn't actually reflect the first time you created it. You need to make sure that actually reflects the first time you bought the domain. And then to detect by gone SSL man in the middle, you give it a list of all domains that you own and it will go through and see if any of those domains share certificates with domains that you don't own. So for this to be accurate, you need to give it a complete list of all domains your own as long as you do those two things have an accurate registration date and a complete list of all domains your own. You don't get any false positives and it can very accurately detect both flavors of the problem. The two downsides to using this tool, first, you have to create a Facebook developer account and give them the token. And the second downside is Facebook actually will rate limit you if you hit it too aggressively. And lastly, we've created another tool, the by gone SSL certificate transparency log monitor and this access a certificate transparency actual log. We use a SL may search bar tool and added in by gone SL detection to that so you create a config file for the domain names for the certificates you want to be alert for, specify valid at date, which is the date that you acquired the domain name. And then whenever it finds matching shirt, you'll print out or notify you the phone patient like in the screenshot right here. And if it happens to notice that the certificate is valid for both the four and after the date that you acquired it, it puts us a little by gone SL go shoe flag. And the changes have been accepted upstream into SL may search spotter so you can grab that from them if you want to run your own certificate transparency log monitor. Although note that we'll look through all the half a billion certificates in CT and it will take some time but if you want to complete self hosted solution, this will work great. So if you want to try to protect yourself from being vulnerable from by gone SL or someone else having a SL certificate for your domain name or potentially revoking one that you're using. And the best you can do right now is to use the expect CT header with the enforce flag on your HP server. This will protect you from someone else having a SL certificate for your domain names that's not in CT and using it on you. However, this will not protect you if the case for the certificate is already been logged in CT. There is no current protection against that. The best thing you can do is monitor CT logs using our tools or others for all SL certificates for your own domain names. And if you see a certificate for your domain name either before, issue before you got it or after, reach out to the CA and ask them to revoke it. And it should also point out that not all certificates will be in CT logs. CT was only required for browsers like Chrome as of April this year for non-EP certificates. Certificates issued before then, a lot of them are in there. I've seen certificates as early as 2009 and before in certificate transparency logs, but it's not a requirement to be trusted by browsers. So now we've got some requests for the general internet as well. You realize this issue isn't going away. We have some basically band-aid asks. For example, registrars could notify new, first register a domain name. The registrar gives you a heads up and say, hey, we checked CT and the previous owner still has a valid certificate. They might even also consider auto revocation in certain cases. Another ask is if these certificates are much shorter-lived, like the let's encrypt 90-day policy, the issue is still there, but it's there for a shorter period of time. We don't have to deal with the five-year issue that we talked about before. When you do your revocation, it's kind of courteous to give a heads up to the other people using certificates with subject alt names so you don't accidentally break production websites. But as mentioned before, there's no mechanism stopping you from breaking production websites. And CAs could also not issue certificates that go on beyond the expiration date of a domain. So if you do who is on the domain, you see the expiration date. There's no reason why the certificate should ever outlive that. So CAs could just not issue certs that outlive the lifetime of the domain. And then the last bullet point here is really targeted at CDN specifically, but also just generally companies. You got to be really careful with the way you use subject alt names. If you shove a whole bunch of demands on the same certificate, in kind of the worst case there, 700, one of them might become expired and that's going to open yourself up to a stranger revoking your certificate. So a recommendation there is kind of you could do what GitHub is doing with GitHub pages. They have every single customer on their own. Let's encrypt certs. You can use custom demand. But if you share customers on the same cert, you're opening yourself up. All right. That concludes our talk. Here are the links to the tools that we talked about and our insecure design website where we have more information on this topic. Thank you all very much. And we'll take questions outside.
 I have a warm DEF CON welcome for Ian Foster and Dylan Avery.  Er- Er- Erry?  Erry.  Erry?  Sorry.  Lost and found certificates.  So just as a quick introduction, as mentioned, this is Ian.  He's a motorcycle hobbyist and DNS nerd.  And this is Dylan.  Let's go bike enthusiast and cat owner.  Did you say cat owner?  Yeah.  It's true though.  So basically the problem that we're going to be talking about today is what happens  when an SSL certificate from a previous owner is still valid for the next owner of the domain.  So the previous owner gets a real SSL certificate that they're allowed to do for their domain.  The domain either expires for transfer ownership and then the new owner of the domain, they  maybe don't realize that the previous owner still has a valid SSL certificate.  And prior to 2013, there was really no way whatsoever to get any visibility of this.  And really, like when you think about it, it seems kind of silly that this is even an issue.  Yes.  An example we have here at the bottom, we say Alice registered a domain name, in this  case FUTA-COMP for one year and gets an SSL certificate, in this case three years more  than the one year domain name.  Our registration FUTA-COMP is unregistered because Alice doesn't renew it.  Then Bob later registers FUTA-COMP, gets his own SSL certificate, completely unaware that Alice's SSL  certificate is still valid for her domain name and she can encrypt traffic to it.  So in order to help try to identify these certificates, we have certificate transparency.  This was created as a public, publicly auditable log of all SSL certificates to help catch  misbehaving certificate authorities.  It's currently about half a billion certificates and growing.  And basically, we can use certificate transparency to identify this issue, which gives us way  more visibility than we had before.  So basically, if the previous owner has an SSL certificate and it gets logged in CT, we can  see it and we know from that that there are still certificates for our domain that we don't  have control of.  So we look for really notable examples of this and we were able to find some.  One particular example is for Stripe.  So if you're not familiar with Stripe, they're a really big online payment processor and a large  percentage of transactions that you may have conducted online on e-commerce websites may have  actually used Stripe under the hood.  What we found was that the previous owner of Stripe.com still had a valid SSL certificate when  Stripe bought it.  And now the crossover was relatively short, but it didn't have to be.  It could have been a five-year cert.  It could have been all the way up to today.  So we try to set out to figure out how big is this issue.  So we search for certificate transparency to look for certificates that overlap to multiple  domain ownerships or registrations.  And the hard part of this is trying to figure out when a domain name changed hands.  There's no easy way of doing this.  The best way we could look at was historical who is, historical name servers, and the way  back machine.  And we surveyed three million random domain names from the Internet and their associate  7.7 million certificates, which makes up just about one percent of the entire Internet.  It's a fairly small study, which should give an idea of what the entire Internet looks like.  And we look for changes like expression date, email contact, registrar changes to try to  determine whether or not a domain name has changed hands or not.  And this type of analysis is not perfect.  They're both false negatives and false positives.  But it should still give us a good idea of what we're looking at.  And we found that in our data set, about 40.45 percent of the domain names had previous SSL  certificates, which strapped to the Internet is about 1.5 million domain names.  And of the certificates for these one and a half million domain names, about 25 percent  have not expired and are still valid right now.  And so we are calling this problem like on SSL, which is we are defining as an SSL certificate  created before and supersedes its domain's current registration date.  And this is just another way of saying that the SSL certificate spans multiple domain name registrations.  So could this be any worse?  So as many of you might know, a certificate can be valid for multiple domain names.  In this case, we have a certificate for both Food.com and Bar.com.  And a certificate can be good for domain names and they have changed ownership.  And some of the domain names may have not changed ownership.  In this example, Bar.com has always had the same owner.  In Bar.com, they have changed owners one or more times during the existence of this certificate.  So if it's not immediately clear, a lot of CDNs will actually shove a whole bunch of customers on the same cert.  And in this kind of extreme case, we found one instance of the CDN putting 700 of their customers on a single certificate.  And we've made the decision to blur this out because this is still a valid issue.  But if we were to show the domains used on the certificate, I promise everyone in this audience would recognize some of them.  And what we found was the one unblurred domain there was actually currently unregistered and expired.  And it was available for purchase.  So basically, we have two options here of whether or not we can revoke these certificates.  You know, the question is like, should we have the right to revoke these certificates?  If you say no, then you can imagine shelling out a whole bunch of money for a new domain, maybe for your new start out.  And you find that there's an old SSL certificate in CT that's going to last for another five years.  And you just can't do anything about it. You just have to live with that fact.  You can imagine a scenario where a bad guy might squat on a whole bunch of desirable looking domains  and just selectively only give them out to e-commerce websites so that they could maintain SSL certificates  and man in the middle of that traffic and steal financial data.  On the other hand, if we say yes, if you can revoke these certificates,  you get these situations where certificates have both bygone domains on them and non-bygone domains on them.  A lot of cases are still used in production.  And if you give the new owner the right to revoke these certificates,  then all of a sudden they have the power to denial of service the websites that are still using that certificate for legitimate reasons.  So it's really a lose-lose scenario.  So we dug a little deeper and we learned about the CA and browser form.  And this is a group of people made up of representatives from both web browsers and certificate authorities  who create the base-on requirements for the issuance and management of public certificate certificates,  which is just a long document that specifies how CA's and browsers should operate  so that the certificate authorities can be trusted by the web browsers.  And inside this very long document, section 963, subsection 5, it talks about revocation and the reporting of revocation.  And it does specify that.  If any information in a certificate becomes inaccurate or incorrect,  that the certificate authority must revoke the certificate.  So on the previous slide, inaccurate, that's kind of an ambiguous term.  We found this other section, though, 4.9.1.1.  And this one, in my opinion, is a lot more explicit.  It basically says if the domain name registrant fails to renew the domain name,  then if the certificate authority becomes made aware of that,  that certificate authority has to revoke the certificate within 24 hours.  Now, we're caveatting us with the fact that we were warned by CAB members  that this document is very ambiguous and sometimes self-contradictory.  The people that draft this document oftentimes lawyers, not actually engineers.  That being said, to the best of our knowledge, we have the right and the power to revoke these certificates  and we have the power to do so within 24 hours.  So going back to the previous example of the certificate pool of food.com, bar.com,  where one domain name is changed owners and one is not,  this now means that if bar.com is still using the certificate that was available through bar.com,  the new owner of food.com could reach out to bar.com certificate authority  and revoke the certificate and cause a download service on them,  or at least their users will get an SSL warning.  And so looking at cases of this where domains share a certificate with other domains  that are in ships at numbers skyrockets or cause a four times increase  up to 7 million domains on the internet are potentially affected, about 2%.  And of this sample set, about 41% just under half still haven't expired  and are still valid and potentially still being used.  So I mean at this point Ian and I are realizing we can break stuff, like a lot of stuff.  Ian and I had the power to revoke something like 3 million certificates  and the CAs had a legal obligation to do so within 24 hours.  And most of those certificates, well I shouldn't say most, a lot of those certificates  were still being used in production. So it would have broken all kinds of websites,  all kind of places, a lot of the websites are definitely ones that you all are familiar with.  And so we thought that this basically, there's no real clean fix to this,  so we have to just introduce a new class of vulnerability.  And there's two flavors to this, the first flavor is the one that we first introduced.  It's when you get a new domain and you notice or don't notice, you see in the CT log  that the previous owner still happens to have a valid SSL certificate.  We're calling that variant the bygone SSL man in the middle variant.  And the other type is the type I was just talking about which is the bygone SSL denial of service  where you share a certificate and are still using it with an alt name which has expired  or been acquired by someone else and that gives them the power to revoke the certificate that you're using.  If they were to do that, that would take down your site.  So if you remember back from a couple slides ago, there was that CDN that showed 700 customers on one cert.  We now realize that if we bought that domain and reached out to the certificate authority,  we could say, hey, the previous domain owner failed to renew, you have to revoke this thing.  And we now have the power to revoke it and break 700 customers' websites.  Now for our demo, I'm going to be tabbing over to an email client and in real time revoking the cert.  Not really.  But we totally have the power to do that.  So for our pre-recorded demo, we have a couple of certs here that we did reach out to the certificate authorities  just to see whether or not they would actually revoke them.  So for the first example here on the left for Digisert, I should mention this cert had a subject alt name on it  and the subject alt name was using that certificate in production.  We reached out, we said, hey, one of the domains on this certificate belongs to us.  Can you please revoke the cert?  And the way we framed the email, it seemed like we didn't own the other domain.  And within 24 hours, Digisert verified that we did own the one domain, didn't verify that we owned the other domain.  They had no problem revoking the cert.  So another example here, we reached out to Amazon and I should mention also, usually certificates have a little field on them  called the CPS contact and the CPS contact is basically the email contact you want to reach out when you want to revoke the certificate.  That's the contact that starts the 24 hour timer when you reach out to that.  So we did that for Digisert.  For Amazon, they actually didn't have a CPS contact on their certificate and it's kind of hard to reach out to AWS  if you're not like a customer of AWS.  So we tried to do this the best we can without actually creating an AWS account.  And we found this public email, ec2abuse, at amazon.com.  And that's the one we reached out to.  It took a little bit of back and forth and a little bit of routing.  But eventually that got us to the right certificate people.  It took a couple of weeks, but again, they had no problem revoking the certificate for us.  So this is our pre-recorded demo that failed.  We reached out to Komodo and the same thing.  We reached out to the CPS contact to ask them to revoke the certificate.  And to this day, they still haven't revoked the certificate.  They basically said, you're not the original owner.  Like you didn't generate that certificate.  We're not going to pay attention to you at all.  And on the bottom there, you can see they actually tried to use it as an upselling opportunity saying,  forget about the old certificate.  We'll sell you a shiny new one.  You just forget about the one that the previous owner still has.  So next we tried the revoke certificate using GluttonCrip,  which is a slightly different type of certificate authority.  They use the ACME protocol to try to automate as much as they can with no human interaction.  And currently if you use the ACME protocol to try to revoke a certificate,  they require you to prove ownership of every domain name in the certificate  in order to actually map the verification happen.  So we reached out to their CPS contact and asked them about this.  And they recognized that, or specified that this is their current policy,  that they require you to prove ownership of all domains in the certificate to revoke.  And they recognized that it is a slight conflict with the CA browser form  and that they are currently considering a change of policy to prevent this.  There might exist a case where someone has a certificate for a domain name  that you might have that domain name for,  because you lost the domain name required from them.  So at GluttonCrip we were not able to revoke the certificate,  but it could be possible.  And if GluttonCrip implements that, it's also worth pointing out  that that'll be real-time replication.  It won't be like 24 hours while the CA reaches out kind of thing.  Because their whole system is real-time automated,  if you use GluttonCrip and one of your domains on your certificate comes bygone,  instantly somebody on the Internet will be able to revoke your certificate.  Very true.  So now I'll talk a little about cert graph.  This is a tool I made a while ago.  It's an open source intelligence gathering tool that crawls the graph of the certificate alt names.  It works by you give it a domain name,  it finds all the SEL certificates of that domain name,  goes through, gets all the alt names of all the certs,  gets all the certificates for all those alt names,  and continues to grow and grow until you get a complete graph of all domain names  and certificates for a given domain name or property.  It was built the idea of domain name enumeration for red team targets,  but it's very useful for trying to find vulnerable domain names for bygone and sell denial of service as well.  This is an example of a graph generated with this tool on the FS website.  So one particular example we found this was at Salesforce.  So we ran this in Salesforce.com, it created this nice graph,  it's squarespace.com, which is nothing new to Salesforce.  And this was because Salesforce.com used to own do.com,  lost that domain name somehow, Squarespace got it, not sure it expired,  they transferred, but they kept in the Salesforce.com SEL certificate,  the one that read dot in the center of the circle of green on the left,  that SEL certificate was good for do.com,  and it was good for do.com far after they owned it and after Squarespace had it.  So Salesforce had a valid SEL certificate for another company at this time.  And this gives one Salesforce ability to potentially on the middle squarespace.com  and also special case of a calm could have revoked sales forces as a certificate taking down their site.  And if you look on the left side, all those like green in circle domains around that certificate,  those are all the websites that would all of a sudden break if Squarespace decided to revoke this thing within 24 hours.  Yeah.  So this is digging a little deeper into the do.com example.  We can see on the right is the certificate in question on the top part.  We have been read the dates that was valid before and after you can see those between the two owners  and all the domain names those valid for sales forces and do.com.  And then the left we have historical and S lookups for this domain name on the screenshot was taken after the domain name had been transferred to where it currently is right now.  I believe it's like a for sale auction sites.  Some of us can go by that domain name if they want.  But on the circle red part is when Salesforce had the domain name in the past,  so you can see historical name services being hosted at Microsoft, AWS and a few other places as well.  So we wanted to also introduce the tools specifically crafted for finding this.  So circraft is a nice visualization tool.  We created a new tool that uses the Facebook certificate transparency API to both detect by gone SSL denial of service and by gone SSL man in the middle.  Now, let's caveat it with the fact that you have to give it accurate information.  So to detect by gone SSL man in the middle, you need to give it a complete list of all them or you give it the list of all domains you own with an accurate date on when you first registered it.  So maybe you renewed it a couple times and the created date on the who is record doesn't actually reflect the first time you created it.  You need to make sure that actually reflects the first time you bought the domain.  And then to detect by gone SSL man in the middle, you give it a list of all domains that you own and it will go through and see if any of those domains share certificates with domains that you don't own.  So for this to be accurate, you need to give it a complete list of all domains your own as long as you do those two things have an accurate registration date and a complete list of all domains your own.  You don't get any false positives and it can very accurately detect both flavors of the problem.  The two downsides to using this tool, first, you have to create a Facebook developer account and give them the token.  And the second downside is Facebook actually will rate limit you if you hit it too aggressively.  And lastly, we've created another tool, the by gone SSL certificate transparency log monitor and this access a certificate transparency actual log.  We use a SL may search bar tool and added in by gone SL detection to that so you create a config file for the domain names for the certificates you want to be alert for,  specify valid at date, which is the date that you acquired the domain name.  And then whenever it finds matching shirt, you'll print out or notify you the phone patient like in the screenshot right here.  And if it happens to notice that the certificate is valid for both the four and after the date that you acquired it, it puts us a little by gone SL go shoe flag.  And the changes have been accepted upstream into SL may search spotter so you can grab that from them if you want to run your own certificate transparency log monitor.  Although note that we'll look through all the half a billion certificates in CT and it will take some time but if you want to complete self hosted solution, this will work great.  So if you want to try to protect yourself from being vulnerable from by gone SL or someone else having a SL certificate for your domain name or potentially revoking one that you're using.  And the best you can do right now is to use the expect CT header with the enforce flag on your HP server.  This will protect you from someone else having a SL certificate for your domain names that's not in CT and using it on you.  However, this will not protect you if the case for the certificate is already been logged in CT.  There is no current protection against that.  The best thing you can do is monitor CT logs using our tools or others for all SL certificates for your own domain names.  And if you see a certificate for your domain name either before, issue before you got it or after, reach out to the CA and ask them to revoke it.  And it should also point out that not all certificates will be in CT logs. CT was only required for browsers like Chrome as of April this year for non-EP certificates.  Certificates issued before then, a lot of them are in there.  I've seen certificates as early as 2009 and before in certificate transparency logs, but it's not a requirement to be trusted by browsers.  So now we've got some requests for the general internet as well.  You realize this issue isn't going away.  We have some basically band-aid asks.  For example, registrars could notify new, first register a domain name.  The registrar gives you a heads up and say, hey, we checked CT and the previous owner still has a valid certificate.  They might even also consider auto revocation in certain cases.  Another ask is if these certificates are much shorter-lived, like the let's encrypt 90-day policy, the issue is still there, but it's there for a shorter period of time.  We don't have to deal with the five-year issue that we talked about before.  When you do your revocation, it's kind of courteous to give a heads up to the other people using certificates with subject alt names so you don't accidentally break production websites.  But as mentioned before, there's no mechanism stopping you from breaking production websites.  And CAs could also not issue certificates that go on beyond the expiration date of a domain.  So if you do who is on the domain, you see the expiration date.  There's no reason why the certificate should ever outlive that.  So CAs could just not issue certs that outlive the lifetime of the domain.  And then the last bullet point here is really targeted at CDN specifically, but also just generally companies.  You got to be really careful with the way you use subject alt names.  If you shove a whole bunch of demands on the same certificate, in kind of the worst case there, 700, one of them might become expired and that's going to open yourself up to a stranger revoking your certificate.  So a recommendation there is kind of you could do what GitHub is doing with GitHub pages.  They have every single customer on their own.  Let's encrypt certs.  You can use custom demand.  But if you share customers on the same cert, you're opening yourself up.  All right.  That concludes our talk.  Here are the links to the tools that we talked about and our insecure design website where we have more information on this topic.  Thank you all very much.  And we'll take questions outside.
DEF_CON_26_-_Foster_and_Ayrey_-_Dealing_with_Residual_Certificates_for_Pre-owned_Domains_gZ9_-YQ4hoY_0_2003.png DEF_CON_26_-_Foster_and_Ayrey_-_Dealing_with_Residual_Certificates_for_Pre-owned_Domains_gZ9_-YQ4hoY_2004_2783.png DEF_CON_26_-_Foster_and_Ayrey_-_Dealing_with_Residual_Certificates_for_Pre-owned_Domains_gZ9_-YQ4hoY_2784_2855.png DEF_CON_26_-_Foster_and_Ayrey_-_Dealing_with_Residual_Certificates_for_Pre-owned_Domains_gZ9_-YQ4hoY_2856_5915.png DEF_CON_26_-_Foster_and_Ayrey_-_Dealing_with_Residual_Certificates_for_Pre-owned_Domains_gZ9_-YQ4hoY_5916_6947.png DEF_CON_26_-_Foster_and_Ayrey_-_Dealing_with_Residual_Certificates_for_Pre-owned_Domains_gZ9_-YQ4hoY_6948_7067.png DEF_CON_26_-_Foster_and_Ayrey_-_Dealing_with_Residual_Certificates_for_Pre-owned_Domains_gZ9_-YQ4hoY_7068_7187.png DEF_CON_26_-_Foster_and_Ayrey_-_Dealing_with_Residual_Certificates_for_Pre-owned_Domains_gZ9_-YQ4hoY_7188_9107.png DEF_CON_26_-_Foster_and_Ayrey_-_Dealing_with_Residual_Certificates_for_Pre-owned_Domains_gZ9_-YQ4hoY_9108_9167.png DEF_CON_26_-_Foster_and_Ayrey_-_Dealing_with_Residual_Certificates_for_Pre-owned_Domains_gZ9_-YQ4hoY_9168_9287.png DEF_CON_26_-_Foster_and_Ayrey_-_Dealing_with_Residual_Certificates_for_Pre-owned_Domains_gZ9_-YQ4hoY_9288_9335.png DEF_CON_26_-_Foster_and_Ayrey_-_Dealing_with_Residual_Certificates_for_Pre-owned_Domains_gZ9_-YQ4hoY_9336_10295.png DEF_CON_26_-_Foster_and_Ayrey_-_Dealing_with_Residual_Certificates_for_Pre-owned_Domains_gZ9_-YQ4hoY_10296_12647.png DEF_CON_26_-_Foster_and_Ayrey_-_Dealing_with_Residual_Certificates_for_Pre-owned_Domains_gZ9_-YQ4hoY_12648_12983.png DEF_CON_26_-_Foster_and_Ayrey_-_Dealing_with_Residual_Certificates_for_Pre-owned_Domains_gZ9_-YQ4hoY_12984_13031.png DEF_CON_26_-_Foster_and_Ayrey_-_Dealing_with_Residual_Certificates_for_Pre-owned_Domains_gZ9_-YQ4hoY_13032_19571.png DEF_CON_26_-_Foster_and_Ayrey_-_Dealing_with_Residual_Certificates_for_Pre-owned_Domains_gZ9_-YQ4hoY_19572_19739.png DEF_CON_26_-_Foster_and_Ayrey_-_Dealing_with_Residual_Certificates_for_Pre-owned_Domains_gZ9_-YQ4hoY_19740_19823.png DEF_CON_26_-_Foster_and_Ayrey_-_Dealing_with_Residual_Certificates_for_Pre-owned_Domains_gZ9_-YQ4hoY_19824_20027.png DEF_CON_26_-_Foster_and_Ayrey_-_Dealing_with_Residual_Certificates_for_Pre-owned_Domains_gZ9_-YQ4hoY_20028_26135.png DEF_CON_26_-_Foster_and_Ayrey_-_Dealing_with_Residual_Certificates_for_Pre-owned_Domains_gZ9_-YQ4hoY_26136_30479.png DEF_CON_26_-_Foster_and_Ayrey_-_Dealing_with_Residual_Certificates_for_Pre-owned_Domains_gZ9_-YQ4hoY_30480_30575.png DEF_CON_26_-_Foster_and_Ayrey_-_Dealing_with_Residual_Certificates_for_Pre-owned_Domains_gZ9_-YQ4hoY_30576_31295.png DEF_CON_26_-_Foster_and_Ayrey_-_Dealing_with_Residual_Certificates_for_Pre-owned_Domains_gZ9_-YQ4hoY_31296_31439.png DEF_CON_26_-_Foster_and_Ayrey_-_Dealing_with_Residual_Certificates_for_Pre-owned_Domains_gZ9_-YQ4hoY_31440_31727.png DEF_CON_26_-_Foster_and_Ayrey_-_Dealing_with_Residual_Certificates_for_Pre-owned_Domains_gZ9_-YQ4hoY_31728_31828.png