[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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

Well I took a look into the code, not my primary language but readable, and have some concerns and some suggestions...

# Concerns

Opening signing up to an API is a very bad idea especially if the server administrator is using keys vulnerable to "known word" attacks, below is a link to the severity and key types effected.


While sub key use may mitigate this; the whole concept of clients sending data for servers to process is fraught with danger... I will confess that I didn't read deep enough into the servers' side to inspect if the received strings where being scrubbed, nor do I have the expertise to know what that would look like in Python but I've enough knowledge to know that it's though no matter the language.

# Suggestions

- Instead of clients sending a block to be signed have them ask for a signed block and have the server make up some sudo-random string to sign.

Here's how I'd do it in bash for one off blocks of junk data

    for _count in $(seq 1 3); do echo "$(base64 /dev/urandom | td -cd 'a-zA-Z0-9' | head -c32)"; done

However, be warned against allowing clients to bombard servers with request to build random blocks because this could rob the server of needed entropy.

- Instead of the whole public key being presented consider using the "long format" key fingerprint IDs because then clients may have more choices in where to download a copy for validating the signed blob. This last suggestion does pose more risk to clients' key downloading behavior being linked like a DNS-leak but as you're targeting users already making use of Tor they should be relatively safe in downloading keys though those channels.

# 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.

Another option https://github.com/mnfst/mnfst seems to be a sweet of tools for allowing clients to posted signed data , no user accounts required. Turned the other way round and it's the clients allowing servers to post signed data to their local cached version of the web page.

These are suggested only to aid you in furthering your own project because I see that if used correctly your project could open up options for content delivery servers to become more of an option for web designers on the Tor network as well as an alternative to trying to find SSL cert exchange that's friendly to hidden services.

On October 25, 2016 3:57:50 AM PDT, arrase <arrase@xxxxxxxxx> wrote:
>I would like to explain this more in deep from the point of view of the
>final user, the one who wants to know about the identity behind a
>mirror of
>a service.
>The client has an extension installed in the browser.
>The client go into a domain for first time
>The client decided than that service is good for him and he would like
>know in the future if a mirror of the service is from the same author
>The extension notes the client about that site is running hidden
>The client accepts the data offered from the service to identify
>mirrors in
>the future , just clicking on extension icon
>Next time the client go into a service who claims to be a mirror of the
>original one the extension uses the stored info to advice the client if
>realy true or if it is scam
>2016-10-25 1:58 GMT+02:00 arrase <arrase@xxxxxxxxx>:
>> Hi list,
>> This is my first post
>> What do you think about that?, can be good or is a waste of time?
>> ""
>> - The problem:
>> Many sites at TOR network have multiple mirrors for support their
>> load.
>> When connecting to one of these mirror sites we can have the
>> question:
>> Is this the right place or is a service impersonation?
>> - My proposal:
>> The client who wants to verify if a service is fake or real can
>> the PGP key of the service and send a challenge to a port of the
>> The challenge is a simple string defined by the client and the server
>> respond with the same string with a valid GPG signature to identify
>> ""
>> Some code (work in progress):
>> https://github.com/arrase/TOR-Hidden-Service-Verification
>tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
>To unsubscribe or change other settings go to
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to