Delist OpenNIC & NameCoin #1273
No reviewers
Labels
No Label
🔍🤖 Search Engines
approved
dependencies
duplicate
feedback wanted
high priority
I2P
iOS
low priority
OS
Self-contained networks
Social media
stale
streaming
todo
Tor
WIP
wontfix
XMPP
[m]
₿ cryptocurrency
ℹ️ help wanted
↔️ file sharing
⚙️ web extensions
✨ enhancement
❌ software removal
💬 discussion
🤖 Android
🐛 bug
💢 conflicting
📝 correction
🆘 critical
📧 email
🔒 file encryption
📁 file storage
🦊 Firefox
💻 hardware
🌐 hosting
🏠 housekeeping
🔐 password managers
🧰 productivity tools
🔎 research required
🌐 Social News Aggregators
🆕 software suggestion
👥 team chat
🔒 VPN
🌐 website issue
🚫 Windows
👁️ browsers
🖊️ digital notebooks
🗄️ DNS
🗨️ instant messaging (im)
🇦🇶 translations
No Milestone
No Assignees
1 Participants
No due date set.
Dependencies
No dependencies set.
Reference: privacyguides/privacytools.io#1273
Loading…
Reference in New Issue
No description provided.
Delete Branch "rm-insecure-dns"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Description
Resolves: #1258
While OpenNIC and Namecoin allow private domain registration, I am let to understand that they cannot get SSL certificates, that are globally recognised as valid, due to their nature as an alternative to ICANN managed DNS.
If I am correct, this results to them either not having https/TLS at all or teaching users to blindly accept any SSL certificates, either announcing in plaintext to any network listener (or Tor exit node) what they are doing or leaving them vulnarable to MITM attackers. Thus I don't consider them as private.
See also:
Check List
I have read and understand the contributing guidelines.
I have delisted the source code.
This project has an associated discussion.
Deploy preview for privacytools-io ready!
Built with commit
caea706a01https://deploy-preview-1273--privacytools-io.netlify.com
It appears that I am not entirely correct in case of Namecoin judging by https://wiki.namecoin.org/index.php?title=Domain_Name_Specification#TLS_support, however
I think installing root certificates is dangerous as those have leaked in the past and probably will also in the future.
LGTM
Looks ready for merging.
While this was already merged, another argument I happened to thought of against Namecoin is that I have heard them often encouraging DNS servers that are capable of resolving Namecoin domains, and I understand that in that case there wouldn't even be the root CA installed resulting to security issues.
Hi, Namecoin developer here. (I'm happy to open a new issue if you prefer; let me know.)
The statements about Namecoin in this thread are a mix of just-plain-false or highly-misleading. It's disappointing that no one reached out to me about this, as I would have been happy to answer your concerns.
Technically true in the sense that users need to install software in order for their systems to recognize Namecoin TLS certs, but this is an odd criterion given that Namecoin domain names themselves require installing software.
This is false. Namecoin encourages users to use TLS, and we don't recommend that they accept certificates that show validation errors.
I assume you're referring to things like SuperFish. The reason SuperFish's root CA "leaking" was a problem is that SuperFish used the same root CA on all users' systems. Namecoin's root CA is generated locally and is unique per installation, so this is not an issue for Namecoin.
EDIT: I should also mention that Namecoin takes great care to limit attack surface from its certificates. For example, Namecoin's TLS implementation (ncdns/certinject) doesn't require root privileges while running (it sets up a sandboxed user that only has write privileges to the root CA list, rather than running with root privs), and we have partially deployed additional safeguards such as name constraints, which prevent the Namecoin root CA from issuing any certificates outside of the
.bitTLD. We also don't use an intercepting proxy, even though that's the most commonly deployed method of changing TLS certificate validation behavior (it's what SuperFish does), because TLS intercepting proxies have more attack surface than we're comfortable with. Feel free to look at my talks at 34C3 and 35C3 if you're curious about how we limit attack surface for this.Unless you're referring to ncdns (which is a locally installed DNS server, which sets up TLS support at the same time), this is false AFAIK. In fact, I requested that OpenNIC stop resolving Namecoin domains because I don't think centralized resolution is a good idea; they complied with my request. Could you provide a citation to whatever statements you're referring to?
Thank you for your comments jeremy! If personally been wanting to contact you over this, but ive been rather swamped with my job and other stuff happening around ptio. In anycase, i highly appreciate that your here now to help out :)
(Ninja-edited my above comment to add a paragraph about how Namecoin limits attack surface regarding TLS root CA's.)
@blacklight447-ptio Good to hear. Definitely feel free to let me know if you have any questions for me about Namecoin. More generally, I would recommend at least making a cursory effort to reach out to software projects before de-listing them, in order to avoid misunderstandings such as the one in this thread.
Well generally we do that, sadly it seems we slipped a little on this one (so much stuff to do on the project these days) ill be coming up with some questions soon. I'm first handling some more pressing matters. I can at least assure you that Namecoin wont go anywhere until we had a proper conversation about it with you.
On Thu, 14 Nov 2019, 08:34 JeremyRand, notifications@github.com wrote:
I don't remember the amount of research done at that time, but how easily
could your contact details or GitHub account be found?
I am under impression that this is incorrect as so many DNS resolvers have
NameCoin support without requiring additional installation.
How is the root CA protected? Can installing a new root CA ever be safe
outside of distribution or browser trust store that should have a criteria?
I apologise if I have confused NameCoin and NameCoin community
recommendations or even people who have nothing to do it, I can surely say
that I have received feedback saying that the DNS page should include
whether the resolver includes NameCoin support or not and I am happy to
hear that you are against it.
PS. I am currently in a bad place and cannot even check GitHub and verify
that you are who you claim to be at the moment.
I have now checked your GitHub profile, NameCoin profile and NameCoin website and accept that you are who you say to be, but may I suggest you to Verifying your organization's domain on GitHub?
Sorry, I missed this before not being able to access GitHub and it not emailing edit histories to me (which may be a good thing).
I definitely will at a better time. I am having a bit too much going on at the moment, but I hope my December should stabilize, but the editorional team luckily includes more people than just me.
I guess I may be thinking of https://bit.namecoin.org/browse.html listing "Volunteer-Run DNS Servers" and while it says "For quick testing" and "Using this for everyday browsing or anything sensitive is strongly discouraged...", I fear listing it as an option may send the wrong signal ("If I am not doing anything special, I don't need to do this") and I don't know how much people using NameCoin domains or third party DNS servers perform research and if they ever hear that their favourite DNS server is not recommended.
Jumping back to the beginning
I think it would be more clear to have a new open issue about this while mentioning that there has been discussion here.
However I am not sure where in the site would NameCoin belong to especially if https://github.com/privacytoolsIO/privacytools.io/pull/1372 gets merged as it would turn it more to encrypted ICANN DNS providers (how does NameCoin handle ICANN DNS?) and thus be blocked by https://github.com/privacytoolsIO/privacytools.io/issues/1466 .
Should be pretty easy; the Namecoin.org website links to the Namecoin GitHub account on the Downloads pages. I've also recently added my OpenPGP fingerprint to the Team page, so it should be even easier going forward.
Might I ask which resolvers those would be? The main one I'm aware of was OpenNIC, and they stopped after I asked them to. FWIW, I've spent some effort trying to get IETF and/or ICANN to issue a ruling (specifically a suTLD designation, similar to what they did for
.onion) saying that public DNS resolvers shouldn't resolve Namecoin domains; alas, that effort ran into political issues and lately I've been too busy writing code to have sufficient time to pursue that.In any event, those DNS resolvers aren't affiliated with us. You might find the following articles of mine relevant:
This is a complicated question to answer, because every web browser and OS has its own API's, none of which have much resemblance to each other, so Namecoin has to do different things per browser/OS, and different API's give us more capacity to limit attack surface than others. That said, it looks like we're converging on 2 main implementations: certinject (which is used for most Windows applications that aren't Firefox) and ncp11 (which is used for Firefox and Tor Browser on all OS's as well as most other applications on GNU/Linux). So I'll cover those two here.
certinject currently installs certs into the Windows root CA list, but they're not actually CA certs. They're end-entity certs that are deterministically derived by "rehydrating" a public key, expiration period, domain name, and signature (which are collectively called a "dehydrated certificate"). The domain name is obtained based on which name the web browser looked up; the other fields are retrieved from that domain name's entry in the blockchain. The rehydration procedure doesn't give the domain owner any control of the fields that could be potentially malicious (e.g. the CA bit), so it avoids most of the attack surface of the X.509 spec. The rehydrated certs are added to the root CA list because adding an end-entity cert to the root CA list in Windows has the result of making that end-entity cert trusted for the domain name in its SAN field, without making it valid as a CA (because Windows honors the CA bit and KeyUsage field, both of which we set to disallow usage as a CA). The actual insertion of the cert into the root CA list is triggered by the DNS lookup event. Normally, inserting a root CA in Windows requires Admin rights, which is obviously attack surface that we don't want. However, in reality, the root CA list in Windows is backed by a set of registry keys, and the Windows registry supports ACL's just like the filesystem. So we run the daemon that uses certinject as a sandboxed user that has almost no privileges (substantially less than a typical user), but has write privileges to the specific registry key that contains the root CA list. That user is created at install time (naturally, the installer runs with admin privs, just like every other Windows installer).
You'll note here that this still means that the daemon has the ability to add additional root CA's that aren't Namecoin-related in the event that it somehow gets compromised. It's unlikely that it will get pwned in that way (it's written in a memory-safe language), but I'm planning to rewrite a lot of this so that the installer will instead insert a single name-constrained root CA into the root CA list (the name constraint means that the root CA can only sign certs for Namecoin domains), and save the private key for that name-constrained root CA in a location that only the certinject daemon has read access to. The certinject daemon would then run as a user that doesn't have write access to the root CA list, but instead has write access to the intermediate CA list. This means that it can sign certs with the private key it has, and tell Windows that those certs exist, but because of the name constraint, the only certs it can issue are for domains in the Namecoin TLD. So this significantly limits the amount of damage it could do, by confining the damage to within the Namecoin TLD.
Meanwhile, ncp11 uses the PKCS#11 functionality of Firefox and similar browsers to provide a parallel cert store to the one that Firefox usually ships with. Each time ncp11 launches (i.e. each time Firefox runs), ncp11 locally generates a root CA with a name constraint for the Namecoin TLD, and marks it as trusted. (The root CA cert, and its key, are not written to disk; they stay in RAM.) Then, for each .bit domain that gets accessed by Firefox, ncp11 looks up the public key for that .bit domain in the blockchain, and signs an intermediate CA with that public key and a name constraint for that specific .bit domain. The domain owner would configure their TLS server to provide a TLS cert that's signed by a CA whose public key matches the blockchain. The usage of intermediate CA's rather than end-entity certs is for 2 reasons: (1) Firefox doesn't allow PKCS#11 modules to mark end-entity certs as trusted, and (2) it makes it easier for users to periodically rotate their keys, or use multiple certs for different IP's on the same domain, without spamming the blockchain. The usage of PKCS#11 rather than writing certs to the built-in trust store provides a major privacy benefit: the certs produced by ncp11 never get written to disk, so there's no risk of browsing history getting leaked to someone who snoops through the cert database.
If you've been following so far, you'll note that the suggested improvement for sandboxing certinject also could be done for ncp11: I'm planning to modify ncp11 to not need any permission from Firefox to mark certs as trusted, and instead load the private key for the name-constrained root CA from an access-protected file; the root CA would be added to Firefox's trust list at install time, and ncp11 itself would only be able to provide intermediate certs signed by the root CA, which is only able to issue certs within the Namecoin TLD.
There are lots of details that I'm omitting here for brevity, but you can get the general idea.
Generally speaking, the main ways that software installing root CA's can go south are in 2 categories:
Namecoin uses private keys that are not shared between users, and it doesn't use an intercepting proxy of any kind. It's certainly true that the number of software products that do do one of those 2 things is alarming, but the well-deserved concerns associated with those products simply are not applicable to Namecoin.
Thanks for the tip, I'll look into it. But note that we're seriously considering ditching GitHub in favor of something open-source, so whatever effort we're willing to put into GitHub-specific infrastructure is limited unless/until we decide to stay with GitHub long-term.
I was actually not aware that that wording was still there. Thanks for pointing me to that; I'll look into getting that entire section removed, as I agree with you that users may get the wrong message from it.
I was intending to post this reply in a new issue, but I'm not sure what category it would go into. Is this a "software suggestion"? Seems like a wrong place to put it since it's not "new" software but rather a discussion about software that was already there and which might have been prematurely removed. Feel free to create a new issue in whatever category you think is appropriate; you guys are better qualified to decide what category it goes in since it's your repo.
Generally speaking, Namecoin doesn't conflict with the DNS; Namecoin has its own TLD, and nothing in the DNS tries to use that TLD. The only area in which it might arguably conflict is that Namecoin domains can delegate to DNS via NS+DS records, which generally is handled by running a recursive resolver locally. Whether the connections to the nameserver have transport encryption is a function of whether the recursive resolver supports transport encryption when contacting authoritative nameservers. AFAIK this is an area in which IETF is working on specs, but they're not particularly far along in standardization yet, and I don't know of any recursive resolvers that support this yet. Namecoin currently recommends DNSSEC-Trigger, which definitely does not support transport encryption for contacting authoritative nameservers. We are not happy about this situation, and we look forward to better recursive resolvers becoming available that handle this properly, but alas, that's the tradeoff that exists right now. Suggestions welcome. Of course, the DNS records in question are still verified via DNSSEC, so there's no risk of malicious records being accepted, it's just a lack of encryption for that DNS traffic. Hypothetically we could add an optional "privacy mode" to our authoritative DNS server implementation that disables record types that could trigger a recursive resolver to produce external traffic. I think there's been some requests for such a mode, and I probably wouldn't mind implementing it, though whether I'll actually get to it soon is a different question (too many other privacy/security enhancements that need work, so I don't get to implement everything I want to as fast as I want to).
Hope this giant wall of text is useful.
Cheers.
Thank you, I opened https://github.com/privacytoolsIO/privacytools.io/issues/1492 for tracking the relisting, I hope you find the todo list OK (I messed up at least the first one starting to list why it's a blocker and wondering different issues, but I am not sure how to start fixing it at the moment).
One concern I forgot to ask earlier is personal (and where rest of the team has voted me down, so it's not related to relisting), but being a Bitcoin fork, do you have any research on the energy usage of NameCoin or how much it results to wasted energy? Do you have any plans to become more eco-friendly? I am thinking of how Bitcoin is widely considered as problematic related to the global warming.