4 ms·
Can you please explain why DNSSEC was a bad idea in the first place? It worked perfectly fine with the old registrar.
by medguru 4y ago
Can you please explain why DNSSEC was a bad idea in the first place? It worked perfectly fine with the old registrar.
- belorn 4y agoIt like https. A lot of people in the past viewed HTTPS as a terrible idea that just broke things, and every example where someone had their website go down because of broken certificates or mixed content was proof that https as a concept was broken. Usually people brought up x.509 or revocation lists as the definitive proof that https would never be common.
- the8472 4y agoFrom a site reliability perspective HTTPS is still broken. Some 15yo OS can't access any site because it doesn't have the certificates or cipher suites. And as you mentioned we need to update certs, webservers and DNS all the time to keep up to date. We only put up with it because it protects users from from snoopers. But that means we live in an inadequate equilibrium. If we abolished mass surveillance rather than impeding it with technical measures then we wouldn't need encryption for read-only sites, we could have our cake and eat it too.
- shkkmo 4y ago> If we abolished mass surveillance then we wouldn't need encryption for read-only sites, we could have our cake and eat it too. Mass surveillance is not the only reason to have HTTPS everywhere. It protects not just from snoopers, but from MITM attacks.
- the8472 4y agoDid you notice the "read only sites" part? MITM is hardly relevant for those.
- sunaurus 4y agoYou should still protect against MITM attacks even with read-only websites - not all attacks are based on stealing user input.
- the8472 4y agoWhat's the threat model here?
- NovemberWhiskey 4y agoYour ISP inserts random javascript and pop-ups into HTTP sites to tell you that you're nearing your data cap and that you should go buy an additional-data-pack. Like Airtel used to (still does?) in India.
- sunaurus 4y agoRandom examples of MITM attacks I could do on a read-only website: * Inserting malicious JavaScript * Changing content on trusted websites in order to mislead people * Replacing downloadable application binaries with versions that contain malicious code
- the8472 4y agoMalicious JS can be served directly, e.g. via ad iframes. Injecting it into a low-stakes (read-only) site doesn't gain much, does it? Points 2 and 3 are the same, they're about integrity which could be had cheaper with content-addressing (hashes uniquely identifying the content) rather than pulling in the full TLS+CA machinery.
- pixl97 4y agoOk, you have a site with signed firmware downloads. I mean, they are signed securely right? A user messing with the stream can only send you another signed firmware the device takes, and not anything they attempt to create (unless they guess your signing key somehow). But, you make a mistake in firmware version XYZ and there is an RCE in it. So you pull it off your site and now XZZ is the latest version. Only problem is, anyone that can MITM you can serve version XYZ that the client will accept and make the machine exploitable by an RCE.
- emteycz 4y agoDo you think criminals care about the law?
- the8472 4y agoCriminals are much less likely to engage in MITM attacks, besides TLAs it's usually shady ISPs who want to inject some content (similar to surveillance that could be made illegal too, ISPs would in fact care). And criminals also have little incentive to attack read-only sites. Even if they did it might be more efficient to allocate resources to law enforcement rather than securing everything that could theoretically be attacked by criminals.
- emteycz 4y agoThey're not attacking the sites, they're attacking the users. Incentives are exactly the same with readonly sites. I'm a web programmer and I have no idea how the law enforcement could in any way help. Nor do I want them to. The idea that I have to cooperate with law enforcement to put a site online is absurd. See "Tech support scams" on YouTube to see what's being done today. We're talking about billion-dollar crime organizations.
- pixl97 4y agoAnother one for the list of attacking users.... You're updating the firmware on a server. The firmware is signed, so the attacker cannot outright put their own firmware on your system. The version you're using currently is secure, and the version you want to go to is secure, but there are versions in between that are insecure. All an attacker needs to do is modify the DNS and http stream to feed the firmware with an RCE to you, and then they can directly take over your server.
- ziddoap 4y ago>Criminals are much less likely to engage in MITM attacks Can you provide a source, or even just reasoning, to why this would be true? In my experience, MiTM is a common enough attack vector used by criminals.
- 4y ago
- TedDoesntTalk 4y agoHTTPS is indeed broken when viewing it from a site reliability perspective. Anyone who has maintained more than a handful of domains simultaneously will agree (personally I’ve managed hundreds, each with their own certificate … it’s an awful experience).
- verdverm 4y agoI've had several sites with HTTPS work for many years now with zero effort or SRE time. Let's Encrypt via certbot handles it all for me
- baisq 4y agoLucky you. I’ve had multiple problems like rate limits, cron not firing, let’s encrypt servers not being able to see challenge files because of obscure rewrite rules… it’s far from flawless
- verdverm 4y agoI don't think of it as luck, more about good devops practices and not letting tech debt creep
- middleclick 4y agoAwful in what sense though? I also maintain many domains and have not touched them in years since their initial setup, with LetsEncrypt (and the Certbot renewal timer).
- aseipp 4y agoHTTPS also guarantees integrity of the content; even for read-only sites it's important to ensure content isn't modified, code isn't injected, etc. There's an argument that a protocol which does integrity-checks only (without data encryption) might be good, that's the NONE cipher in TLS but it was removed in TLS 1.3 I believe; but it wouldn't fundamentally change the problem with 15yo operating systems lacking the software support or whatever. (More broadly though the operational overhead of software is really high these days in a lot of ways. I think that's true of anything, not just HTTPS, but there are a lot of other historical factors leading to that.) I think it's a bit of a leap to suggest that just doing things like banning mass surveillance would magically make systems more stable or make 15yo operating systems suddenly relevant on the net again. We'd probably still need a lot of the stuff we have in place already. However, I suggest we try it anyway because there's only one way to find out and oh well we won't lose anything valuable anyway.
- antihero 4y agoIt really isn’t hard now there’s letsencrypt. We’ll never live in a world where a connection between the client and server can be completely trusted. HTTPS is wonderful because it offers a guarantee that the data isn’t tampered with (except with corporate root CAs, but that is fuckery).
- toast0 4y agoLetsEncrypt removes the cost of certificates, and ACME removes the work of getting certificate issues, and decent integrations remove the work of loading new certificates and that's all great. But LE doesn't remove the compatability challenges. If you needed to ship a device today that would sit in a box for 10 years and then get online and get an update via https, that's really hard to do. TLS protocols sometimes get discouraged, and CA changes happen, etc.
- jtbayly 4y agoIt’s very sad that new SSL sites just don’t work on older computers that work just fine still. We’re not talking about complicated sites that wouldn’t work anyway without new browsers. Just basic HTML.
- warrenm 4y ago> From a site reliability perspective HTTPS is still broken. Some 15yo OS can't access any site because it doesn't have the certificates or cipher suites Sorry, but this argument doesn't hold water And this coming from someone who supports systems still running NT 4 I have fallback rules enabled on all of my domains - TLS 1.3 is preferred, but older editions will be supported if the need arises (1.2, 1.1, and 1.0 (on a single domain))
- the8472 4y agoDoesn't that enable downgrade attacks?
- warrenm 4y agoWhen you need to support older OSes, does it matter?
- neurostimulant 4y agoIf your service must meet some strict certifications (e.g. PCI DSS), simply enabling old tls/ssl protocols for backward compatibility is not an option.
- theamk 4y agoEh, except that HTTPS actually has tangible benefits, unlike DNSSEC.
- belorn 4y agoMuch of the Internet right now uses DNS as proof of authentication. Having authentication system be a plain text protocol without any integrity or validation is a recipe for abuse. Right now the work-around is to have multiple resolver spread out all over the world and query the name servers multiple times to detect malicious actors, which is a much worse solution that dnssec if you ask me. It doesn't scale well and is a hack on top of an insecure protocol in order to create a sense of security. We could return back to IPsec, or tunnel everything under https as a more modern version of IPsec, but those solutions are all disliked depending on who you ask.
- kevincox 4y agoWithout DNSSEC anyone can intercept your email. The TLS cert verified by mail is the domain pointed to by the MX record. Plus with DKIM keys store in DNS people can spoof email (if they can fool the receiver to trust their records). If you can fool DNS resolution for LetsEncrypt (pretty hard since IIRC they fetch DNS from multiple perspectives on the internet to mitigate this) you can get certificates for any hostname. There are other solutions such as MTA-STS and DNS-over-HTTP but the end-to-end validation of DNSSEC is pretty powerful.
- theamk 4y agoBasically, it is lots of extra work effort for no real security advantages. Other people wrote a lot about it, here is an example: https://sockpuppet.org/blog/2015/01/15/against-dnssec/ https://sockpuppet.org/blog/2015/01/15/against-dnssec/
- teddyh 4y agoRebuttal: https://easydns.com/blog/2015/08/06/for-dnssec/ https://easydns.com/blog/2015/08/06/for-dnssec/
- Spooky23 4y agoDNSSEC doesn’t really solve any problems that you have nor does it meaningfully prevent any security risks. It does create a lot of operational risk, as you’ve discovered. It also checks a box if you’re building a system for the US Federal .gov. tptacek has written about this at length on this site and other places.