RFC: API Server "Fog of Requests"

Forum rules
Warning !
Avoid using binary softwares from untrusted users.
Prefer compiling it yourself and verify sources.
Post Reply
phelix
Posts: 1634
Joined: Thu Aug 18, 2011 6:59 am

RFC: API Server "Fog of Requests"

Post 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.
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

cassini
Posts: 336
Joined: Sun May 26, 2013 6:36 pm

Re: RFC: API Server "Fog of Requests"

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

somename
Posts: 80
Joined: Mon Sep 15, 2014 3:12 pm
os: windows

Re: RFC: API Server "Fog of Requests"

Post 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?

phelix
Posts: 1634
Joined: Thu Aug 18, 2011 6:59 am

Re: RFC: API Server "Fog of Requests"

Post 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?
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

somename
Posts: 80
Joined: Mon Sep 15, 2014 3:12 pm
os: windows

Re: RFC: API Server "Fog of Requests"

Post by somename »

phelix wrote: I don't quite follow. Are you talking about server configuration?
Yes.

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: RFC: API Server "Fog of Requests"

Post 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.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

Post Reply