Re: [tor-bugs] #19163 [Core Tor/Tor]: Make sure clients almost always use ntor

[Tor Bug Tracker & Wiki]

#19163: Make sure clients almost always use ntor
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.9.x-final
 Keywords:  rsos, tor-hs, TorCoreTeam201607  |Version:
Parent ID:   | Resolution:
 Reviewer:   |  Actual Points:  5
 | Points:  1.0
 |Sponsor:
-+-

Comment (by teor):

 I added some fixups to reject-tap-v5 on both github and gitlab:

 d790fee fixup! Client & HS ignore UseNTorHandshake, all non-HS handshakes
 use ntor
 * Allow client intro and HS rend to use ntor, TAP, and CREATE_FAST, in
 that order

 5bc3335 fixup! Client intro opportunistically upgrades to ntor
 * Allow client intro to use TAP when none of the intro points are in the
 consensus
 * Allow Tor2web client intro to use CREATE_FAST when making a direct
 connection, none of the intro points are in the consensus, and none have
 TAP keys in the HS descriptor

 Gitlab is at:
 https://gitlab.com/teor/tor/merge_requests/2

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #19163 [Core Tor/Tor]: Make sure clients almost always use ntor

[Tor Bug Tracker & Wiki]

#19163: Make sure clients almost always use ntor
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 Priority:  Medium   |  needs_revision
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.9.x-final
 Keywords:  rsos, tor-hs, TorCoreTeam201607, |Version:
  review-group-6 | Resolution:
Parent ID:   |  Actual Points:  5
 Reviewer:  nickm| Points:  1.0
 |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => needs_revision
 * reviewer:   => nickm


Comment:

 Actual-review-points: .1

 Added some comments on the gitlab page.  Issues seem minor.  I'm most
 concerned here about the testing of this, but if you've tested that it
 doesn't break hidden services, I believe it.

 (Have you looked at the test coverage for the lines that changed?)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #19163 [Core Tor/Tor]: Make sure clients almost always use ntor

[Tor Bug Tracker & Wiki]

#19163: Make sure clients almost always use ntor
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rsos, tor-hs, TorCoreTeam201608, |  Actual Points:  5
  review-group-7 |
Parent ID:   | Points:  2.0
 Reviewer:  nickm|Sponsor:
-+-
Changes (by teor):

 * status:  needs_revision => needs_review
 * keywords:  rsos, tor-hs, TorCoreTeam201607, review-group-7 => rsos, tor-
 hs, TorCoreTeam201608, review-group-7
 * points:  1.0 => 2.0


Comment:

 I've made an update based on nickm's review, and pushed it to github and
 gitlab.
 branch reject-tap-v5 on https://github.com/teor2345/tor.git
 https://gitlab.com/teor/tor/merge_requests/2

 I also folded the code from #19923 into this branch. I needed to add a
 stub for rend_service_allow_direct_connection to get it to compile.

 Sorry for the swapping back and forth.

 I still need to look at the test coverage of the changed lines, and do
 some more testing using mixed-version chutney networks, in particular:
 * basic-min (but with half/half old/new tor versions)
 * hs-min (but with half/half old/new tor versions)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #19163 [Core Tor/Tor]: Make sure clients almost always use ntor

[Tor Bug Tracker & Wiki]

#19163: Make sure clients almost always use ntor
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rsos, tor-hs, TorCoreTeam201608, |  Actual Points:  5
  review-group-7 |
Parent ID:   | Points:  2.0
 Reviewer:  nickm|Sponsor:
-+-

Comment (by teor):

 Testing this is difficult!

 I have merged two new chutney networks to chutney master, hs-min-mixed and
 basic-min-mixed. They are an even mix of old and new tor versions, and
 will likely fail if old and new versions do incompatible things. I've
 tested them with this patch and Tor 0.2.7.6.

 I also want to write unit tests for the cases where:
 * the service selects an intro point that's not in the client consensus,
 and
 * the client selects a rendezvous point that's not in the service
 consensus

 It is very hard to give a client and a relay different consensuses in
 chutney, so unit tests will have to do. Perhaps I should check code
 coverage first, so I know where to focus my efforts.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #19163 [Core Tor/Tor]: Make sure clients almost always use ntor

[Tor Bug Tracker & Wiki]

#19163: Make sure clients almost always use ntor
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rsos, tor-hs, TorCoreTeam201608, |  Actual Points:  5
  review-group-7 |
Parent ID:   | Points:  2.0
 Reviewer:  nickm|Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 Re-review:

   * I worry about the security of the opportunistic upgrade stuff. It has
 the potential to enable epistemic attacks.

 Otherwise stuff looks good.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #19163 [Core Tor/Tor]: Make sure clients almost always use ntor

[Tor Bug Tracker & Wiki]

#19163: Make sure clients almost always use ntor
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rsos, tor-hs, TorCoreTeam201608, |  Actual Points:  5
  review-group-7 |
Parent ID:   | Points:  2.0
 Reviewer:  nickm|Sponsor:
-+-

Comment (by teor):

 Replying to [comment:17 nickm]:
 > Re-review:
 >
 >   * I worry about the security of the opportunistic upgrade stuff. It
 has the potential to enable epistemic attacks.
 >
 > Otherwise stuff looks good.

 Yes, I have the same concerns - you could probe a client / hidden service
 to find out which relays it knows about. And it's hard to test.

 Here are our options:
 * We could control opportunistic upgrades with a consensus parameter that
 we only switch on when 0.2.8 is no longer recommended. But this means the
 code won't be tested.
 * We could remove opportunistic upgrades entirely, and only kill off TAP
 when we kill off the old hidden service protocol.

 And separately, for Single Onion Services / Tor2web:
 * We could always do opportunistic upgrades, because it doesn't matter if
 anyone knows what consensus a Single Onion Service or Tor2web client has,
 and it's more important to protect the single-hop link with ntor rather
 than using the vulnerable TAP protocol.
 * Or we could go with either of the above options.

 What do you think?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #19163 [Core Tor/Tor]: Make sure clients almost always use ntor

[Tor Bug Tracker & Wiki]

#19163: Make sure clients almost always use ntor
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rsos, tor-hs, TorCoreTeam201608, |  Actual Points:  6
  review-group-7 |
Parent ID:   | Points:  2.0
 Reviewer:  nickm|Sponsor:
-+-
Changes (by teor):

 * status:  needs_revision => needs_review
 * actualpoints:  5 => 6


Comment:

 nickm said on IRC to just get rid of the opportunistic upgrades.

 Turns out that rend_client_get_random_intro_impl() already inadvertently
 upgrades to ntor in the following circumstances:
 * the HS descriptor doesn't contain a TAP onion key
 * the node can be found by nickname or fingerprint in the client's
 consensus

 I've left that code as-is, but I can easily remove it if you'd like.
 I think we should be consistent between client intro and service rend, and
 never upgrade from the consensus. (It certainly doesn't break modern
 clients or hidden services.)

 Please see my branch reject-tap-v6 on https://github.com/teor2345/tor.git
 Or on gitlab at https://gitlab.com/teor/tor/merge_requests/7

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #19163 [Core Tor/Tor]: Make sure clients almost always use ntor

[Tor Bug Tracker & Wiki]

#19163: Make sure clients almost always use ntor
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rsos, tor-hs, TorCoreTeam201608, |  Actual Points:  6
  review-group-7 |
Parent ID:   | Points:  2.0
 Reviewer:  nickm|Sponsor:
-+-

Comment (by nickm):

 I think we should consider _that_ ntor-upgrade a separate bug, and open
 another ticket for it.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #19163 [Core Tor/Tor]: Make sure clients almost always use ntor

[Tor Bug Tracker & Wiki]

#19163: Make sure clients almost always use ntor
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rsos, tor-hs, TorCoreTeam201608, |  Actual Points:  6
  review-group-7 |
Parent ID:   | Points:  2.0
 Reviewer:  nickm|Sponsor:
-+-

Comment (by nickm):

 Replying to [comment:20 nickm]:
 > I think we should consider _that_ ntor-upgrade a separate bug, and open
 another ticket for it.

 Teor has opened this ticket as #20012 .

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #19163 [Core Tor/Tor]: Make sure clients almost always use ntor

[Tor Bug Tracker & Wiki]

#19163: Make sure clients almost always use ntor
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rsos, tor-hs, TorCoreTeam201608, |  implemented
  review-group-7 |  Actual Points:  6
Parent ID:   | Points:  2.0
 Reviewer:  nickm|Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => closed
 * resolution:   => implemented


Comment:

 Okay, looks good now!  Merging it.  Please have a look at my merge commit
 (bbaa7d09a045130560a2f5da579671c5e02c9cd7) to make sure that my solution
 for the conflict in routerlist.c didn't reintroduce #19973 .

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #19163 [Core Tor/Tor]: Make sure clients almost always use ntor

[Tor Bug Tracker & Wiki]

#19163: Make sure clients almost always use ntor
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rsos, tor-hs, TorCoreTeam201608, |  implemented
  review-group-7 |  Actual Points:  6
Parent ID:   | Points:  2.0
 Reviewer:  nickm|Sponsor:
-+-

Comment (by nickm):

 Actual-review-points: .2

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #19163 [Core Tor/Tor]: Make sure clients almost always use ntor

[Tor Bug Tracker & Wiki]

#19163: Make sure clients almost always use ntor
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rsos, tor-hs, TorCoreTeam201608, |  implemented
  review-group-7 |  Actual Points:  6
Parent ID:   | Points:  2.0
 Reviewer:  nickm|Sponsor:
-+-

Comment (by teor):

 Replying to [comment:22 nickm]:
 > Okay, looks good now!  Merging it.  Please have a look at my merge
 commit (bbaa7d09a045130560a2f5da579671c5e02c9cd7) to make sure that my
 solution for the conflict in routerlist.c didn't reintroduce #19973 .

 The merge commit looks good, apart from the following comment line being
 removed:

 {{{
 -  * if we are making a direct connection */
 }}}

 I'm not too worried about that, because the next line is pretty readable
 even without the comment:

 {{{
  +if (direct_conn && check_reach &&
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #19163 [Core Tor/Tor]: Make sure clients almost always use ntor (was: Maybe RSOS single-hop circuits should always have ntor)

[Tor Bug Tracker & Wiki]

#19163: Make sure clients almost always use ntor
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.9.x-final
 Keywords:  rsos, tor-hs, TorCoreTeam201607  |Version:
Parent ID:   | Resolution:
 Reviewer:   |  Actual Points:  5
 | Points:  1.0
 |Sponsor:
-+-
Description changed by teor:

Old description:

> isis asks in #1744:
> {{{
>  // XXXprop#188 Why do we not care if it's ntor if it's only one hop?
> }}}
>
> I think it's because one-hop circuits were originally used only for
> directory fetches, which are authenticated by signature (and not
> private).
>
> But with RSOS, maybe we should require all one-hop paths to have ntor. I
> need to talk to a cryptographer about this.
>
> See the `populate_cpath` function for details.

New description:

 Update:
 All clients should use ntor for almost everything
 The only exceptions are during the hidden service protocol. Client to
 intro and hidden service to rendezvous should still be able to use TAP.

 -

 isis asks in #1744:
 {{{
  // XXXprop#188 Why do we not care if it's ntor if it's only one hop?
 }}}

 I think it's because one-hop circuits were originally used only for
 directory fetches, which are authenticated by signature (and not private).

 But with RSOS, maybe we should require all one-hop paths to have ntor. I
 need to talk to a cryptographer about this.

 See the `populate_cpath` function for details.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs