Re: [tor-bugs] #4570 [Tor Bridge]: Implement certificate serial number covert channel (part of proposal 179)

["Tor Bug Tracker & Wiki" <torproject-admin@xxxxxxxxxxxxxx>]

#4570: Implement certificate serial number covert channel (part of proposal 179)
------------------------+---------------------------------------------------
 Reporter:  asn         |          Owner:       
     Type:  defect      |         Status:  new  
 Priority:  normal      |      Milestone:       
Component:  Tor Bridge  |        Version:       
 Keywords:              |         Parent:  #3972
   Points:              |   Actualpoints:       
------------------------+---------------------------------------------------

Comment(by nickm):

 Replying to [comment:2 asn]:

 > We will always have false positives with this scheme, till all the
 non-0.2.3.x relays disappear from the network.

 Unless we use the other v3-indicating cert features plus the SN to
 indicate

 Let's take a step back -- do you currently think this feature is a good
 idea?  I don't think it's workable if we have user-provided certs, and I
 think that getting user-provided certs to work is more important than
 this.


 > > > For link protocol version negotiation, we have the VERSIONS cell. We
 might '''need''' a covert channel '''on''' the SSL handshake, if we need
 to negotiate the link protocol version before the Tor protocol. In which
 cases do we need such a '''visible''' covert channel?
 > >
 > > The question isn't whether we need a visible one; it's whether we'll
 ever need to do again what we've done with the v1->v2 and v2->v3 link
 protocol transition, where the client learns which handshake it is before
 the handshake is actually done, so that the client can act differently,
 depending.  I *think* that v3 should be flexible enough to last
 indefinitely, but we should actually figure this out.
 >
 > VERSIONS cells should be enough to negotiate future 'in-protocol' link
 protocols.
 >
 > A covert channel like the one described in 178 could find use:
 >
 > a) If we needed to do our link protocol in the initial SSL handshake.
 But we've grown old for that, no?

 Well, we did need to negotiate v1 vs v2 this way, and v2 vs v3 this way.
 We couldn't use VERSIONS cells, since these connection varieties differ in
 their TLS handshakes.

 > b) If we needed to negotiate the link protocol before the Tor protocol
 hits the wire. This sounds like an anti-bridge-detection measure, but I
 can't find any scenarios where such a '''visible''' covert channel would
 help [0].
 >
 > Can you describe a use case where VERSIONS wouldn't do it and this
 serialNumber covert channel would help?

 Yes; the case of how we negotiate v1 vs v2, and v2 vs v3 now.  If we need
 to do some other kind of TLS handshake, then the VERSIONS cell can't help
 us, since that happens after the TLS handshake.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/4570#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs