4 ms·

>Let’s Encrypt only checks domains that it issues against the Google safe browsing API; in addition, they have stated that they do not believe CAs should act as

• chinathrow 11y ago
  >> in addition, they have stated that they do not believe CAs should act as a content filter. Isn't that what they exactly do when they check the safe browsing API?
• zamalek 11y ago
  There is a way to avoid this issue: Let's Encrypt should disallow subdomain registrations unless a TXT record is present for the parent domain. For example, if I wanted to get a certificate for bar.foo.example.com there would need to be a Let's Encrypt TXT record for foo.example.com. Although it's not their responsibility, they can take steps to mitigate it.
  • 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
    • 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.
  • nippoo 11y ago
    Or perhaps do it the other way around? Make a Let's Encrypt subdomain-blacklisting TXT record with which the parent domain could indicate that they don't want subdomain owners to be able to create their own SSL certificates. (Useful in the case of hosted web services, for example, where the parent already owns a wildcard certificate so there's no reason for the subdomain to create one)
    • pfg 11y ago
      This is already possible using CAA DNS records, which can be used to define which CAs should be permitted to issue certificates for a domain.
      • tremon 11y ago
        That's great. But according to https://tools.ietf.org/html/rfc6844 https://tools.ietf.org/html/rfc6844, this is quite recent, and not standardized yet. Do you have any information on which CA's already support this, or whether Let's Encrypt (intends to) support this? I'm still hoping for DANE to gain traction, though. Not necessarily as a replacement for CA's; there is value in thorough, third-party validation of certificates, but not within the current ecosystem.
        • pfg 11y ago
          Yes, Let's Encrypt does support CAA. Not sure about other CAs.
  • tracker1 11y ago
    In this case someone got a legitimate subdomain A record in DNS... your solution would not add much to the situation.
• jvdh 11y ago
  Exactly, their statement has been made in October already: https://letsencrypt.org/2015/10/29/phishing-and-malware.html https://letsencrypt.org/2015/10/29/phishing-and-malware.html That statement did not contain anything on other kinds of reports. They do have an email address for reporting certificate abuse. So far, I have not been able to find any public statements on how they will handle that.
• cm2187 11y ago
  In fact it's not more of an abuse of let's encrypt than it is an abuse of the linux, apache and openssl used to host these malicious websites. All of which are doing their job. The domain owner is the one not doing his.
• droopybuns 11y ago
  Encrypting everything has consequences. I recently had an IoT pairing issue between two devices. A normal human will not run wireshark to troubleshoot a pairing failure between two devices. I did. I was rewarded with a shitty protocol that could not be evaluated for errors and a moderated support forum that encouraged me to reboot my router. Taken to its extreme conclusion- there are important networking problems that are amplified if we encrypt all the packets. Sometimes, I feel like the EFF is composed of idealistic teenagers with limited understanding of how the world outside of their first hop works. I generally support them, but it is always at arms length.
  • sametmax 11y ago
    And buckling up your seat belt has consquences. You cannot danse the way you used to on your seat and 1 time out 1000, it actually makes the accident more violent. Still, you should use the seat belt. All the time.
  • userbinator 11y ago
    That's what MITM proxies are for... but I do agree that devices with encrypted traffic, without any means of its owner inspecting it, can be a significant threat.
  • pjc50 11y ago
    Of course, not encrypting and authenticating between the devices lets any other compromised device on your network interpose itself in that pairing and do whatever it likes with your IoT devices.