44 ms·
I've long wished for a browser extension that did DNSSEC and DANE validation and displayed which country's CA signed the current cert. CT helps somewhat, but g
by Avamander 7y ago
I've long wished for a browser extension that did DNSSEC and DANE validation and displayed which country's CA signed the current cert.
CT helps somewhat, but given that Firefox doesn't enforce it leaves a lot of people vulnerable.
- tptacek 7y agoThat browser extension exists, or at least it used to. Of course, you run aground of the fact that nobody signs their zones (other than European domains whose registrars sign them automatically, which is, when you think about it, just theater). I don't know what you mean by "Firefox doesn't enforce [CT]". Mozilla has been instrumental in dis-trusting misissuing CAs.
- garrettr_ 7y ago> I don't know what you mean by "Firefox doesn't enforce [CT]". They mean Firefox, unlike Chrome and Safari, doesn't require proof of inclusion in a CT log for recently issued TLS certificates to be considered valid. Source: https://developer.mozilla.org/en-US/docs/Web/Security/Certificate_Transparency#Browser_Requirements https://developer.mozilla.org/en-US/docs/Web/Security/Certif....
- tialaramex 7y agoMozilla has lots of policy but Firefox has very little policy enforcement. This is important for practical reasons I explained only the other day. For example Firefox doesn't check for SCTs so if you show my Firefox an apparently brand new certificate for which there are no SCTs (because maybe it's actually bogus) it will carry on as if nothing happened. It also doesn't check validity periods. If you show Firefox a certificate from Let's Encrypt claiming notBefore 1986-03-02 and notAfter 2024-09-16 it considers that seems fine, never mind that the Web PKI didn't exist in 1986 or that nobody is allowed to issue leaf certificates that last almost 40 years - it doesn't care about that.
- alwillis 7y agoThe latest survey of 250 million zones [1] shows that 10,787,502 zones are DNSSEC signed. And that number continues to increase steadily. [1]: https://stats.dnssec-tools.org/#summary https://stats.dnssec-tools.org/#summary
- vbezhenar 7y agoWhat's the deal with DNSSec for ordinary websites? I copied some code from namecheap (my registrar) to Cloudflare (my DNS hoster) and ticked DNSSec box, and it just worked. Literally few minutes. Setting up HTTPS with letsencrypt is thousand times harder and people manage to do that. I guess that webmasters just don't care about DNSSec.
- tptacek 7y agoThey do not, nor do the security teams of the tech industry or the financial industry (the second-best security staffed industry vertical) or really any other industry, because DNSSEC is silly and doesn't do anything important. I will concede that if you centralize all your stuff on Cloudflare, it's very easy to set up. That's why Cloudflare makes it so easy to set up. Cloudflare is one of a single-digit small number of exceptions to the rule that big tech companies don't use DNSSEC; they do, of course, because it's part of the product they sell.
- deleted 7y ago[deleted]
- alwillis 7y agoIt’s more likely they are confused because of all of the conflicting opinions on the web. You’ll see people on HN who seem to have a personal vendetta against DNSSEC for reasons that only make sense to them. For example, a common argument is that DNSSEC is controlled by world governments, as if certificate authorities and domain registries are free-standing entities separate from the countries they’re based in. Many of these folks are actually misinformed, but there are quite a few who are clearly disingenuous about how DNSSEC works. Let's clear this up: DNSSEC creates a chain of trust, from the root zone (the “.” at the top of the domain hierarchy) to your zone, such as example.com. The chain is . --> com --> example.com Browsers trust hundreds of root and intermediate certificate authorities that can issue a certificate for any domain. This has happened more than a few times. The DNSSEC trust chain is far more constrained and you get to create the KSK and zone signing keys (ZSK) for your zone. Root Key Signing Key (KSK) is the public key of the key pair that’s for the root zone. The private key of this key pair is used to sign the top-level domains such as .com, .net, .org, etc. The root KSK ships with all of the DNSSEC-supporting DNS resolvers and enables them to verify the authenticity of the trust chain. It’s not clear what the paranoia is about; the public KSK is public; it’s referenced on thousands of websites and everyone involved with running the global internet knows about it. [1] If something malicious or nefarious were to happen, all registries, regional internet operators, ISPs, etc. would immediately know about it. All of the DNS resolvers that support DNSSEC have a built-in way to automatically upgrade to a new KSK when it’s released [2]. Even if you imagine the world’s governments colluding to change the key for whatever nefarious reason, DNS resolvers know not to trust any new key unless it’s been available for 30 days. (The new key would need to be signed by the old key anyway, but for the sake of arguement, lets pretend that’s not neccessary.) What those people neglect to mention is you’re not required to trust the root KSK. You can decide where your chain of trust starts if you wish, including only trusting your own zone. You can also create islands of trust, zones or domains you feel comfortable with. Anyway, you can read rational, fact-based responses to these and other DNSSEC falsehoods. [3] [1]: https://www.iana.org/domains/root https://www.iana.org/domains/root [2]: https://tools.ietf.org/html/rfc5011 https://tools.ietf.org/html/rfc5011 [3]: https://easydns.com/blog/2015/08/06/for-dnssec/ https://easydns.com/blog/2015/08/06/for-dnssec/