3 ms·

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 th

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?

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?