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

[Tor Bug Tracker & Wiki]

#4570: Implement certificate start time fuzzing and 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 [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?

 > 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.)

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

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/4570#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online