dnscrypt-proxy and OpenDNS (in)security: A Matter of Time
|
Presumably, OpenDNS is using its own tech - so I would therefore like to know, as a matter of customer convenience and security, *when* the development and release schedule from OpenDNS for releasing its production DNSCrypt-Proxy daemon (or even an executable) will be made public in order that special characters can be used in OpenDNS account passwords (i.e. e.g. transmitted over HTTPS/SPDY using encryption) - broadening the character space for OpenDNS passwords, and mitigating the risk of a breach on your backhaul? Open source community development on dnscrypt-proxy is in quite a sorry state. Experience has taught us we need the entire UTF-8 character space available for passwords as an elemental aspect of security. Without this, mark me - and this post - that your being compromised by a third party is, on the balance of probabilities, simply a matter of time. Note: as at time of posting, Google is far from completing their inter-datacenter encryption infrastructure. I am aware you've basically got 1, maybe 2, people working on dnscrypt-proxy - I humbly suggest you consider re-allocating HR to focus much more and with considerable urgency on DNScrypt Proxy. N.B.: Can you please make a note on my account to keep me advised of internal progress (not merely Github) on DNSCrypt-Proxy - in return I shall offer, if you'd like, to test your dev work periodically. Take care and thanks once again. |
-
It seems you mix everything up.
"I would therefore like to know, as a matter of customer convenience and security, *when* the development and release schedule from OpenDNS for releasing its production DNSCrypt-Proxy daemon ..."
DNSCrypt is not an OpenDNS product, but supported by several DNS services. The related client side and server side programs are available at http://dnscrypt.org/
OpenDNS is just one service supporting this DNS encryption protocol. The development of this is basically finished, and the "daemon" is not from OpenDNS."in order that special characters can be used in OpenDNS account passwords"
DNSCrypt and passwords are related in no way, because passwords are not being used in conjunction with DNSCrypt.
So now what?
-
You seem to have missed, well, everything: I am a contributor under private contract for the inhouse development of libsodium, libcurvecp (I improve what is posted to Github), was instrumental in the cryptologic development and cryptographic debugging of NaCl, EdSA, the E551 curve augmentations and am an active participant in the further development of curveprotect.org moving it toward a production release. I have also consulted on the SQRL project and have played an integral role in both creating the first Fully Homomorphic Encryption library and demonstrating how one may securely parallelize computation in FPGA cells in series.
Open-source enthusiasts such as yourself often tend to present feeling offended when almost any attempt is made to stop playing in disparate open-source sandboxes where everyone is on their own page, proactively bucking the aggregation of development efforts on a particular technology when it is used by a major player such as OpenDNS.
The technical misunderstanding/premature-reaction: OpenDNS Update and the OpenDNS Diagnostic Tool cannot accept certain special characters in their password character space - yet when signing into either of these utilities (not to mention disclosing an appspot-generated log URL when Google's inter-datacenter encryption is far from complete) the paying OpenDNS user's security when relying on dynamic IP updates is lessened by 32 factorial orders of magnitude (if using UTF-8 for passwords) by, most unwisely, failing to facilitate almost all special ASCII characters in an account's password.
Moreover OpenDNS has made itself an even more attractive target by complicating interoperability with OpenVPN in posting its 2 NS IPs in plain view, upsetting a lot of people. Further still, with OpenDNS using its own tech, are you actually conceding that you fail to comprehend what a successful attack on OpenDNS's servers would mean for its millions of users?
I have studied much of the open code for dnscrypt-proxy implementations and frankly have come away rather discouraged, esp. at opensource fanboys' lack of cohesion and coherence: Committing to open-source can be likened to someone with great ambition to professionally succeed, starting their own charity. You're entirely reliant on the one thing you both need and loathe: Leadership.
Leadership is not commercialization or even necessarily centralization, but it can certainly straighten out a dispersed and incoherent codebase. Cryptography is a responsibility, not a bath toy. Please, avail yourself of the facts before fuming on a forum post the history of which is axiomatically unknown to you.
A more appropriate form of conduct would be to constructively get the background, evaluate the discussion and determine whether there exists a viably addressable problem in need of resolution.. Then resolve it. 32 factorial orders of magnitude weaker than it could be. Will that decide the future of OpenDNS?
-
For the kind attention of all OpenDNS Product Managers -
- Mr. Frank Denis (aka "jedisct1"), evidently an OpenDNS employee responsible for the technology I have discussed in this support entry, has expressed his having taken offence at my candour - an indispensable trait in preventive security maintenance - in a manner that is becoming defamatory. Please see attachments. This post itself - in fact the entire thread thus far - will be saved to secure PDF the moment I save this comment.
- My next step will be to get Executive Management on the phone in order to resolve Mr. Denis' unfortunate response responsibly.
- If an internal OpenDNS employee would choose to use OpenDNS equipment to make his personal frustrations social, there is an emergent basis for actionable defamation.
- For the record: Yes, Frank and world, to Mr. Denis' question; in fact I'm engaged to a crossfit fashion-fitness model and we just celebrated our one month. Also, I have assisted this nation's top defamation barristers as a paralegal and defamation attorney myself in a previous life.
- Q. Can we now bring this discussion back into a far more professional sphere within which valid contributors may appropriately participate - if that is what they wish to do?
Regards
Screen Shot 2014-02-24 at 10.06.49 pm_Redacted.pdf
Screen Shot 2014-02-24 at 10.20.43 pm.png -
You obviously missed a reference to a famous response from Bryan Cantrill to Linux kernel hacker David S Miller.
https://groups.google.com/forum/#!topic/comp.sys.sun.hardware/wCd7fHnzHjw%5B76-100-false%5D
http://en.wikipedia.org/wiki/Bryan_Cantrill
The fact that OpenDNS passwords can or cannot contain non-ASCII characters has little to do with Google datacenters or opensource software. Your post was very impressive and packed with a lot of different things, but it's pretty hard to extract what issues you are having when trying to use OpenDNS out of it.
Non-ASCII characters are accepted in OpenDNS user passwords, at least on the web site. My own password contains French accents, and I verified that it still works, including when changing the password from the dashboard.
If the bug you are describing is in the OpenDNS IP Updater, it might be due to incorrect character encoding in the app. You didn't mention if you are on OSX (Mac) or Windows (PC).
There is a known URL encoding bug in the Mac version. It for sure prevented usage of passwords with a space character in them, but maybe the same issue applies to some other characters. If you are using the updater on a Mac, try the attached file to see if it fixes your issue.
For Windows, OpenDNS has a client, but there are also (opensource, sorry) alternative ones. One is frequently being recommended here. I don't remember the same, but Rotblitz probably do. Maybe the OpenDNS Windows client has the same URL encoding issue than the Mac version.
updater.dmg -
Mr. Denis -
Having written an article about it, I'm quite aware of Bryan's response - though since so few people would be, please don't backtrack on an inappropriate comment: It's as embarrassing as it is implicit. Why delete a post you knew I would receive?
On point: Having come late to this support request, you would not have understood that "rotblitz" was responding (above) to my original comment at https://support.opendns.com/entries/26821594 (top) - which in turn was prompted by the ticket correspondence in a suppoert request initiated by me, at: https://support.opendns.com/requests/76519
I suggest you read it.
Having re-read it, in not evidently being able to include ^, &, *, ~, `, or % in an account's password, when using either the Diagnostic Tool or Updater, OpenDNS Inc. is reducing its password character space security by 64 factorial orders of magnitude.
In having these utilities run URL generation scripts on Google's App Engine (and backhaul), disclosure of the log contents located at those URLs *can*, quite easily, be retroactively decrypted once Google is compelled to handover expired keys to the N_A.
The security implications for OpenDNS Inc. of transacting a TCP request to view the contents of these URLs on its own network are dramatically amplified by its failure to parse just six special ASCII characters for the passwords used to sign into these utilities, run the tests/update stale IPs and generate an appspot URL - but OpenDNS Inc. is *not* viewing these loga on its network is it? You are connecting to Google's backhaul - the security implications for OpenDNS Inc., therefore, of Google's inter-datacenter encryption being incomplete, are both of the highest relevance and profoundly disturbing.
If you would like to pass this information on to a Support Supervisor to then go to Product Management, hopefully OpenDNS can get its ass in gear and update *both* utilities for all platforms to include these six omitted special ASCII characters.
Sydney is soon moving to 1 GB/s fiber. If Product Management hasn't gotten its act together by then (when I for one would no longer require OpenDNS for all practical intents and purposes) you will have lost one of many clued-in customers who will end their payed subscriptions also. I am just more vocal.
Regards
-
Incredibly persistent...
"Having re-read it, in not evidently being able to include ^, &, *, ~, `, or % in an account's password, when using either the Diagnostic Tool or Updater, OpenDNS Inc. is reducing its password character space security by 64 factorial orders of magnitude."
This has nothing to do with OpenDNS, but is valid for all DDNS based services in the world where updates via HTTP with basic auth are being made. You cannot use characters reserved for URL encoding in HTTP header data (like passwords, but also user IDs or hostnames or any other), generally, because they appear encoded at the destination, and you wouldn't know if they are encoded or intentionally as they look like. This is how the internet works, generally, and neither Frank Denis nor OpenDNS nor you or me are to redesign how the internet and HTTP as transport mechanism are supposed to work.
"Mr. Frank Denis (aka "jedisct1"), evidently an OpenDNS employee responsible for the technology"
He recently posted in a thread here that he's neither an employee nor a developer of OpenDNS. So what?
"Non-ASCII characters are accepted in OpenDNS user passwords, at least on the web site."
Yes, but this is HTTP data and not part of the HTTP header, therefore it is (and has to be) behaving differently. This is how it is supposed to work in the internet.
"in a suppoert request initiated by me, at: https://support.opendns.com/requests/76519 I suggest you read it."
This can be read by you and staff only, not by anybody else. I.e. he and I cannot read it.
I refrain from commenting on your other points. They are almost irrelevant and off-topic. You still mix everything unrelated up.
-
- "This has nothing to do with OpenDNS, but is valid for all DDNS based services in the world where updates via HTTP with basic auth are being made. You cannot use characters reserved for URL encoding in HTTP header data (like passwords, but also user IDs or hostnames or any other), generally, because they appear encoded at the destination, and you wouldn't know if they are encoded or intentionally as they look like. This is how the internet works, generally, and neither Frank Denis nor OpenDNS nor you or me are to redesign how the internet and HTTP as transport mechanism are supposed to work."
The characters otherwise reserved for URL encoding are already being transmitted across the existing internet's HTTP(S) protocol in (encrypted) encapsulated HTTP query header packets - on a (bulletproof) per-packet basis - using both (i) (lib)curveCP (as part of the http://curveprotect.org/ project) as the transport layer for secure VPN, & (ii) an advanced, intelligent authentication protocol known as SQRL (http://en.wikipedia.org/SQRL ~ https://sqrl.pl ~ https://grc.com/sqrl/sqrl.htm/) whose development and documentation is complete and whose coding has begun globally.
If Product Managers at OpenDNS Inc. would like to rest on their laurels rather than gaining 64 factorial orders of magnitude greater strength (actual is greater; this figure by Chris Frost (OpenDNS Customer Support disclosing 6 special ASCII characters failed within passwords with the diag & updater utilities provided by OpenDNS Inc.) then you are indeed correct: all DDNS based services in the world - with OpenDNS leading the way - will eventually honeypot their own attack vulnerability by virtue of exhibiting (i) apathy; (ii) stubbornness; (iii) complacency/stagnation; & (iv) a lack of the one quality I discussed in response to your first reaction on this support thread: Leadership.
As corporate citizens on the global internet with the largest public user-base, this is one DDNS service that must acknowledge reality and accept its responsibilities if it is to remain solvent in the long run. Time will work it all out.
If you would lie to reply "rotblitz" please consider an informed response, if only in the hope that others may accurately contribute to this discussion. As for me, your own response (directly above) would seem to embody these four qualities: You don't want change; even though it's change for the better, you seem to have an evident aversion to it.
So in a nutshell, I'm out.. Busy prepping for the future..
Regards
Please sign in to leave a comment.
Comments
7 comments