81–90 of 95 posts
If TXT-records are proof enough when ownership is to be provided for TLS certs. Then, why not just put the TLS-data into the "trusted" TXT-records and skip the multi-billion-dollar-BS-CA-biz all together?
https://letsencrypt.org/2020/02/19/multi-perspective-validat...
You could also securely hash a username and password together with something like argon2ID, and then authenticate users by seeing if the base64'ed TXT record exists. No need to hit an overloaded database, just dig and you'll even have the benefits of local caching with per-record TTL's! But should you do crazy things like this? Absolutely not! DNS is notoriously prone to MITM, injection, cache poisoning, DoS, etc. DA…
> DANE and DNSSEC are horrible bodges that don't actually do anything useful or in a secure way. Adoption is extremely poor, usability is horrible, and the approach used is quite dated, but I'm not sure DANE and DNSSEC are insecure. Did you have a reference on the latter?
Earlier quoted context omitted.
clamav.net, like most domains, doesn't enable DNSSEC. Further, as designed, local resolvers don't validate DNSSEC, they just ask the recursive resolver to; a MITM between the local and the recursive can lie. So when wikipedia says DNSSEC can protect, that's the permissive can. Like things can happen. But don't rely on it.
Silly me for expecting an anti-virus company to care about security. The point remains: DNSSEC COULD make this safe to do.
Earlier quoted context omitted.
> DANE and DNSSEC are horrible bodges that don't actually do anything useful or in a secure way. Adoption is extremely poor, usability is horrible, and the approach used is quite dated, but I'm not sure DANE and DNSSEC are insecure. Did you have a reference on the latter?
https://sockpuppet.org/blog/2015/01/15/against-dnssec/ is relevant.
It's always amusing when someone discovers DNS TXT records. ClamAV has been using them to announce the latest versions for more years than I care to remember. $ dig +short -t txt current.cvd.clamav.net "0.103.8:62:26972:1689593340:1:90:49192:334" For anyone interested, Freshclam interprets this as: Latest ClamAV version: 0.103.8 Latest Main DB version: 62 Latest Daily DB version: 26972 UNIX Timestamp 1689593340 ...an…
That is... interesting that they do not even use HTTPS or any type of signature for that info. So a man in the middle could prevent updates from happening, and freshclam wouldn't even throw a warning?
And yet it "works" and as the OP mentioned for a long time. Often we get so conditioned to a security response we forget that basic security often relies upon a "simple" and inexpensive solution. Using DNS in this way is a best effort scenario that offloads work to servers designed for this purpose and for an open source project so you use what you have.
Oh, and there is a failover to https if the record is over three hours old.
Earlier quoted context omitted.
Yes and then your government controls your “trusted” connection.
Like NSA did not controlled CA:s? Or are you one of those conspiracy nuts that think NSA cracked it?
It is actually adding to my argument. The NSA and any other government entities REALLY WANT to control these certificates. However, our interaction with CAs became much more secure now because we learned and developed things like CT logs. Major browsers are removing entire CAs from their trust store if shady stuff happens ASAP. You can’t do the same with TLDs. This argument is made frequently on here, why would you even want to propose to regress into stuff like DANE…? DNS servers are such a bad trust anchor, if you could even call it a trust anchor at all.
If you want to discuss further, I ask you to stay on topic instead of name calling.
You could also securely hash a username and password together with something like argon2ID, and then authenticate users by seeing if the base64'ed TXT record exists. No need to hit an overloaded database, just dig and you'll even have the benefits of local caching with per-record TTL's! But should you do crazy things like this? Absolutely not! DNS is notoriously prone to MITM, injection, cache poisoning, DoS, etc. DA…
As a side note, anything security related exists in the reality of uncertainty. It is expected that sharing properly secured secrets is reasonably safe, but day after day we discover "we didn't know". Sometimes simplicity for a particular application is worth certain amount of risk.
Sometimes, you need to take the server out of its box, out of the bunker, and plug it to both the power distribution network, and of course... a LAN...
For quick reference: - https://en.m.wikipedia.org/wiki/Hesiod_(name_service) - https://jpmens.net/2012/06/28/hesiod-a-lightweight-directory...
Earlier quoted context omitted.
> the current fleet of IT workers don’t really grok anything beyond A and PTR. Part of this, though is also who is "in control" of the server. Most of the times, DNS is on the other side of the bastion, managed by Network Ops, and out of reach of Joe Developer. Perhaps a reasonable situation, fat finger DNS and Bad Things can happen. However, Joe Developer has carte blanche access to things like HTTP servers and with…
Yep. I was speaking from a netops/sysadmin standpoint. My belief is that TXT and HINFO saw declining use within an org as Microsoft Windows DNS Server usage grew[1][2][3]. 1. Windows DNS Server hides those records behind a sub-menu item. 2. Windows DNS Server attracted noobs (a good thing, I suppose). Heck, these days, we give low/middle-tier IT workers DNS server access (via DnsAdmins group), which is crazy in my mi…
Takes me back to rendering zone files using perl. The times they have changed.
Earlier quoted context omitted.
well, that would be the fault of clamav if they did not do the proper DNSSEC verification and validation of their ‘current.cvd.clamav.net’ hostname. Digging into the code of freshclam, source of libfreshclam.c, dnsquery() function call, it is painfully evident that freshclam daemon does not do basic DNSSEC when performing res_query(). Instead, freshclam should be calling `val_res_query()`. They are currently using ‘r…
Yep, it's another "security" solution that is dead on arrival