SoylentNews is people
SoylentNews
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.
(Score: 0) by Anonymous Coward on Wednesday September 13 2017, @12:17PM (2 children)
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 2017, @12:32PM
The very same DNS server that also served this line.
(Score: 3, Interesting) by rigrig on Wednesday September 13 2017, @12:51PM
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
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 2017, @12:37PM (2 children)
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 2017, @05:02PM (1 child)
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 2017, @08:46PM
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 2017, @01:48PM (11 children)
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 2017, @02:02PM (2 children)
> the coffee pot internet protocol
That's been renamed to IoT.
(Score: 1, Funny) by Anonymous Coward on Wednesday September 13 2017, @02:25PM (1 child)
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 2017, @08:28AM
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 2017, @02:20PM (1 child)
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 2017, @08:32AM
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 2017, @02:29PM (2 children)
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 2017, @03:06PM
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 2017, @03:45PM
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 2017, @03:00PM (2 children)
I use RFC 7168, you insensitive clod!
(Score: 2) by Thexalon on Wednesday September 13 2017, @06:43PM (1 child)
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.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 0) by Anonymous Coward on Wednesday September 13 2017, @07:20PM
Um, no, those RFCs do not allow high bandwidth:
using something like an SD card violates RFC 1149.