On 23 Dec (00:03:00), Ivan Markin wrote: > 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). You are obviously right that _only_ the Tor code is not a "safe solution" but this is getting into a much broader discussion of "how really to make things safe with computers". Hardware, OSes, memory safe, etc... This will always influenced anything with do with the tor code. FYI, I won't start it here :P. Please keep in mind that our development team does take steps towards having safer code here. We use generated code for our binary parsing, we use static code analyzer, we test with ASAN, we have test network, we fuzz... I mean this is what I meant by "you have to trust us a bit" that is we do take steps to make it more then "we believe we do safe code". And there will ALWAYS be place for improvement over time. We have a project to increase the modularity of Tor which is to split functionalities into separate processes to decrease the attack surface if one is compromised for instance. Doing so takes _time_, huge amount of engineering effort and _testing_ but we'll get there someday. It can't happen overnight as Tor is not getting funding like Google can get and fire up a team of 50 engineers to pull it off. For now, we do add features for better security, for better performance but also to increase Tor adoptions. We do our very _best_ to make it safe but we never claimed that we do perfect safe code (which would be a sign that you shouldn't trust us anyway ;). And of course it is not a final solution to security. > > 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". In my opinion and experience, this is actually less safe. First of all, we have to build compile time conditionals in the code which makes *any* code base more messy, more prone to errors over time and thus less maintainable which is a very important thing to have as developers come and goes and the problem space of Tor is quite complex. Second, with an "only compiled in" feature, the amount of testing that feature will see will be MUCH less compare to anything part of the normal code base. Yes we can improve this with better testing, better CI and yadi yadi yada but ultimately those features don't only need to pass the "make check" but they need to pass the test of time being used and also living next to other subsystem in Tor. Not saying that a compiled in option prevents that but rather won't make it better. Third, having a compiled option does _not_ prevent any tor code bug to fuck it up like the initial question was. Less likely *maybe* but still. Overall, I believe that it won't make it "safer". It could maybe make the user fuck up less and hope they don't install the "single onion daemon" because somehow it's more intuitive? Currently, you have to edit _two_ distinct options in torrc file, then start/restart the daemon and get a bunch of warnings because you are running in non anymous mode which will put a pile next to your hostname file called "onion_service_non_anonymous". Cheers! David > > [*] 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
Attachment:
signature.asc
Description: PGP signature
-- 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