4 ms·

Why is this something they should do? If I have complete control over a subdomain bar.foo.example.com, why do I need cooperation from the parent foo.example.com

by eridius 11y ago

Why is this something they should do? If I have complete control over a subdomain bar.foo.example.com, why do I need cooperation from the parent foo.example.com in order to set up something basic like an SSL certificate?

Ao7bei3s 11y ago
Because A records don't mean complete control over domains. There is a difference between "I can serve content under this domain (currently)" and "I control this domain (and can decide where it points)". DNS domain validation is the right way to do domain validation. But it's slightly harder for users, which is why HTTP(s)- or E-Mail-based validation is being done more often.
- simoncion 11y ago
  > There is a difference between "I can serve content under this domain (currently)" and "I control this domain (and can decide where it points)". Agreed. However, I have a hard time believing that it's a net win to make it impossible for people who are permitted to control the machines that a DNS record points to, but are not permitted to alter that DNS record and/or anything under it [0] to get a cert from Let's Encypt. [0] Or are -perhaps- using a DNS hosting provider that doesn't let you add TXT or CNAME records. (I've used such a sorry provider in the past. :/ )
  - btown 11y ago
    But consider an attacker who pivots onto your entire infrastructure to serve any content they desire. Presumably your DNS provider passwords are stored in a password manager outside of that infrastructure. The attacker would still need to use social engineering to trick the CTO into revealing those passwords. It seems that would have prevented the abuse in the OP, right?
    - simoncion 11y ago
      > But consider an attacker who pivots onto your entire infrastructure to serve any content they desire. I mean, if we're talking about a situation where an attacker controls your webserver, then that's pretty much game over, right? They can read and write to everything your server can, including SSL private keys, SQL databases, etc., etc., etc... > Presumably your DNS provider passwords are stored in a password manager outside of that infrastructure. ... It seems that would have prevented the abuse in the OP, right? Doing DNS-record-alteration-only verification would have prevented the scenario described in TFA, yeah. But, there are a couple of things to consider: * DV certs provide nothing more than HTTPS, without the scary "THE BROWSER DOESN'T RECOGNIZE THIS CERT ISSUER!!11" dialog. They don't provide the additional UI cues that EV certs do. So, their phishing utility is rather limited. * Society as a whole benefits far more from thwarting passive dragnet surveillance than it does from putting roadblocks in the way of occasional unauthorized and unwanted issuance of a DV cert to someone who has improperly (effectively) gained control of someone else's web server or DNS zone. * TFA is primarily a scare-piece from a traditional CA <strike>that's likely sad that their revenue stream from DV issuance is going to vanish.</strike> Ugh. I actually got off my ass and did some research... it seems that Trend Micro doesn't issue DV certs. [0] Mea culpa. [0] http://esupport.trendmicro.com/solution/en-US/1097653.aspx http://esupport.trendmicro.com/solution/en-US/1097653.aspx
- corobo 11y ago
  I can serve using HTTP on this domain should be enough to prove you can also serve HTTPS on this domain though. It's on the domain owner to avoid giving away control of their (sub)domain to a malicious party. Exactly the same as with regular HTTP and anything else that uses DNS.
  - Ao7bei3s 11y ago
    It's not about proving that you can serve HTTPS, it's about proving that you can legitimately serve HTTPS. I'd find HTTP(S)-based validation ok if CAs wouldn't issue certificates with an expiration time past the expiration time of the DNS records. Of course that would be fairly impractical. But then DNS-based validation exists and doesn't have these problems.
    - eridius 11y ago
      What is the difference between serving HTTPS and "legitimately" serving HTTPS? Or to put it another way, what qualifies as "illegitimate" HTTPS?
zamalek 11y ago
Because this happened: > Website owners should ensure that they secure their own website control panels, to ensure that new subdomains beyond their control are not created without their knowledge. You're a bank and haven't secured your DNS control panel correctly. Someone comes along, and using your vulnerable DNS, registers logon.bank.com (instead of login.bank.com). Now it is the bank's fault to begin with, but end-users are going to see that green padlock and will get pwned. You can point fingers all you want at the bank but that situation could (and should) have been avoided. Let's Encrypt could be seen as a "vulnerability amplifier." With the previous PKI, even if you gained authority over logon.bank.com you wouldn't be able to get that green padlock in the title bar. There is a very good chance that someone at the CA would have made a phone call to someone at bank.com. With the current Let's Encrypt approach this scenario becomes plausible because no check is made with the parent domain to find out exactly how paranoid it is about subdomains. Nobody is blaming Let's Encrypt, but they can help.
- pfg 11y ago
  It's completely unclear whether what you're saying is factually correct. If the attacker controls the bank's DNS, which seems likely given that they're able to create an A record for a subdomain, they can likely also add TXT records for bank.com, which is what traditional CAs often use to verify ownership. They could probably also modify MX records to redirect confirmation emails to a server under their control. Other CAs don't have a magic solution that automatically detects malicious domains. Issuance of DV certs is completely automated at any major CA. There is no manual review unless the domain is on some kind of grey- or blacklist, and I highly doubt that they have a list of every domain used by a bank. There have been numerous counts of unauthorized certificates being issued by almost all CAs, what makes you think they're somehow that much more smarter than Let's Encrypt on this topic?
- eridius 11y ago
  The green padlocks are only for EV certs. Let's Encrypt doesn't do EV certs (nobody automatically issues those). There's a reason why browsers visually distinguish between EV certs and DV certs, and it's because DV certs don't indicate anything at all beyond the fact that the cert owner is able to serve HTTPS at a given domain.

by eridius 11y ago

Ao7bei3s 11y ago

Because A records don't mean complete control over domains. There is a difference between "I can serve content under this domain (currently)" and "I control this domain (and can decide where it points)". DNS domain validation is the right way to do domain validation. But it's slightly harder for users, which is why HTTP(s)- or E-Mail-based validation is being done more often.

simoncion 11y ago
> There is a difference between "I can serve content under this domain (currently)" and "I control this domain (and can decide where it points)". Agreed. However, I have a hard time believing that it's a net win to make it impossible for people who are permitted to control the machines that a DNS record points to, but are not permitted to alter that DNS record and/or anything under it [0] to get a cert from Let's Encypt. [0] Or are -perhaps- using a DNS hosting provider that doesn't let you add TXT or CNAME records. (I've used such a sorry provider in the past. :/ )
- btown 11y ago
  But consider an attacker who pivots onto your entire infrastructure to serve any content they desire. Presumably your DNS provider passwords are stored in a password manager outside of that infrastructure. The attacker would still need to use social engineering to trick the CTO into revealing those passwords. It seems that would have prevented the abuse in the OP, right?
  - simoncion 11y ago
    > But consider an attacker who pivots onto your entire infrastructure to serve any content they desire. I mean, if we're talking about a situation where an attacker controls your webserver, then that's pretty much game over, right? They can read and write to everything your server can, including SSL private keys, SQL databases, etc., etc., etc... > Presumably your DNS provider passwords are stored in a password manager outside of that infrastructure. ... It seems that would have prevented the abuse in the OP, right? Doing DNS-record-alteration-only verification would have prevented the scenario described in TFA, yeah. But, there are a couple of things to consider: * DV certs provide nothing more than HTTPS, without the scary "THE BROWSER DOESN'T RECOGNIZE THIS CERT ISSUER!!11" dialog. They don't provide the additional UI cues that EV certs do. So, their phishing utility is rather limited. * Society as a whole benefits far more from thwarting passive dragnet surveillance than it does from putting roadblocks in the way of occasional unauthorized and unwanted issuance of a DV cert to someone who has improperly (effectively) gained control of someone else's web server or DNS zone. * TFA is primarily a scare-piece from a traditional CA <strike>that's likely sad that their revenue stream from DV issuance is going to vanish.</strike> Ugh. I actually got off my ass and did some research... it seems that Trend Micro doesn't issue DV certs. [0] Mea culpa. [0] http://esupport.trendmicro.com/solution/en-US/1097653.aspx http://esupport.trendmicro.com/solution/en-US/1097653.aspx
corobo 11y ago
I can serve using HTTP on this domain should be enough to prove you can also serve HTTPS on this domain though. It's on the domain owner to avoid giving away control of their (sub)domain to a malicious party. Exactly the same as with regular HTTP and anything else that uses DNS.
- Ao7bei3s 11y ago
  It's not about proving that you can serve HTTPS, it's about proving that you can legitimately serve HTTPS. I'd find HTTP(S)-based validation ok if CAs wouldn't issue certificates with an expiration time past the expiration time of the DNS records. Of course that would be fairly impractical. But then DNS-based validation exists and doesn't have these problems.
  - eridius 11y ago
    What is the difference between serving HTTPS and "legitimately" serving HTTPS? Or to put it another way, what qualifies as "illegitimate" HTTPS?

zamalek 11y ago

Because this happened: > Website owners should ensure that they secure their own website control panels, to ensure that new subdomains beyond their control are not created without their knowledge. You're a bank and haven't secured your DNS control panel correctly. Someone comes along, and using your vulnerable DNS, registers logon.bank.com (instead of login.bank.com). Now it is the bank's fault to begin with, but end-users are going to see that green padlock and will get pwned. You can point fingers all you want at the bank but that situation could (and should) have been avoided. Let's Encrypt could be seen as a "vulnerability amplifier." With the previous PKI, even if you gained authority over logon.bank.com you wouldn't be able to get that green padlock in the title bar. There is a very good chance that someone at the CA would have made a phone call to someone at bank.com. With the current Let's Encrypt approach this scenario becomes plausible because no check is made with the parent domain to find out exactly how paranoid it is about subdomains. Nobody is blaming Let's Encrypt, but they can help.

pfg 11y ago
It's completely unclear whether what you're saying is factually correct. If the attacker controls the bank's DNS, which seems likely given that they're able to create an A record for a subdomain, they can likely also add TXT records for bank.com, which is what traditional CAs often use to verify ownership. They could probably also modify MX records to redirect confirmation emails to a server under their control. Other CAs don't have a magic solution that automatically detects malicious domains. Issuance of DV certs is completely automated at any major CA. There is no manual review unless the domain is on some kind of grey- or blacklist, and I highly doubt that they have a list of every domain used by a bank. There have been numerous counts of unauthorized certificates being issued by almost all CAs, what makes you think they're somehow that much more smarter than Let's Encrypt on this topic?
eridius 11y ago
The green padlocks are only for EV certs. Let's Encrypt doesn't do EV certs (nobody automatically issues those). There's a reason why browsers visually distinguish between EV certs and DV certs, and it's because DV certs don't indicate anything at all beyond the fact that the cert owner is able to serve HTTPS at a given domain.