Re: [tor-bugs] #4570 [Tor Bridge]: Implement certificate serial number covert channel (part of proposal 179) (was: Implement certificate start time fuzzing and 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 asn):

 Replying to [comment:1 nickm]:
 > Replying to [ticket:4570 asn]:
 > > This ticket is for tracking the implementation of certificate start
 time fuzzing and serial number covert channel.
 >
 > I'm not sure it makes sense to have both of these in one ticket; are
 they actually related in some way I'm not getting?
 >

 It does not make sense. I'm restricting this to the serial number thing.

 > > Jake implemented both of these in his prop179 branch.
 > >
 > > wrt the serial number thing, if we decide to allow users to input
 their own TLS certificates, the serial number covert channel will get
 poluted. I think it's time to think if we really need '''this''' covert
 channel, or if we care that we will get false positives with user-specific
 certificates.
 >
 > If we want to do this, we need to care about false positives, or else
 it's useless.  (If there are false positives, then we can't safely use the
 hypothetical v4 link protocol whenever we see the hypothetical v4
 indicator.)
 >

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

 > > 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?

 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?

 [0]: On the other hand, a covert channel based on a shared secret has some
 uses. See 5.1: https://lists.torproject.org/pipermail/tor-
 dev/2011-November/003070.html

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/4570#comment:2>
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