Re: Proper form for a public FMS outproxy?

On 2019-07-21 08:11, Arne Babenhauserheide wrote:
> [email protected] writes:
>> On 2019-07-20 07:59, Arne Babenhauserheide wrote:
>>> [email protected] writes:
>>>> Frontends would be disposable and dime-a-dozen
>>> To get to this situations, you must make it very, very easy to host
>>> them. This might be a major endeavor (but one which would benefit
>>> Freenet a lot).
> If you want to make it dime-a-dozen, you need to make it easy to 
> install
> Freenet with FMS already setup.
Aren't Freenet and FMS already trivial to install programmatically?
> If you have actual IDs, you must provide a secure way to log in — not
> secure against the server, but secure against others users 
> impersonating
> you.

> Visibility is also based on the ID, otherwise you don’t get real spam
> defense (you’d have to rely on the site hoster to manage spam for you).
Well, doesn't the cookie mechanism I described do this? Everyone is 
anonymous, but personally I think that goes under "It's not a bug, it's 
a feature". No need for an actual login field, although you could give 
them a link that sets the cookie for them that they can use as a 
bookmark if they want.

If you need reliable names, you could implement tripcode functionality. 
For a bit more security, secure tripcodes. This also simplifies 
implementation. On the other hand, it's ugly. But then again, Worse is 
Better, and if you want your software to spread you should make it as 
simple as possible, like a virus.

https://en.wikipedia.org/wiki/Imageboard#Tripcodes

Recap: When posting, you enter a name and a secret, separated by one or 
two pound symbols. For instance, yanmaani#NDl5tlZY. Then the server 
hashes whatever is after the pound symbol(s), and replaces it by its 
(possibly truncated) hash. So an example output would be 
yanmaani#Ri2dTa5T. If using two pound symbols, a secure tripcode is 
computed, where the server appends a secret salt, which makes offline 
brute-force impossible. That has the downside of not being portable, of 
course.

Maybe you'd want to replace the pound symbol by something else, but 
that's an implementation detail.

A user who was really serious about becoming famous should either GPG 
sign their messages or download Freenet. I don't think "secure 
identities" are useful more than as a spam countermeasure, and for that 
purpose tripcodes are more than enough.

Anyway, the upside of predictable names is that you could separate the 
"announce" and "post" parts. Then posting could require for instance one 
captcha, and announcing ten. And there would be no need for the server 
to do any book-keeping.

So the workflow for a new user would be
a1) visit gateway.com/announce
a2) type in their name (optional) and tripcode
a3) solve 10 captchas
b1) visit gateway.com/board/thread
b2) make their post, type in tripcode
b3) solve 1 captcha, for rudimentary flood/tripcode bruteforce control

Steps B can be done before steps A, but a minor UX issue is users doing 
steps B and only B. There could be a warning if the server believes that 
to be the case, though.

Kind of like on this mailing list: first you solve a captcha to get your 
e-mail added to the list, and then you can post. Except for the part 
where you can't first post and then solve captchas.

Super ugly but probably decently functioning hybrid approach: posting, 
if done from a clean IP, gets a very low trust from a seed node, 
provided the IP hasn't been used in the past week or whatever. This 
would make it possible for "normal users" (e.g. casuals dropping by who 
just want to try it out) to post without much hassle, while still making 
it possible for Tor users to post. And the network could handle 
blacklisting that seed node if botnets are raising too much hell.

Of course now the implementation is much harder, since you need to pass 
the IP on to the onion service without terminating SSL. So I would 
rather not go down that route.

The network could handle blacklisting too old identities that suddenly 
resurface - an attacker stands nothing more to gain from solving 20 
captchas and getting a new identity from the service than they do from 
solving 20 captchas and getting a new identity with its own key, so I 
wouldn't imagine it that big a problem.

Another way could be for posts without well-announced identities to go 
into some kind of "pool" where you can vote on them. Or you could just 
have low standards for initial identity verification.

Probably, this can be fine-tuned on-the-fly long as you get the concept 
working. So I wouldn't bike-shed it too much.
>> What I'm curious about is how the identity generation should
>> proceed. In particular, can the WoT have multiple identities sharing
>> the same key?
> 
> No, and that wouldn’t be a good idea, since they could switch to the
> other ID if they’d manage to trick the server into using another public
> name.
But there's no issues if the server is well-coded? Or does WoT point 
blank not have the ability to deal with multiple identities sharing the 
same key?

If that's the case, could you change the public key exponent for the 
same result? That's how the custom .onion name brute-forcers do it. Then 
you don't need any persistent read-write storage, since you can just 
pick the exponent from an array of primes keyed on hash(name + secret 
salt).

Downside is of course the limited range of public key exponents, and the 
extreme complexity it brings, so I would rather not do it.

What's the limit in WoT preventing supporting multiple identities with 
different human-readable names but same keys?
> If you block open proxies, then you exclude all tor users, but you 
> don’t
> get real security, because botnets are horribly cheap.
Not block them, but have them solve captchas. In this regard, "Real 
security" is impossible, since you can likewise pay to get captchas 
solved.

How much does a botnet cost, then? A captcha costs $0.001 to solve, so 
if you pay $0.02/IP that's more or less equivalent to solving 20 
captchas.

Same goes for spam filtering - for sure it can be evaded, but it filters 
out some types of junk, and as long as it doesn't have a too high FP 
rate, it reduces the total amount of junk even if not by 100%. The more 
layers, the better, in theory.

>> Doesn't FMS already limit posting rate on the client side?
> 
> Not that I know of. It has delay of messages to provide more anonymity.
> 
Then it could be done externally: any user that posts too many messages 
too rapidly gets a poor rating.
> The server always has non-public information about the users. The
> question is just how to represent it.
Not in my approach, as far as I can see. Well, it has the secret salts, 
the exact posting times, and the tripcode secrets, but not more. Neither 
of those should be considered very secret, unlike the long-term 
linkability of a user who thought he or she was anonymous.
>> Do you reckon they would
>> blacklist the main ID's trust list, because it has too many children
>> which are rotten apples?
> Yes. It would then be the same as those public IDs (where the secret 
> key
> was published intentionally) which get blocked after abuse.
So how should this be dealt with? If the identity cost is the same as 
for the new seed nodes, would it still have this issue?

Extremely hacky solution, which I'd want your input on before even 
thinking about implementing: The page to announce nodes just passes 
captchas through to the seed nodes, without ever holding anything like a 
master seed key. Then it's not the front-end's problem anymore. It would 
also make them easier to start, since they wouldn't need to first get a 
trusted identity for bootstrapping purposes.
>> Bots which "jump the gun" would get blacklisted by the other bots
>> programmatically. Bots which censor messages would get blacklisted,
>> provided they didn't block all messages sent within a certain
>> timeframe.
> 
> You’d likely have to block them via FMS and only consider bots in the
> distributed algorithm which are not blacklisted by given moderator IDs.
That's what I'm thinking. It's easier to just use one trust list for 
everything and assume the consensus is right though, so there's no need 
to directly designate specific moderator IDs.

Each bot can tell if one has deviated from the protocol, so it wouldn't 
need to be that centralized.
>> Another question is if FCP already supports a "stripped-down mode",
>> where it doesn't expose internal material, only stuff that's on the
>> network. I know SIGAINT ran a Freenet <-> Tor proxy, do you know how
>> they did it?
> 
> There is public gateway mode, but I would not vouch for its security —
> it might have deteriorated over the past years of little usage.
What would be its vulnerabilities then? Accidentally exposing internal 
pages?

Cheers