Would someone please review this DNS proposal for secure HTTPS?
https://github.com/okTurtles/dnschain http://okturtles.com/other/dnschain_okturtles_overview.pdf http://okturtles.com/
It is new but it appears to be the most correct secure DNS solution for HTTPS security at present. Thank you.
Best regards, James Salsman
This isn't really relevant to MediaWiki, and the proposal is so ridiculous I can only assume it is some sort of joke project.
For others seeing this thread, I found all the good quotes for you:
DNSChain "stops the NSA"
.dns is a meta-TLD because unlike traditional TLDs, it is not meant to
globally resolve to a specific IP [...] you cannot register a meta-TLD because you already own them!
I think ICANN might take issue with that. (Also, a good read of RFC 3686 is necessary here.)
// hijack and record all HTTPS communications to this site function do_TLS_MITM(connection) { if ( // let's not get caught by "pinning", shall we? isPinnedSite(connection.website, connection.userAgent) // never hijack those EFF nuisances, they're annoying || isOnBlacklist(connection.ip) // hijack only 5% of connections to avoid detection || randomIntBetween(1, 100) > 5 ) { return false; } return mitm_and_store_in_database(connection); }
I'd *love* to see the implementation of "mitm_and_store_in_database".
Also, fun to note that the entire application is written in CoffeeScript.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science
On Wed, Apr 30, 2014 at 1:41 AM, James Salsman jsalsman@gmail.com wrote:
Would someone please review this DNS proposal for secure HTTPS?
https://github.com/okTurtles/dnschain http://okturtles.com/other/dnschain_okturtles_overview.pdf http://okturtles.com/
It is new but it appears to be the most correct secure DNS solution for HTTPS security at present. Thank you.
Best regards, James Salsman _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Apr 30, 2014 8:21 AM, "Tyler Romeo" tylerromeo@gmail.com wrote:
This isn't really relevant to MediaWiki, and the proposal is so ridiculous I can only assume it is some sort of joke project.
For others seeing this thread, I found all the good quotes for you:
DNSChain "stops the NSA"
.dns is a meta-TLD because unlike traditional TLDs, it is not meant to
globally resolve to a specific IP [...] you cannot register a meta-TLD because you already own them!
I think ICANN might take issue with that. (Also, a good read of RFC 3686
is
necessary here.)
// hijack and record all HTTPS communications to this site function do_TLS_MITM(connection) { if ( // let's not get caught by "pinning", shall we? isPinnedSite(connection.website, connection.userAgent) // never hijack those EFF nuisances, they're annoying || isOnBlacklist(connection.ip) // hijack only 5% of connections to avoid detection || randomIntBetween(1, 100) > 5 ) { return false; } return mitm_and_store_in_database(connection); }
I'd *love* to see the implementation of "mitm_and_store_in_database".
Also, fun to note that the entire application is written in CoffeeScript.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science
In the PDF I read this is saver than lower level languages, because it has no null pointer exceptions.
I for one would prefer not to take safety advice from this person.
--Martijn
On Wed, Apr 30, 2014 at 1:41 AM, James Salsman jsalsman@gmail.com wrote:
Would someone please review this DNS proposal for secure HTTPS?
https://github.com/okTurtles/dnschain http://okturtles.com/other/dnschain_okturtles_overview.pdf http://okturtles.com/
It is new but it appears to be the most correct secure DNS solution for HTTPS security at present. Thank you.
Best regards, James Salsman _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I'll start with their "vs. Convergence" since I was pretty enthusiastic when I read up on how it works. The okTurtles/DNSChain authors don't seem to understand how Convergence works at all (we'll it's either that or they do understand it but are maliciously misrepresenting it). They make ridiculous statements like " It depends on group consensus, but the group might not be very bright. What happens then?" lies like " It also does not provide MITM protection on first-visit" then say " all of the notary info appears to be stored locally to the computer, or even the browser. That is rather inconvenient for most users" glossing over how that's pretty much the same as how they handle what DNSChain server you trust. Likewise their " the website claims that it’s simple to use, which we have to disagree with because users are asked to manage a list of notaries." statement (besides making trusting notaries sound harder than it is) skips the part where DNSChain recommends that everyone run their own DNSChain daemon or at least maintain a reference to a public DNSChain service which is basically the same as a reference to a Convergence notary.
For a bit of reference the basic idea of Convergence they're calling "group consensus" is this: You have a list of notaries you trust. We'll call them say W, X, Y, and Z. When you visit a new website over HTTPS you get a SSL certificate from them and you need to know if you can trust it. To figure this out you talk to all your notaries and ask them if you can trust this certificate. Each of your notaries looks up the site and tells you what certificate they see. If all or most of them say they see the same certificate then it's safe. Each of these notaries would be run by different organizations in different locations, they can be in different countries under different governments, and you can include ones for different organizations you trust (you could include Mozilla and EFF if they ran notaries). The basic idea is that in order to compromise your connection the MITM compromising your connection would have to collude with or intercept all outgoing traffic for nearly all of these notaries you trust.
((You could even run notaries which instead of looking at certificates themselves used some other method – DNSSEC, Pinning, EFF's SSL Observatory – to test a certificate))j
The best explanation of Convergence is probably this video: https://www.youtube.com/watch?v=Z7Wl2FW2TcA
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
On 2014-04-29, 10:41 PM, James Salsman wrote:
Would someone please review this DNS proposal for secure HTTPS?
https://github.com/okTurtles/dnschain http://okturtles.com/other/dnschain_okturtles_overview.pdf http://okturtles.com/
It is new but it appears to be the most correct secure DNS solution for HTTPS security at present. Thank you.
Best regards, James Salsman _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
((In a separate email since my first on Convergence was long)) Now on DNSChain itself.
The authors like to put down other methods that are attempting to secure the communications to major websites we use today using .com domains, ensuring that when we want to talk to Facebook, Google, Wikimedia, Mozilla, EFF, or "that guy over in the corner who can't afford a certificate from a CA's website" we know we're talking to the website instead of having to rely on the broken CA system. So how does DNSChain secure your communication to a .com site without relying on CA certificates? Simple, it doesn't.
When visiting .bit sites using DNSChain it looks up the DNS in Namecoin using Namecoin's standard for the DNS of .bit domains, which includes the fingerprints of the site for TLS. So on https://*.bit/ you "can" get a fairly nice secure connection (assuming you're not being phished and also either running a dnschain daemon on your local mahine or running dnscrypt-proxy on your local machine and connecting to a server running dnschain you can trust 100%).
When visiting the rest of the web... Well it just proxies whatever normal public dns you tell it to, ;) which defaults to 8.8.8.8 without supporting the fallback 8.8.4.4.
Their answer to using the rest of the web is to install the okTurtles plugin into your browser and encrypt communication PGP style. This of course assumes that both you and the other party have setup an id/* for yourself in namecoin presumably through okTurtles and are both using DNSChain+okTurtles, relies on hardcoded per-site hacks to figure out who you're talking to (or has you manually enter their namecoin/okTurtles id), of course will probably bypass any WYSIWYG editor or feature the site has (otherwise the site could intercept the communication you're encrypting), and the site you're connecting to it hasn't secured isn't tricking it into selecting the wrong namecoin user. As for on the current web making sure you're sending your password to the right person, no one is intercepting your credit card details, who you're talking to isn't being tracked by anyone but the site itself, etc... well okTurtles just leaves that up to the same certificate authorities they don't trust.
Of course before we go try and setup wikipedia.bit (whoopsie, looks like someone already swiped it) we'll probably want to support a .onion domain.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
On 2014-04-29, 10:41 PM, James Salsman wrote:
Would someone please review this DNS proposal for secure HTTPS?
https://github.com/okTurtles/dnschain http://okturtles.com/other/dnschain_okturtles_overview.pdf http://okturtles.com/
It is new but it appears to be the most correct secure DNS solution for HTTPS security at present. Thank you.
Best regards, James Salsman _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org