SoylentNews is people
SoylentNews
Arthur T Knackerbracket has found the following story:
The world's top eight DNS providers now control 59 per cent of name resolution for the biggest Websites - and that puts the Web at risk, according to a group of Harvard University researchers.
The group was led by Harvard's Shane Greenstein, and warned that since 2011, the "entropy" of the DNS (referring to how widely distributed it is) has fallen, becoming concentrated in "a small number of dominant cloud services companies".
That state of affairs, the group's research paper (PDF) argued, creates fragility if attackers find a weakness in those DNS services.
[...] For the namespaces they measured, the team found the top eight providers grew their market share from 24 per cent to 59 per cent from 2011 to 2017, and the top four went from 17 per cent to nearly 50 per cent.
[...] The other trend they found was that unsurprisingly, in a world awash with easy-to-use cloud services, external DNS hosting has overtaken in-house DNS servers.
For companies worried that this might leave them open to a Mirai-style botnet taking out their DNS provider, the solution is simple, the paper said.
Organisations should diversify their pool of nameservers by taking DNS management services from multiple providers, the paper said. Compared to the costs of a day's downtime, this is " a comparatively costless and therefore puzzlingly rare decision".
(Score: 3, Interesting) by darkfeline on Sunday March 04 2018, @12:50AM (7 children)
>Encryption is largely at the mercy of incompetent or malicious certificate "authorities".
Oh look, someone who doesn't understand SSL or the issue of trust.
I can generate an SSL certificate myself and start encrypting traffic. Clearly, encryption is not at the mercy of anyone, largely or otherwise.
The great thing about trust is that there's no way to guarantee it. At the end of the day, you must trust someone, whether that be multiple individuals through a web of trust, or a regulated organization made up of multiple individual and policies through an authority model. You can trust a person because you trust someone else says they trust the person, who you trust because someone else says they trust the person, and so on, but ultimately there has to be an entity that you blindly trust.
The only alternative to CAs is a web of trust. History has shown that webs of trust aren't practical. I wouldn't trust the average person to securely store their private key and vet other public keys correctly anyway.
Join the SDF Public Access UNIX System today!
(Score: 2) by maxwell demon on Sunday March 04 2018, @06:32AM (4 children)
What about DANE? No CA, No web of trust. All a certificate can do anyway is to ensure that the server you're talking to is the server you think you are talking to.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by NotSanguine on Sunday March 04 2018, @06:51AM (3 children)
Incorrect. DANE [wikipedia.org] is about authentication/non-repudiation [wikipedia.org]. Encryption [wikipedia.org] is another animal entirely.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 2) by maxwell demon on Sunday March 04 2018, @09:41AM (2 children)
And CAs are about what again? Yeah, that's right: Authentication (certifying that the site is really the one you think of). The CA does not encrypt for you, nor is the CA's root certificate used for encryption.
With DANE you can safely use a self-signed certificate for encryption, since you know that it indeed comes from the site you are intending to visit.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by NotSanguine on Sunday March 04 2018, @12:07PM
As far as DANE usage is concerned, you're partially correct. But there are risks and caveats with DANE as well, as I discuss below.
My original point was that in many (most?) use cases, you can do secure encryption without DANE, a CA or a web of trust, as client/server authentication isn't needed.
And in many cases where authentication/non-repudiation *is* needed (corporate webmail, SSL VPN, 802.1x, etc.), you'll need to issue certs to both the server *and* the clients. At which point, it won't matter whether you use DANE or not, as the certs will be signed by a CA certificate (itself signed by a CA cert that you control) trusted by both.
I'd also point out that DNSSEC (which is required for DANE) requires a "chain of trust" up to the TLD through your registrar (assuming the devices are on uncontrolled networks), so it's not just a matter of "let's set up DANE and Bob's your uncle!"
Do you trust your registrar's PKI policies/security? I suppose that if you start your own registrar, then you might be able to assure that the chain of trust is valid. If not, you're at the mercy of your registrar's policies and infrastructure, as well as their employees' honesty and ethics.
DANE is useful with connections to servers that aren't within your control, where you are transmitting sensitive information (financial or medical data, etc.) for which there's no single entity that controls the certificates of the client *and* the server. Even then you're still dependent on the quality/security of the server's registrar (back to the DNSSEC "chain of trust").
I don't know about you, but I'd be a little leery if I connected to my bank and they had a self-signed certificate, even if it was verified with DANE RRs, as that's pretty unusual, and things that are unusual are suspicious.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 2) by darkfeline on Monday March 05 2018, @05:46PM
Without DANE you can use a self-signed cert for encryption.
You guys seem to be confusing encryption with authentication and trust. I can encrypt a file with symmetric encryption using a known password and it's still encryption, you know.
Join the SDF Public Access UNIX System today!
(Score: 2) by FatPhil on Sunday March 04 2018, @02:45PM (1 child)
> Oh look, someone who doesn't understand SSL or the issue of trust.
> I can generate an SSL certificate myself and start encrypting traffic.
Oh, look, someone who doesn't understand SSL or the issue of trust.
You can generate your own SSL certificate, and it's indistinguishable from a SSL certificate generated by a malicious third party, as nobody knows the difference between you and Malory. And don't attempt any inane "but muh public key" response, as if you can't understand that you have a bootstrapping problem, you're more ill-equipt to take part in this discussion than you'd care to admit.
The trust the traditional, and rightly maligned, CA's provide is that of "I can connect that identity to a bank account, or other payment mechanism, but I'm not going to let anyone know what that connection is, without a warrant". Which is pretty damn useless. But less useless than nothing.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by darkfeline on Monday March 05 2018, @05:44PM
>You can generate your own SSL certificate, and it's indistinguishable from a SSL certificate generated by a malicious third party, as nobody knows the difference between you and Malory.
So how exactly is encryption at the mercy of CAs? Not only can you or me do it, but a malicious third party can do it too. That sounds like the opposite of encryption being at the mercy of CAs to me.
Join the SDF Public Access UNIX System today!