Page 1 of 1

RFC: API Server "Fog of Requests"

Posted: Mon Aug 24, 2015 8:55 am
by phelix
For this API server I got an idea I would like to hear opinions on.

By the nature of how the API server works it could log all requests and IP addresses. To get better anonymity it is possible to use Tor. Maybe it is possible to improve anonymity particularly for normal users by hiding their actual requests among other random requests.

The server could with every answer include a handful of names that the client could than more or less randomly request.

Problem: all fog request come from the server so if it is really compromised it could serve unused names. Maybe we could simply include a large list with the client...


Just an unfinished idea I am pondering about. I am not sure whether it is worth the effort.

Re: RFC: API Server "Fog of Requests"

Posted: Mon Aug 24, 2015 1:39 pm
by cassini
phelix wrote:by hiding their actual requests among other random requests.
This looks a bit like security by obscurity which is never a good idea. In worst case it can even backfire, e.g. those random requests could yield important clues for statistical analysis attacks.

If you do want to put some effort in security-related issues then I suggest you add a system that permanently checks the integrity of the API server. This could be an external bot that periodically requests all name entries from the API server and compares the data with its own namecoind data. If it encounters inconsistencies it sends out a notification to the dev team.

Re: RFC: API Server "Fog of Requests"

Posted: Mon Aug 24, 2015 5:50 pm
by somename
cassini wrote:
phelix wrote:by hiding their actual requests among other random requests.
This looks a bit like security by obscurity which is never a good idea. In worst case it can even backfire, e.g. those random requests could yield important clues for statistical analysis attacks.

If you do want to put some effort in security-related issues then I suggest you add a system that permanently checks the integrity of the API server. This could be an external bot that periodically requests all name entries from the API server and compares the data with its own namecoind data. If it encounters inconsistencies it sends out a notification to the dev team.
If you allow one specific server to perform this checking, then the hijacked server can give correct data only to that server.
If you allow any server to perform this checking, then you may DDoS-ed that way.

If the API server runs in a container or VM, you could checksum its file(s) and periodically recheck (from the host system) to make sure none have been tampered with. This won't help if the attacker's code resides in the app's RAM.

Why not allow "loglevel=0" where 0 means none?

Re: RFC: API Server "Fog of Requests"

Posted: Wed Aug 26, 2015 9:12 am
by phelix
cassini wrote:
phelix wrote:by hiding their actual requests among other random requests.
This looks a bit like security by obscurity which is never a good idea. In worst case it can even backfire, e.g. those random requests could yield important clues for statistical analysis attacks.
True. Depending on the implementation it might be used to see if someone is still online for example.
If you do want to put some effort in security-related issues then I suggest you add a system that permanently checks the integrity of the API server. This could be an external bot that periodically requests all name entries from the API server and compares the data with its own namecoind data. If it encounters inconsistencies it sends out a notification to the dev team.
Data integrity will be "proven" by PoW (to some extent).
somename wrote: Why not allow "loglevel=0" where 0 means none?
I don't quite follow. Are you talking about server configuration?

Re: RFC: API Server "Fog of Requests"

Posted: Wed Aug 26, 2015 9:26 am
by somename
phelix wrote: I don't quite follow. Are you talking about server configuration?
Yes.

Re: RFC: API Server "Fog of Requests"

Posted: Wed Aug 26, 2015 2:37 pm
by biolizard89
cassini wrote:
phelix wrote:by hiding their actual requests among other random requests.
This looks a bit like security by obscurity which is never a good idea. In worst case it can even backfire, e.g. those random requests could yield important clues for statistical analysis attacks.
Generally agreed, people should be using Tor if they don't want to be surveilled. Generating a bunch of extra requests is usually easily foiled by statistical attacks. Note that for Tor to work properly, you need stream isolation, otherwise the server can surveil users by pseudonyms. Unfortunately, I don't actually know of any Bitcoin clients that support stream isolation fully. (Bitcoin Core uses stream isolation of different peers, but not different pseudonyms.)

FWIW, I'm still unclear on exactly what benefit this API server has over something like Electrum. Electrum is *very* lightweight, and also does PoW checks.
cassini wrote:If you do want to put some effort in security-related issues then I suggest you add a system that permanently checks the integrity of the API server. This could be an external bot that periodically requests all name entries from the API server and compares the data with its own namecoind data. If it encounters inconsistencies it sends out a notification to the dev team.
Note that if the API server were compromised, it could selectively lie only to real clients (unless the integrity check client is *very* well disguised as a real client, which is hard to do). For example, if the same IP address queries all names in order, then it's obviously the integrity check.