Re: [tor-dev] Tor path selection upon failure

[Liu, Zhuotao]

Thanks for your notes. Tim. :) 


From: tor-dev [tor-dev-boun...@lists.torproject.org] on behalf of teor 
[teor2...@gmail.com]
Sent: Tuesday, September 13, 2016 19:42
To: tor-dev@lists.torproject.org
Subject: Re: [tor-dev] Tor path selection upon failure

> On 14 Sep 2016, at 07:28, Liu, Zhuotao  wrote:
>
> Hi Folks,
>
> There have been some technical reports about how to deal with the problem 
> when a botnet uses Tor as its primary C channel. In this case, the CPU of 
> some relays is exhausted, causing circuit creation failure.
>
> I am wondering currently how a client reacts when its circuit creation fails? 
> Does the client simply resends create cells to the relays on the original 
> path or it will re-select a new path instead?

I think the Tor client selects a new path, with a new Exit, HSDir, Intro Point, 
or Rendezvous Point (within various constraints).
In the Exit case, it will try 3 different paths to 3 Exit relays that claim to 
allow exiting to the port it wants, then return a failure to the application 
that made the request.

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org






___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] "old style" hidden services after Prop224

[teor]

> On 14 Sep 2016, at 00:40, s7r  wrote:
> 
> Also, we need to move with Prop 245 (deprecate TAP handshake entirely)
> and the v2 hidden service code is the blocker for this.

As an aside, if it wasn't for v2 hidden services, we could have removed TAP 
entirely in 0.2.9.
Instead, we made ntor (the upgraded handshake) mandatory almost everywhere, 
except hidden service client intro and server rendezvous. (And we made ntor 
onion keys mandatory for relays as well.)
https://trac.torproject.org/projects/tor/ticket/19163

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org








signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Tor path selection upon failure

[teor]

> On 14 Sep 2016, at 07:28, Liu, Zhuotao  wrote:
> 
> Hi Folks,
> 
> There have been some technical reports about how to deal with the problem 
> when a botnet uses Tor as its primary C channel. In this case, the CPU of 
> some relays is exhausted, causing circuit creation failure.
> 
> I am wondering currently how a client reacts when its circuit creation fails? 
> Does the client simply resends create cells to the relays on the original 
> path or it will re-select a new path instead?

I think the Tor client selects a new path, with a new Exit, HSDir, Intro Point, 
or Rendezvous Point (within various constraints).
In the Exit case, it will try 3 different paths to 3 Exit relays that claim to 
allow exiting to the port it wants, then return a failure to the application 
that made the request.

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org








signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] [Patch] common/util_bug.h

[teor]

> On 13 Sep 2016, at 18:52, Gisle Vanem  wrote:
> 
> The 'IF_BUG_ONCE__' for non-gcc is wrong. A simple patch:
> 
> --- a/util_bug.h 2016-09-13 10:44:59
> +++ b/util_bug.h 2016-09-08 20:24:45
> @@ -117,7 +117,7 @@
> #else
> #define IF_BUG_ONCE__(cond,var) \
>   static int var = 0;   \
> -  if (PREDICT_UNLIKELY(cond)) ? \
> +  if (PREDICT_UNLIKELY(cond) ?  \
>   (var ? 1 :\
>(var=1,  \
> tor_bug_occurred_(SHORT_FILE__, __LINE__, __func__, \
> --
> --gv

Thanks for reporting this.
Logged as https://trac.torproject.org/projects/tor/ticket/20141

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org








signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] v2 to v3 onion service transition (was: "old style" hidden services after Prop224)

[Ivan Markin]

Forking this thread to discuss onion service transition path.

David Goulet:
> The question arise now. Someone running a .onion upgrades her tor that
> supports v3, should we allow v2 to continue running or transition it to v3 or
> make them both happy together...? We haven't discuss this in depth and thus we
> need to come to a decision before we end up implementating this (which is
> _soon_). I personally could think that we probably want to offer a transition
> path and thus have maybe a torrc option that controls that behavior meaning
> allowing v2 for which we enable by default at first and then a subsequent Tor
> release will disable it so the user would have to explicitely set it to
> continue running v2 .onion and then finally rip off v2 entirely in an other
> release thus offering a deprecation path.

We can add arbitrary fields into descriptors. So we can build up kinda
"aliases". What comes to mind first:

Onion Service Operator
  Publishes v2 descriptor with v3 cross-certification.
  Publishes somewhere their v3 address and cross-cert*.
v2-only client
  Uses v2 service.
v3-compatible client
  Takes v3 address from a descriptor for requested v2 address.
  Makes a connection to v3 address that looks like a connection
  to v2 for the end user. There should be no v3->v2 downgrade
  option. One-way ticket.
v3-only client
  Uses v3 service.

Also, there should not be any torrc options, I think. There is no
behavior to control so there is no need to make this transition even
more sophisticated.

* There should be a simple tool to generate and verify
cross-certifications. Like signify(1) from OpenBSD. Or even simpler.
Probably something that even built into TBB.

Don't know if such transparent connection thing is secure or not. It
seems to be as secure as v2 services.
Thoughts?

--
Ivan Markin
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] "old style" hidden services after Prop224

[Ivan Markin]

I agree with both s7r and Lunar here. Just want to add some bits:

> I disagree with your approach, for comparison's sake, let's say v2 is IPv4
> and v3 is IPv6. When IPV6 was introduced, IPv4 was kept around (and still
> is to this day, although IPv6 is arguably a much better solution in a lot
> of areas). Expecting _everyone_ to just switch to IPv6 or get cut off is a
> bit of a pipe dream.

The main goal of Tor Project is privacy and security _for everyone by
default_. If Tor is going to end up like PGP... it's a nightmare. ["Hey,
are you using new onion or old onion?", "Hm, I don't know. Maybe it's
better to go with normal Internet? At least it works.".]
If you don't care much about security/privacy/anonymity and look for a
"crypto-identified network" with NAT traversal - Tor is not _the_
network you're looking for. And yes, IPv4 is still around since it's
"just technology" and isn't tied to security. One can use outdated
technology (I do, a lot) but not use _outdated security_ ["outdated
security" hardly can be called security - a white horse is not a horse].
So ISPs can use IPv4 for any reason until the Sun become a supernova and
may not care about CGNAT and all this crazy stuff - it doesn't _threat_
anyone* except their budget.

> Tor hidden services are a bit "special" because it's hard to poll their
> owners on their intentions. Some hidden service operators have gone to
> great lengths to advertise their .onion URLs (v2-style), some have even
> generated vanity addresses (like Facebook). Forcing a switch to v3 at some
> point presents a very interesting opportunity for phishing because suddenly
> a service known and trusted at some address (as opaque as it is) would need
> to move to an even more opaque address, with no way to determine if the two
> are really related, run by the same operator, etc. If I were a LE agency, I
> would immediately grab v3 hidden services, proxy content to existing v2
> services and advertise my v3 URL everywhere, then happily monitor traffic.

It's not going to happen. You have v2 private key and your new v3
private key. Now you cross-certify them** and teach your users to use
new address.
If you've spent zillions of core-hours on generating a nice-looking
address on top of RSA1024 (can be factored now[1]) and truncated (!)
SHA-1 (someone probably can afford collisions now [2]) - congratulations.

NSA:
> Attacks always get better; they never get worse.

Also, one shouldn't rely on secret keys as you've mentioned. It
shouldn't be an apocalypse if you lost/compromised your key.

> All I'm saying is don't remove the v2 services, even if you choose to no
> longer support them. Some operators (like my company) may choose to
> continue to patch the v2 areas if required and release the patches to the
> community at large. Forcing us out altogether would make us drop Tor and
> start using an alternative network or expending the additional effort to
> make our services network-agnostic (so no more good PR for Tor).

No problem, just run your personal Tor network in your corporate
environment - Tor is free software. It's not as hard as you may think.
And you're always welcome to contribute back. Also it's good since you
may find out some edge-cases or complicated bugs that could harm The Tor
Network at some point.
Just for the record, probably a good choice for your use case here is to
stick with cjdns [3]. It provides IPv6 "cryptoaddress" and mesh
networking and other cool stuff. You don't have to have authorities and
don't have to use OnionCat. It just works. But it's different from Tor
in many ways. The major difference - it's not anonymous.


* Yes, it does break end-to-end principle and makes the Internet less
fault-resistant etc, etc. Anyway, the Internet is already broken. Deal
with it.
** It definitely needs a proposal. :) Maybe I missed one? Something like
xxx-rsa1024-rend-id-migration.txt.

[1] https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf

https://media.ccc.de/v/32c3-7288-logjam_diffie-hellman_discrete_logs_the_nsa_and_you
[2] https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html
[3] https://github.com/cjdelisle/cjdns
--
Ivan Markin
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] "old style" hidden services after Prop224

[Razvan Dragomirescu]

I fully agree with the security points, I was just arguing for keeping the
_option_ to list a v2 service for a longer time (possibly forever). Let's
not make assumptions for the service operators - ok, make them enable the
option explicitly, have them do it at compile time if you want to (like
Tor2Web) but don't remove it just because you think the alternative is
better. Some services (like mine) are not worthy targets for a LEA (unless
they're interested in hacking your fridge), Tor is interesting to us
because of its NAT traversal capabilities and cryptographic service
authentication.

Don't assume that all users have the same goals and they are all fighting
well funded or state-level attackers. Another option to be honest would be
for us to just fork Tor at the time v2 services are removed altogether and
spin a few directory authorities of our own and a few relays around the
world (we send very little traffic) and call it a day. Tor can continue
onwards with the v3-only services while our Tor fork would be happily using
v2, separate from the main network (and less subject to attacks from well
funded attackers and DDOS operators interested in revealing activists'
identities and not in finding out that you're out of cheese in your
fridge). I think there's potential in making a simpler, slightly less
secure version of Tor but with significantly improved user experience.

Oh, and no, I wasn't planning on having the Onion Balance and OnionCat devs
fix bugs for us :). I just didn't want to duplicate effort, so if they have
a plan to adapt their tools to v3, I'd rather wait for their solution than
do a half-baked one of our own.

Razvan

On Tue, Sep 13, 2016 at 10:31 PM, s7r  wrote:

>
> On 9/13/2016 6:13 PM, Razvan Dragomirescu wrote:
> > I disagree with your approach, for comparison's sake, let's say v2 is
> > IPv4 and v3 is IPv6. When IPV6 was introduced, IPv4 was kept around (and
> > still is to this day, although IPv6 is arguably a much better solution
> > in a lot of areas). Expecting _everyone_ to just switch to IPv6 or get
> > cut off is a bit of a pipe dream.
> >
>
> Your analogy with IPv4 and IPv6 is unacceptable. IPv6 exists not because
> IPv4 isn't secure, but because the address space got filled up (internet
> grew). Of course it has some improvements compared to IPv4 but we cannot
> say IPv4 has questionable security. I don't think we can speak about
> security in IP context anyway since there are other protocols where this
> happens (BGP,TCP etc.). And they do exist in parallel with perspective
> to migrate to IPv6 entirely in the future (obviously v2 and v3 hidden
> services will have a migration period also, just not so large because we
> aren't talking about the entire internet here).
>
> > Tor hidden services are a bit "special" because it's hard to poll their
> > owners on their intentions. Some hidden service operators have gone to
> > great lengths to advertise their .onion URLs (v2-style), some have even
> > generated vanity addresses (like Facebook). Forcing a switch to v3 at
> > some point presents a very interesting opportunity for phishing because
> > suddenly a service known and trusted at some address (as opaque as it
> > is) would need to move to an even more opaque address, with no way to
> > determine if the two are really related, run by the same operator, etc.
> > If I were a LE agency, I would immediately grab v3 hidden services,
> > proxy content to existing v2 services and advertise my v3 URL
> > everywhere, then happily monitor traffic.
> >
>
> I am not sure what you mean by grabbing v3 hidden services (generating
> random ed25519 keys?) and how exactly you are going to proxy anything to
> the v2 hidden service without access to v2's private key? But regardless
> of how you have in mind to do this, your points are wrong.
>
> Maintaining v2 services just because operators advertised the v2 onion
> url style is not an argument. RSA1024 will be easily factored in coming
> years. We have strong reasons to believe factoring RSA1024 at current
> moment is not impractical if the target is worth it enough. So, if we
> allow v2 services forever, we increase the chances for a LE to hijack v2
> hidden services by factoring their private keys - this risk is bigger
> than what you are describing. For the second part, there are plenty ways
> to prove a v2 hidden service is tied to a v3 one, given you control v2's
> private key. It provides exactly the same level of cryptographic
> certification.
>
> > All I'm saying is don't remove the v2 services, even if you choose to no
> > longer support them. Some operators (like my company) may choose to
> > continue to patch the v2 areas if required and release the patches to
> > the community at large. Forcing us out altogether would make us drop Tor
> > and start using an alternative network or expending the additional
> > effort to make our services network-agnostic (so no more good PR for
> Tor).
> >
>
> This doesn't sound 

Re: [tor-dev] "old style" hidden services after Prop224

[Lunar]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

s7r:
> So, my opinion is to deprecate v2 entirely after a sane and 
> reasonable transition period.  Apologies to whom this will create 
> headaches - technologically everything can be adjusted to v3 hidden
> services, it's just some work required -- it's not going to be fun
> but it's the clean way for the longer term future.

For what its worth, we now have a social contract [1] that can help us
evaluate such decisions.

In any cases, v2 onion services are broken in several aspects. I think
this is good be advertised even more (point 5, being honest about
limits). The outdated crypto primitives are not my main concerns. I
think the fact that an HSDir can learn onion service addresses, refuse
to serve them, or track connections is really bad.

Once v3 onion services are deployed, I believe the current set of
problems in v2 conflict with social contract point 6, “we will never
intentionally harm our users”. Having them continue to use a
technology that doesn't deliver its initial promises when a better
option is available feels like intentional harm to me.

YMMV, obviously, but I think this is a good framework for having a
discussion. (Should we move this to -project? Not sure.)

 [1]: https://blog.torproject.org/blog/tor-social-contract
 [2]: https://blog.torproject.org/blog/hidden-services-need-some-love
  See “Attacks by Hidden Service Directory Servers”

- -- 
Lunar 
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJX2CPzAAoJEEAsIlA9Nuk2gB8P/3SsrOeKNGG0jIB1kyED2LTu
Nf47izPICYE+ekHljlUxnmMl7QgpQGAsvzVYQ9CXoPXn09oA7TyMlyWx0DSrUf6G
cLIGoDVljnHvzAjNADtc4k2vEvT5gmIeIk19OwVepvCnjwGbYb+yDJthQRJ0Tf8V
FZtwkDAEdLwfDpJIfUrgr5quPMLij+EjCDhzfuW7nv3JrHUcEe+AQogpFYjT/roX
4Zauj+T6OvAYMKgOzmpu36uoihWF4w/N6ITdBcAjFcZQXCKVenNAUH5TIXxshheb
3rVm92MnzhbMf3vGVhJWbrWGEFS7hhcshHSVIZC4KB4T5Pm8axr9XJ5X6OriS40J
LK22xht/yEcXxhCeVO3O8rg3Tvwszw/Dtqv3/6ArTuZ4YXxnbC3HR4S60ypYbVr+
yi/0Id+Coszyu/NYOTqyTP50DNctpveqZ4zalfCPKNFnXddsvPTN5TQNFyuFG/o+
onoPOaPmAVtKOEXn1dTiAc3ys4ZGSdLFIcO9M3y7bxal0rdqb7nfTBundHEX8+5R
Ah+IE9xRkEInRDEIYWCckVZ9FWCu5ycrM17KG2fenCvdjX84EoZSFPPAN/dDrKqB
YZZFdLsR27w9N9sMcgGGNjxZ1YrEZQO40vvj7uSpqqm/mrGkw8aWroYB/v+cmv1F
5apnB6W1drX+pBOMDYd8
=9Ya/
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] "old style" hidden services after Prop224

[Razvan Dragomirescu]

I disagree with your approach, for comparison's sake, let's say v2 is IPv4
and v3 is IPv6. When IPV6 was introduced, IPv4 was kept around (and still
is to this day, although IPv6 is arguably a much better solution in a lot
of areas). Expecting _everyone_ to just switch to IPv6 or get cut off is a
bit of a pipe dream.

Tor hidden services are a bit "special" because it's hard to poll their
owners on their intentions. Some hidden service operators have gone to
great lengths to advertise their .onion URLs (v2-style), some have even
generated vanity addresses (like Facebook). Forcing a switch to v3 at some
point presents a very interesting opportunity for phishing because suddenly
a service known and trusted at some address (as opaque as it is) would need
to move to an even more opaque address, with no way to determine if the two
are really related, run by the same operator, etc. If I were a LE agency, I
would immediately grab v3 hidden services, proxy content to existing v2
services and advertise my v3 URL everywhere, then happily monitor traffic.

All I'm saying is don't remove the v2 services, even if you choose to no
longer support them. Some operators (like my company) may choose to
continue to patch the v2 areas if required and release the patches to the
community at large. Forcing us out altogether would make us drop Tor and
start using an alternative network or expending the additional effort to
make our services network-agnostic (so no more good PR for Tor).

Ivan was right, moving to v3 would be, at least for my project, extremely
complex and unwieldy. Ed25519 is not supported by any smartcards I know
(but can be "hacked" by manually defining Curve25519 params and converting
back and forth). But then we'd have to modify the service re-registration
(or wait for OnionBalance to do it), then add another layer for
OnionCat-like lookups, etc. It would be far easier to just drop the Tor
dependency at that point or centralize it a bit more.

Just my 2 cents, if any hidden service operators wish to chime in, feel
free to do so. After all, it's us (them? :) ) that will have to make the
changes to their services.

Razvan

On Tue, Sep 13, 2016 at 5:40 PM, s7r  wrote:

> On 9/13/2016 3:27 PM, David Goulet wrote:
> [SNIP]
> > Hello!
> >
> > So I 100% share Ivan's concerns. The Hidden Service subsytem of Tor is
> quite
> > complex, lots of pieces need to be glued together and prop224 will add a
> lot
> > of new code (in the 10 of thousand+).
> >
> > We decided a while back to have the two protocols living side by side at
> first
> > that is current system (v2) and next gen (v3). Relays will need to
> support v2
> > for a while after v3 is release because well not everybody updates their
> tor
> > to the latest. Lots of people have current .onion for which they need a
> > transition to the new generation which includes telling their users
> about the
> > new 52 character one and SSL certs and so on...
> >
> > The question arise now. Someone running a .onion upgrades her tor that
> > supports v3, should we allow v2 to continue running or transition it to
> v3 or
> > make them both happy together...? We haven't discuss this in depth and
> thus we
> > need to come to a decision before we end up implementating this (which is
> > _soon_). I personally could think that we probably want to offer a
> transition
> > path and thus have maybe a torrc option that controls that behavior
> meaning
> > allowing v2 for which we enable by default at first and then a
> subsequent Tor
> > release will disable it so the user would have to explicitely set it to
> > continue running v2 .onion and then finally rip off v2 entirely in an
> other
> > release thus offering a deprecation path.
> >
> > However, we are clear that every _new_ service will be v3 and never
> again v2
> > unless it already exists that is we can find a RSA private key
> (considering we
> > do the above of course). And considering both will be supported for a
> while,
> > we'll have to maintain v2 security wise but all new features will go in
> v3.
> >
> > Let's discuss it and together we can come up with a good plan! :)
> >
> > Thanks!
> > David
> >
>
> v2= old-style (RSA1024) hidden services
> v3= prop 224 (ed25519) hidden services
>
> I agree with David - it will be problematic to maintain support for both
> v2 and v3, unlimited in the future. It's clear that we need to offer a
> reasonable transition period, so everyone can upgrade and move their
> customers/user bases to the new hidden services, but this doesn't mean
> v2 should work forever.
>
> v2 hidden services already provide questionable security (from crypto
> point of view) and in the future things will only get worse for v2. I
> agree that there are a lot of third party tools working with v2 hidden
> services (OnionCat, OnionBalance) -  these all need to be improved to
> support prop 224 hidden services.
>
> Considerable resources are spent on v3 hidden services. They are better
> vs 

Re: [tor-dev] "old style" hidden services after Prop224

[s7r]

On 9/13/2016 3:27 PM, David Goulet wrote:
[SNIP]
> Hello!
> 
> So I 100% share Ivan's concerns. The Hidden Service subsytem of Tor is quite
> complex, lots of pieces need to be glued together and prop224 will add a lot
> of new code (in the 10 of thousand+).
> 
> We decided a while back to have the two protocols living side by side at first
> that is current system (v2) and next gen (v3). Relays will need to support v2
> for a while after v3 is release because well not everybody updates their tor
> to the latest. Lots of people have current .onion for which they need a
> transition to the new generation which includes telling their users about the
> new 52 character one and SSL certs and so on...
> 
> The question arise now. Someone running a .onion upgrades her tor that
> supports v3, should we allow v2 to continue running or transition it to v3 or
> make them both happy together...? We haven't discuss this in depth and thus we
> need to come to a decision before we end up implementating this (which is
> _soon_). I personally could think that we probably want to offer a transition
> path and thus have maybe a torrc option that controls that behavior meaning
> allowing v2 for which we enable by default at first and then a subsequent Tor
> release will disable it so the user would have to explicitely set it to
> continue running v2 .onion and then finally rip off v2 entirely in an other
> release thus offering a deprecation path.
> 
> However, we are clear that every _new_ service will be v3 and never again v2
> unless it already exists that is we can find a RSA private key (considering we
> do the above of course). And considering both will be supported for a while,
> we'll have to maintain v2 security wise but all new features will go in v3.
> 
> Let's discuss it and together we can come up with a good plan! :)
> 
> Thanks!
> David
> 

v2= old-style (RSA1024) hidden services
v3= prop 224 (ed25519) hidden services

I agree with David - it will be problematic to maintain support for both
v2 and v3, unlimited in the future. It's clear that we need to offer a
reasonable transition period, so everyone can upgrade and move their
customers/user bases to the new hidden services, but this doesn't mean
v2 should work forever.

v2 hidden services already provide questionable security (from crypto
point of view) and in the future things will only get worse for v2. I
agree that there are a lot of third party tools working with v2 hidden
services (OnionCat, OnionBalance) -  these all need to be improved to
support prop 224 hidden services.

Considerable resources are spent on v3 hidden services. They are better
vs v2 from all points of view, I don't think keeping the v2 code and
therefor allowing additional attack surface + creating the task to
maintain this old code (v2) in future releases is worth it. This is how
things work in software, if something gets upgraded everything upper
layer should upgrade as well. Keeping parallel older versions to allow a
feature of non-mandatory upgrades is not solid reason for us to do it.

Also, we need to move with Prop 245 (deprecate TAP handshake entirely)
and the v2 hidden service code is the blocker for this.

So, my opinion is to deprecate v2 entirely after a sane and reasonable
transition period.  Apologies to whom this will create headaches -
technologically everything can be adjusted to v3 hidden services, it's
just some work required -- it's not going to be fun but it's the clean
way for the longer term future.



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] "old style" hidden services after Prop224

[David Goulet]

On 12 Sep (22:29:00), Ivan Markin wrote:
> Razvan Dragomirescu:
> > Thank you Ivan! I still dont see a very good reason to _replace_ the 
> > current HS system with the one in Prop224 and not run the two in
> > parallel.
> 
> For me it's because it would make overall system more complex and thus
> error-prone and reasonably less secure. Is like using RC4, SHA1, 3DES in
> TLS and be vulnerable downgrade attacks and all kind of stuff like
> Sweet32 and LogJam (export-grade onions, haha).
> 
> > Why not let the client decide what format and security
> > features it wants for its services?
> 
> It's like dealing with plethora of ciphers and hashes in GnuPG:
> 
> https://moxie.org/blog/gpg-and-me/:
> > It’s up to the user whether the underlying cipher is SERPENT or IDEA
> > or TwoFish. The GnuPG man page is over sixteen thousand words long;
> > for comparison, the novel Fahrenheit 451 is only 40k words.
> 
> When system is complex in that way someone is going make huge
> mistake(s). If crypto is bad, just put it into museum.
> 
> So I don't see _any_ reason to manage outdated and less secure system
> while we have a better option (if we already deployed it).

Hello!

So I 100% share Ivan's concerns. The Hidden Service subsytem of Tor is quite
complex, lots of pieces need to be glued together and prop224 will add a lot
of new code (in the 10 of thousand+).

We decided a while back to have the two protocols living side by side at first
that is current system (v2) and next gen (v3). Relays will need to support v2
for a while after v3 is release because well not everybody updates their tor
to the latest. Lots of people have current .onion for which they need a
transition to the new generation which includes telling their users about the
new 52 character one and SSL certs and so on...

The question arise now. Someone running a .onion upgrades her tor that
supports v3, should we allow v2 to continue running or transition it to v3 or
make them both happy together...? We haven't discuss this in depth and thus we
need to come to a decision before we end up implementating this (which is
_soon_). I personally could think that we probably want to offer a transition
path and thus have maybe a torrc option that controls that behavior meaning
allowing v2 for which we enable by default at first and then a subsequent Tor
release will disable it so the user would have to explicitely set it to
continue running v2 .onion and then finally rip off v2 entirely in an other
release thus offering a deprecation path.

However, we are clear that every _new_ service will be v3 and never again v2
unless it already exists that is we can find a RSA private key (considering we
do the above of course). And considering both will be supported for a while,
we'll have to maintain v2 security wise but all new features will go in v3.

Let's discuss it and together we can come up with a good plan! :)

Thanks!
David

> 
> --
> Ivan Markin
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev


signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] "old style" hidden services after Prop224

[Razvan Dragomirescu]

Hello Ivan,

Breaking existing (possibly automated) systems is a _very good reason_ IMHO
:). Sure, warn the operators that they're using a legacy system, deprecate
the option but don't disable it.
https://trac.torproject.org/projects/tor/ticket/18054 sounds like a pretty
sane solution btw.

Even if it's no longer officially supported, I think OnionCat in its
current incarnation is a great proof of what could be done with the Tor
network, other than privacy protection. I actually have this listed on one
of my slides for SIM4Things - it's good for the Tor network, shows it can
be used for a variety of things while putting very little stress on the
network components. Very little traffic, potentially large PR impact (in a
good way :) ).

Razvan

On Tue, Sep 13, 2016 at 1:29 AM, Ivan Markin  wrote:

> Razvan Dragomirescu:
> > Thank you Ivan! I still dont see a very good reason to _replace_ the
> > current HS system with the one in Prop224 and not run the two in
> > parallel.
>
> For me it's because it would make overall system more complex and thus
> error-prone and reasonably less secure. Is like using RC4, SHA1, 3DES in
> TLS and be vulnerable downgrade attacks and all kind of stuff like
> Sweet32 and LogJam (export-grade onions, haha).
>
> > Why not let the client decide what format and security
> > features it wants for its services?
>
> It's like dealing with plethora of ciphers and hashes in GnuPG:
>
> https://moxie.org/blog/gpg-and-me/:
> > It’s up to the user whether the underlying cipher is SERPENT or IDEA
> > or TwoFish. The GnuPG man page is over sixteen thousand words long;
> > for comparison, the novel Fahrenheit 451 is only 40k words.
>
> When system is complex in that way someone is going make huge
> mistake(s). If crypto is bad, just put it into museum.
>
> So I don't see _any_ reason to manage outdated and less secure system
> while we have a better option (if we already deployed it).
>
> --
> Ivan Markin
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] [Patch] common/util_bug.h

[Gisle Vanem]

The 'IF_BUG_ONCE__' for non-gcc is wrong. A simple patch:

--- a/util_bug.h 2016-09-13 10:44:59
+++ b/util_bug.h 2016-09-08 20:24:45
@@ -117,7 +117,7 @@
 #else
 #define IF_BUG_ONCE__(cond,var) \
   static int var = 0;   \
-  if (PREDICT_UNLIKELY(cond)) ? \
+  if (PREDICT_UNLIKELY(cond) ?  \
   (var ? 1 :\
(var=1,  \
 tor_bug_occurred_(SHORT_FILE__, __LINE__, __func__, \
-- 
--gv
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] [tor-relays] Tor path selection upon failure

[teor]

> On 13 Sep 2016, at 14:02, Liu, Zhuotao  wrote:
> 
> Hi Folks,

Hi,

Please don't cross post to multiple lists, it makes it hard for people to 
follow all the responses.
Can I suggest that everyone replies to tor-dev, as it's the list for Tor 
development, feature, and issue discussion.
(The other list you used is for Tor relay operators to discuss relay operation 
and configuration.)

Tim

> 
> There have been some technical reports about how to deal with the problem 
> when a botnet uses Tor as its primary C channel. In this case, the CPU of 
> some relays is exhausted, causing circuit creation failure.
> 
> I am wondering currently how a client reacts when its circuit creation fails? 
> Does the client simply resend another create cell or it will re-select new 
> path instead?
> 
> Thanks
> ___
> tor-relays mailing list
> tor-rel...@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org








signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev