Follow

Reminder for instance admins 

Reminder for instance admins 

Reminder for instance admins 

@selea @tursiops

Ask Gargron to add this in His Docs maybe that can increase its usage

@wowaname @selea
Judging by [1], there are a lot of good ciphersuites supported. That default SHA1 is kinda a shame though. I wonder how well the newer ciphersuites are supported by implementations, and how widely they're deployed.

But the good thing about DNSSEC (unlike CAs) is that you only need the path from the root to your domain to be secure, it doesn't matter if some random TLD that you don't use has weak keys or accidentally posts their private key on FB.

[1]: en.wikipedia.org/wiki/Domain_N

@wowaname @selea

Hm...
The ICANN article OP linked points to [krebs] which describes the attack in a vague way. It claims DNSSEC would've helped, but it didn't seem consistent with the described method of attack.
So I checked [fireeye] which Krebs linked to, and AFAIK DNSSEC wouldn't prevent the attacks described there.

[krebs]: krebsonsecurity.com/2019/02/a-
[fireeye]: fireeye.com/blog/threat-resear

@wowaname @selea

Both techniques rely on the attacker having access to your domain registrar's admin panel, and changing the records the same way a legitimate user would do.

The first one is about changing an A record. If the domain has DNSSEC enabled, the registrar will sign the new A record the same way it signed the old one , and any validating clients will think it's a legit record.

@wowaname @selea

The second technique is about changing the NS record, so that the zone is delegated to the attacker's server instead of the victim's server. But if you can change NS, you can also change DS, which holds the DNSSEC public key used to verify the delegated zone.

So you can put your own key in the DS record, and sign the zone with your own key, and everyone will think it's legit.

@wowaname @selea

To sum up: if the attackers can log in as you to your registrar's admin panel, or pwns your registrar, or pwns the registry, then it's already too late.

@wowaname @selea
at least against this attack.

DNSSEC can protect you against downstream DNS hijacking, eg. by an evil ISP, a pwned smart TV doing ARP spoofing, a random raspi sneaked into your network closet, or any other case where the attacker is between you and the authoritative domain server.

Saying "no need for DNSSEC" here is like saying "no need for HTTPS because they can pwn your webserver".

@wowaname @selea

I'm actually curious how those attackers got access to the registrar in the first place.

@wowaname @selea
Unless they get a cert from letsencrypt (which they did in this case)....

But then, accessing your registrar panel through TLS protects the password to log in to that panel, and attackers not having that password prevents the dns attack from happening in the first place... unless they had other ways.

Like, I'm really curious how the attackers got that access in the DNSpionage incident.

@wowaname @selea oh, yeah, indeed.

OTOH, I was hoping DNSSEC could help fix the multiple-SPOF problem of CAs. We can use TLSA records to publish TLS fingerprints in DNSSEC.

Then you can check a TLS cert's validity through CAs, or through DNSSEC, or both.

Reminder for instance admins 

Reminder for instance admins 

Reminder for instance admins 

Reminder for instance admins 

Sign in to participate in the conversation
Linux.Pizza

A instance dedicated - but not limited - to people with an interest in the GNU+Linux ecosystem and/or general tech. Sysadmins to enthusiasts, creators to movielovers - welcome