Re: [tor-talk] A way to reduce service impersonation

[Michael <strangerthanbland@xxxxxxxxx>]

Arrase

No worries, I'm long winded when I've a subject sufficiently researched. Read at your leisure. Good to know we where on the same page with some of the client to server interactions.

Feature suggestions for browser plugin

Perhaps consider color coding mixed page content within the browser plugin and/or allow users to block unsigned/signed with unknown keys kinda like NoScript on Firefox

Future issues for browsers

One issue I for see on client side validating is whether the whole page is signed, source and all, or if there's mixed signed page content, or if there's content signed by some trusted keys along with data that is signed with unknown keys.

These types of pages will happen, especially for forums, and depending on the clients' plugin it may crash the browser or only validate the first signature check. If you check my projects helper scripts you'll find that I've begun to work around this last issue of only the first gpg block in a file being recognized and handled when in a list of gpg encoded blocks. Required some loops and even then it's not purity or cost effective.

Well met and sleep well.

Mirimir

It depends on the server but my dirty hack for Apache would be a vhost redirect to the keybase file system mount point,

    /keybase/public/s0ands0

...instead of...

    /var/www

...but permissions would likely need modifying to prevent client writes. Another option would be to "share" the web host files to a specific keybase account only set up to read/serve shared files. This second option is what I would try first if I couldn't figure out what ports where being used for kbfs, if those ports can be Tor'ified then I'd try serving up the shared directory as a hidden service for the web hosting keybase account and not even bother with third party web server options.

A client side verification alternative maybe supplied via a Java plugin that uses the following as a library/backend

https://github.com/guardianproject/gnupg-for-java

I'll have to check the link out in a few days, got some kennel hacking to finish and post about before crawling domains for more material. But in the interest in sharing notes here's a link to resources I've used to build my own GnuPG related project. It's designed for sysadmins that wanted "one way" encryption of their logs, hint find my postings on stackoverflow related domains for my necromancy on related questions.

https://github.com/S0AndS0/Perinoid_Pipes/blob/master/Documentation/Education_resources.md

Warnings for above linked project

- the above linked project as a whole is unrelated to the goals of this email chain but the 'Gnupg_' prefixed titled documents in the above are general enough for any projects use. You'll also want to check the '.travis-ci/' directory for easy automation tricks with GnuPG.

- it's functional and maybe used for bulk signing or decryption via one or two command line option changes. However, is only a prof of concept because it's all written in Bash scripting language.

- it maybe very insecure or very secure, no live stress tests have been completed as of yet.

- So enjoy'em but let's not derail what's happening here within the current chain topic.

On the subject of further hackery of previously mentioned tools the mnfst GitHub Repo has client, server and API options so I'd have to dig deeper into build setup to recommend it further as an alternative. However, it does look to be a tool that is complimentary to the one proposed here. So consider it as a way of "closing the loop" by allowing clients to send signed post data where as this project kinda aims the reverse. Combined and we'd have pgp signing on both sides of communication.

Stay safe y'all

On October 25, 2016 6:46:54 PM PDT, Mirimir <mirimir@xxxxxxxxxx> wrote:
>On 10/25/2016 07:17 PM, Michael wrote:
>
><SNIP>
>
>> # Alternative options
>> 
>> Have you heard of https://keybase.io yet, or their file system? 
>> I've a few invites reserved for developers so let me know if 
>> it's interesting enough to warrant testing. It maybe possible 
>> to run with all web pages being signed and verified with a 
>> little hackery to how it connects clients.
>
>That would be very cool! My blog <http://dbshmc5frbchaum2.onion/> is
>all
>GnuPG signed, and the key is at <https://keybase.io/sireliah>.
>
>So what sort of hackery would be needed? There are some GnuPG add-ons
>for Firefox etc, but I haven't found one that works. I just tell users
>to download pages, and verify manually. One issue might be that Keybase
>doesn't seem to resolve onions, so I used a tor2web link in the
>profile.
>
>Another issue is that I'm using an ancient app (pgphtml) to sign HTML.
>And I haven't found anything newer that works.
>
><SNIP>
>-- 
>tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
>To unsubscribe or change other settings go to
>https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk