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

@selea i still hear a lot of mixed opinions about dnssec. ive considered it for a while but many people i talk to, many people i read online, they have said it's too complex and it relies on inferior crypto. please correct me if im wrong
@selea RTing to hopefully get more people involved in the discussion

@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.

@Wolf480pl @selea so in essence, protect your account and nameserver, and choose a competent registrar? no need for dnssec?

@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.

@Wolf480pl @selea to be fair, tls incidentally provides a defence against dns attacks

@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.

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

you misunderstand, im talking about the case where your isp or some other router closer to you is compromised, something that letsencrypt wouldnt see
@Wolf480pl @selea regardless, dnssec looks straightforward to offer for my domain so i'll give clients the option to authenticate responses if they wish

@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
LinuxPizza

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