Author Topic: Mumble alert -Author of DNSChain etc. Starting up here within a few minutes !!!  (Read 4918 times)

0 Members and 1 Guest are viewing this topic.

Offline fuzzy

WhaleShares==DKP; BitShares is our Community! 
ShareBits and WhaleShares = Love :D

Offline santaclause102

  • Hero Member
  • *****
  • Posts: 2486
    • View Profile
session going on... very interesting. feel free to join!

Offline fuzzy

16 people in mumble!!  Please feel free to come on in!
WhaleShares==DKP; BitShares is our Community! 
ShareBits and WhaleShares = Love :D

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile
I am not sure when he is going to be on.  We are shooting for next Friday the 24th of October but that may change.  So if you want to show up in person, next Friday's mumble session will likely be the day, but subject to change.  Actually this will be held at 2pm eastern.  Or one hour before the previous time.  There will be no regular hangout at 3pm eastern with Dan, as that will be in the morning at 9am eastern.

https://twitter.com/taoeffect

Greg Slepak

He is working on
http://okturtles.com/ and
https://github.com/okTurtles/dnschain

DNSChain (formerly DNSNMC) makes it possible to be certain that you're communicating with who you want to communicate with, and connecting to the sites that you want to connect to, without anyone secretly listening in on your conversations in between.

What is it?
  • DNSChain replaces X.509 PKI with the blockchain
  • Simple and secure GPG key distribution
  • Free SSL certificates become possible
  • Prevents DDoS attacks
  • Certificate revocation that actually works
  • DNS-based censorship circumvention
  • MITM-proof authentication via .dns metaTLD

Ok show is starting.
I speak for myself and only myself.

Offline JoeyD

Ok I've got mumble up and running and ready to record. I'm a bit ashamed that I did not know about OkTurtles, I guess I have not been paying as much attention to namecoin as I thought I was.

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile
I speak for myself and only myself.

Offline Riverhead



The time for this interview will be 11 am PACIFIC TIME.   That is PACIFIC TIME so you do the math !

Anyone interested in serious security issues please show up.

The left coast time is the most unofficial of all unofficial times... in my view.

What necessitated such a big change... from 3:00pm eastern to 11:00 am pacific?

11am pacific is 1 hour before 3:00 pm eastern AFAIK.  Please correct me if I am wrong.  That is the timezone the guest is in and we worked the time around him since we had to push him off the previous week.  There was a lot of effort trying to find a time and this one will be it.

So 1 pm central, 11 am pacific, or 2pm in Bytemaster's timezone.  !

Cool. This is tomorrow? Can you update the OP with the 24th?

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile


The time for this interview will be 11 am PACIFIC TIME.   That is PACIFIC TIME so you do the math !

Anyone interested in serious security issues please show up.

The left coast time is the most unofficial of all unofficial times... in my view.

What necessitated such a big change... from 3:00pm eastern to 11:00 am pacific?

11am pacific is 1 hour before 3:00 pm eastern AFAIK.  Please correct me if I am wrong.  That is the timezone the guest is in and we worked the time around him since we had to push him off the previous week.  There was a lot of effort trying to find a time and this one will be it.

So 1 pm central, 11 am pacific, or 2pm in Bytemaster's timezone.  !
I speak for myself and only myself.

Offline tonyk

  • Hero Member
  • *****
  • Posts: 3308
    • View Profile


The time for this interview will be 11 am PACIFIC TIME.   That is PACIFIC TIME so you do the math !

Anyone interested in serious security issues please show up.

The left coast time is the most unofficial of all unofficial times... in my view.

What necessitated such a big change... from 3:00pm eastern to 11:00 am pacific?
Lack of arbitrage is the problem, isn't it. And this 'should' solves it.

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile


The time for this interview will be 11 am PACIFIC TIME.   That is PACIFIC TIME so you do the math !

Anyone interested in serious security issues please show up.
I speak for myself and only myself.

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile


Arhag, Taoeffect was unfortunately pushed off the show.  Bytemaster came on and had some very interesting stuff, and so the time I told Taoeffect didn't work so we are going to reschedule on taoeffect's time.  My apologies to him.

Anyone who is interested in questioning or talking to him, please respond here or pm me.  I'll send out a message to each of you when I get a time.

The upside is I think we have a good BBS coming up here with lots of new info but nothing from greg/taoeffect. :(
I speak for myself and only myself.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
So there is MITM by having the Cert Authority hacked and listening in the middle by providing a fake certificate.  With a full DNS DAC client this is not possible because the public keys etc are on the blockchain itself.

My question is how does the DNS DAC client securely feed the public key of a .p2p name into the browser AND how is the antiquated CA-based verification algorithm for TLS connections in the browser updated so that it can approve/reject TLS connections based on whether the supplied public key matches the one in the self-signed certificate provided over the TLS connection.

I get how the okTurtles javascript can securely grab the public key information from an outside process (DNSChain) with the .dns method, but what I haven't been able to figure out yet is what context this javascript is running within and whether it can manipulate the browser's TLS verification to protect the user using the browser's native green lock icon mechanism.

With a little more research I found this information related to extensions in Chrome. It seems that the javascript of the content and of the extension are properly sandboxed from one another and only communicate through the DOM, which is good. However, I don't think it matters all that much in the case of a man-in-the-middle attack of the TLS connection which okTurtles could not prevent against (or can it? I really am not sure). In such a case, I believe any plain-text typed by the user in the text boxes prior to okTurtles having the opportunity to encrypt it would be accessible through the DOM by the compromised web page javascript.

Also, regarding the website itself being hacked, although that wasn't originally part of my question, it does bring up another good point. Isn't the point of encrypting the text locally using okTurtles prior to sending it because the user doesn't want to trust the web site operator in addition to worrying about man-in-the-middle attacks? But even if man-in-the-middle attacks were solved, the web site operator could still feed malicious javascript to steal the plain-text before okTurtles can encrypt it, since the text is written in the same sandbox as the page. If the user wants real security, all plain-text would have to be written and viewed in a separate context that cannot be accessed by the web page through the DOM. Again, I don't know the specifics of how all this browser isolation works (and how it differs between the various browser vendors), but it seems to me that it would require a separate window. Maybe some iframe hacks could work as well from a back-end isolation perspective, but then I worry about the web page visually mimicking the okTurtles "secure" textboxes and tricking the user to type their data in a text box that spies on them.


Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile
Unfortunately I can't attend tomorrow's hangout, but I have a question for Greg, or really anyone else who can answer it.

I have tried to figure it out, but I still do not understand how DNSChain and/or okTurtles actually prevents man-in-the-middle attacks on the browser (or is that not its purpose?). I get how the okTurtles extension is able to verify the signed responses regarding any data in a blockchain like Namecoin or BitShares DNS, but that doesn't help protect the user from a man-in-the-middle of the web page itself. Once the web page is compromised none of the Javascript running in the same sandbox can be trusted anymore anyway.

So maybe I am not even asking the right question here, but I am trying to figure out how we will be able to securely access .p2p websites using BitShares DNS. The one thing I found that seems to have a plausible mechanism is a Firefox plugin (FreeSpeechMe, a fork of Convergence) that appears to change the way the TLS verification of the browser works (if I understood correctly, it is hard to get good detailed information on how it works). Unfortunately it doesn't appear to work in other browsers like Chrome. So, will BitShares DNS only be targeting the Firefox browser, is there some other mechanism planned to prevent man-in-the-middle attacks, or am I just totally misunderstanding this whole thing? I would appreciate any guidance on this topic from anyone. Thanks.

Let me try to clarify your question.

So there is MITM by having the Cert Authority hacked and listening in the middle by providing a fake certificate.  With a full DNS DAC client this is not possible because the public keys etc are on the blockchain itself.

Then there is when the site itself is hacked.  You are trying to figure out how DNS could prevent issues here ?  I suspect the answer is that when a site is hacked it is no longer MITM.  Someone would always be able to view the transactions at some level before they are encrypted, so DNS DAC does nothing to address this ?

This is basically the limits of my understanding (misunderstanding?)    Where do we diverge ?
I speak for myself and only myself.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
Unfortunately I can't attend tomorrow's hangout, but I have a question for Greg, or really anyone else who can answer it.

I have tried to figure it out, but I still do not understand how DNSChain and/or okTurtles actually prevents man-in-the-middle attacks on the browser (or is that not its purpose?). I get how the okTurtles extension is able to verify the signed responses regarding any data in a blockchain like Namecoin or BitShares DNS, but that doesn't help protect the user from a man-in-the-middle of the web page itself. Once the web page is compromised none of the Javascript running in the same sandbox can be trusted anymore anyway.

So maybe I am not even asking the right question here, but I am trying to figure out how we will be able to securely access .p2p websites using BitShares DNS. The one thing I found that seems to have a plausible mechanism is a Firefox plugin (FreeSpeechMe, a fork of Convergence) that appears to change the way the TLS verification of the browser works (if I understood correctly, it is hard to get good detailed information on how it works). Unfortunately it doesn't appear to work in other browsers like Chrome. So, will BitShares DNS only be targeting the Firefox browser, is there some other mechanism planned to prevent man-in-the-middle attacks, or am I just totally misunderstanding this whole thing? I would appreciate any guidance on this topic from anyone. Thanks.

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile

AFAIK Greg is going to be showing up tomorrow.  I told him if he was busy to show up laterish after Dan is more or less done.  Regardless, I'm a bit excited about this.  I should actually prep some questions. :)
I speak for myself and only myself.