Re: [tor-talk] Not comfortable with the new single-hop system merged into Tor

[Ivan Markin <twim@xxxxxxxxxx>]

David Goulet:
> On 20 Dec (23:38:43), hikki@xxxxxxxxxxxxx wrote:
>> I just think that this new single-hop system should have been reserved for a 
>> different Tor source/installation, dedicated only to non-anonymous hidden 
>> services, not merge it with the regular Tor software. And this for security.

> Now to your concern of "What if we have a bug in the code that actually makes
> all new onion service become single onion service?"
> 
> To be honest, that is the uncertainty of computers and programming that will
> probably never go away. It will _always_ be possible that something goes bad
> in the code. We have MANY other features and functionnalities in Tor that if
> they go bad, it will be worst then having your service become an onion
> service. But, this is where I guess people using Tor have to trust a bit the
> Tor Project that we did our best for the safety of our users which is the
> number *one* priority at all time for us, period.

Hmm.. Despite our trust in others and belief in ourselves we are still
humans[*] and we still do mistakes. Saying something like "we catch bugs
fast enough and we don't produce many of them, one should trust us" is
not a solution for having less exploitable in future. I'm trying my best
at writing safe code. But I do know that there are plenty of bugs out
there. I hope to have none but I should be prepared to have many.
I agree with Hikki, isolating this *really dangerous* feature seems so
reasonable. Sure, there are also some unknown bugs somewhere else in
code, but keep in mind that they're spread over the code so they likely
[1] won't result in serious damage. In case of single onion services
there are so many places in the code that if something goes wrong here
the client is just plain naked explicitly.
Yes, it may seem like bikeshedding. Yes, maybe it's just some of us who
feel uncomfortable with this. But also worth noting that most of the
option checks (including SOS code) in little-t-tor are not written in
bitflip-safe manner [2][3]. So flipping of one (!) bit in the right
place of memory makes tor useless. Not just degradation of anonymity.
Just no anonymity at all.
And I'm sure that this is not the only problem that is out there. Let's
not put everything into one basket (like e.g. OpenSSL does).

Personally I think the safest option here is to enable SOS code at
compilation time (there was a discussion long ago, so it's unlikely to
have this). Alec said that it would be complicated to manage separate
versions of this. I don't think so. If one wants to run a SOS they
should know what they're doing and thus install right packages.

Another branch would be messy and hard to catch up with "upstream".

[*] Other species/AI are also welcome.
[1] Most of them.
[2] E.g. RowHammer or plain stupid bitflips of non-ECC RAM.
[3] I'm not just complaining. I'm happy to fix this if I had more time.
--
Ivan Markin
-- 
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