Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Wednesday September 13, @12:06PM   Printer-friendly
from the oh-did-that-start-today? dept.

Submitted via IRC for SoyCow1937

One day after the CAA (Certificate Authority Authorization) standard became obligatory on September 8, a German security researcher caught Comodo breaking the rules and issuing an SSL certificate it was not supposed to issue.

CAA allows website owners to specify what Certificate Authorities (CAs) are allowed to issue certificates in their name. Site owners can set up a CAA rule for their domain by adding a text field in DNS entries such as the one below:

bleepingcomputer.com. CAA 0 issue "symantec.com"

This small rule tells any Certificate Authority that only Symantec can issue SSL certificates for the BleepingComputer.com domain.

According to the rules of the CAA standard approved by the CA/Browser Forum in Ballot 187, this April, Certificate Authorities such as Comodo have to check a CAA field in DNS records before issuing new SSL certificates.

On Monday, German security researcher Hanno Böck shared with the infosec community that he managed to obtain an SSL certificate from Comodo — now revoked — for his own website, even if the CAA field limited SSL issuance only to Let's Encrypt.

Source: https://www.bleepingcomputer.com/news/security/comodo-caught-breaking-new-caa-standard-one-day-after-it-went-into-effect/


Original Submission

Display Options Threshold/Breakthrough

Reply to Article

Mark All as Read

Mark All as Unread

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 0) by Anonymous Coward on Wednesday September 13, @12:17PM (2 children)

    by Anonymous Coward on Wednesday September 13, @12:17PM (#567190)

    bleepingcomputer.com. CAA 0 issue "symantec.com"

    So only "symantec.com" is allowed to issue the certs... but what defines "symantec.com"? Is there a lookup table of all "CA"-strings with the actual signatures of each cert they use for signing the issued cert?

    • (Score: 0) by Anonymous Coward on Wednesday September 13, @12:32PM

      by Anonymous Coward on Wednesday September 13, @12:32PM (#567193)

      So only "symantec.com" is allowed to issue the certs... but what defines "symantec.com"?

      The very same DNS server that also served this line.

    • (Score: 3, Interesting) by rigrig on Wednesday September 13, @12:51PM

      by rigrig (5129) Subscriber Badge <soylentnews@tubul.net> on Wednesday September 13, @12:51PM (#567198) Homepage

      Is there a lookup table of all "CA"-strings with the actual signatures of each cert they use for signing the issued cert?

      No, this is not meant to be checked by website visitors, only by the CA when issuing a new certificate.
      Those will have a page telling you what to put there. Like this one by Comodo [comodo.com], which tells you to put in comodoca.com to have them issue certificates for your domain.
      And also claims that

      Comodo, however, has been supporting this on ALL certificates for the last 12+ months.

      This is not so much for security, but meant to prevent "unintended certificate mis-issue" (although I suppose you can block all CAs and only lift the block for a bit when renewing)

      --
      No one remembers the singer.
  • (Score: 0) by Anonymous Coward on Wednesday September 13, @12:37PM (2 children)

    by Anonymous Coward on Wednesday September 13, @12:37PM (#567194)

    It took Comodo a whole day to ignore the standard? Gee, these guys are really slacking if it took them a whole 24 hours to start breaking the rules in ways that will make them more money.

    They need to hire Travis Kalanick like yesterday! He'll straighten those guys out right quick!

    • (Score: 1, Informative) by Anonymous Coward on Wednesday September 13, @05:02PM (1 child)

      by Anonymous Coward on Wednesday September 13, @05:02PM (#567288)

      Actually it took 24 hours for somebody to notice what the Com[o/e]d[o/i]ans were up to.

      • (Score: 0) by Anonymous Coward on Wednesday September 13, @08:46PM

        by Anonymous Coward on Wednesday September 13, @08:46PM (#567451)

        I guess the old sarcasm detector is on the fritz again? More's the pity.

  • (Score: 2, Informative) by Anonymous Coward on Wednesday September 13, @01:48PM (11 children)

    by Anonymous Coward on Wednesday September 13, @01:48PM (#567220)

    Am I reading this right? That this standard simply defines a way to tell fraudulent certificate authorities "don't issue a fraudulent certificate for my domain"?

    There is not even a single check in the browser or SSL library to reject such a fraudulent certificate?

    If so, this standard should have been filed in the same pile as the evil bit and the coffee pot internet protocol.

    • (Score: 1, Funny) by Anonymous Coward on Wednesday September 13, @02:02PM (2 children)

      by Anonymous Coward on Wednesday September 13, @02:02PM (#567224)

      > the coffee pot internet protocol

      That's been renamed to IoT.

      • (Score: 1, Funny) by Anonymous Coward on Wednesday September 13, @02:25PM (1 child)

        by Anonymous Coward on Wednesday September 13, @02:25PM (#567231)

        I'm so happy with my decision to switch exclusively to IP over Carrier pigeon all those years ago, I don't have any of these problems

        • (Score: 0) by Anonymous Coward on Thursday September 14, @08:28AM

          by Anonymous Coward on Thursday September 14, @08:28AM (#567697)

          Don't blast the carrier pigeon internet protocol. Oh sure, the ping times a crap, but the bandwidth is actually pretty good.

          (At least as long as you use the newest "micro-SD" extension).

    • (Score: 2) by Wootery on Wednesday September 13, @02:20PM (1 child)

      by Wootery (2341) on Wednesday September 13, @02:20PM (#567228)

      My reading of it is that the check is to prevent issuance of another cert beyond the one already in place. It doesn't bypass the usual checks for fraudulence.

      • (Score: 0) by Anonymous Coward on Thursday September 14, @08:32AM

        by Anonymous Coward on Thursday September 14, @08:32AM (#567698)

        It doesn't bypass the usual checks for fraudulence.

        Of course not, the problem with the whole CA system is that there are no checks. Any fraudulent CA can issue fraudulent certificates for any domain.

        This thing appears to be an attempt to limit this, but with nothing actually checking it, we are still at zero checks.

    • (Score: 1, Interesting) by Anonymous Coward on Wednesday September 13, @02:29PM (2 children)

      by Anonymous Coward on Wednesday September 13, @02:29PM (#567232)

      It's pretty weak sauce. It's supposed to make the domain validation (DV) system a bit more robust, to make it a little bit more difficult for an attacker to get bogus DV certs issued from legitimate authorities. This whole system is just an agreement between the CAs, with no impact on domain owners unless you decide to create CAA records.

      The problem is that DNS is totally insecure anyway so DV is kind of a joke to begin with. And if an attacker can spoof A or AAAA records they can spoof the CAA records too.

      • (Score: 3, Informative) by NCommander on Wednesday September 13, @03:06PM

        by NCommander (2) Subscriber Badge <mcasadevall@soylentnews.org> on Wednesday September 13, @03:06PM (#567241) Homepage Journal

        Not disagreeing with DNS security is a joke unless you're DNSSEC signed.

        We are here at soylentnews.org (and at sylnt.us), and we publish CAA records, but I have no solid belief that they're really going to stop a misissue. The only things that can protect us from a misissue is HPKP which for various reasons we've been hestistant to deploy, or CT-transparency+OSCP-Must-Staple.

        --
        Still always moving
      • (Score: 2) by Pino P on Wednesday September 13, @03:45PM

        by Pino P (4721) on Wednesday September 13, @03:45PM (#567256) Journal

        The problem is that DNS is totally insecure anyway so DV is kind of a joke to begin with.

        DNSSEC was supposed to solve this by adding a chain of trust beginning at the root servers. DNSSEC enables DANE, a way of putting a public key in DNS that causes a browser to treat a self-signed certificate as domain-validated.

        But DNSSEC failed to gain wide support for a couple reasons. First, the root zone signing key was 1024-bit until about a year ago [verisign.com], which wasn't strong enough for browser publishers. Second, some DNS hosting providers started to charge extra for DNSSEC. GoDaddy bundles basic DNS hosting with a domain, but DNSSEC requires the "Premium DNS" upsell.

    • (Score: 0) by Anonymous Coward on Wednesday September 13, @03:00PM (2 children)

      by Anonymous Coward on Wednesday September 13, @03:00PM (#567239)

      I use RFC 7168, you insensitive clod!

      • (Score: 2) by Thexalon on Wednesday September 13, @06:43PM (1 child)

        by Thexalon (636) Subscriber Badge on Wednesday September 13, @06:43PM (#567378) Homepage

        Nah, RFC 1149 [ietf.org] and its upgrades with QoS (RFC 2549 [ietf.org]) and IPv6 (RFC 6214 [ietf.org]) are better options. Very high bandwidth if you use it properly.

        --
        If you act on pie in the sky, you're likely to get pie in the face.
        • (Score: 0) by Anonymous Coward on Wednesday September 13, @07:20PM

          by Anonymous Coward on Wednesday September 13, @07:20PM (#567403)

          Um, no, those RFCs do not allow high bandwidth:

          Avian carriers can provide high delay, low throughput, and low
                altitude service.

          ....
          The IP datagram is printed, on a small scroll of paper, in
                hexadecimal, with each octet separated by whitestuff and blackstuff.
                The scroll of paper is wrapped around one leg of the avian carrier.

          using something like an SD card violates RFC 1149.

(1)