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.