[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #4549 [Tor Bridge]: Implement user-defined certificate strings through torrc (part of the proposal 179 efforts)

#4549: Implement user-defined certificate strings through torrc (part of the
proposal 179 efforts)
------------------------+---------------------------------------------------
 Reporter:  asn         |          Owner:                    
     Type:  defect      |         Status:  needs_review      
 Priority:  normal      |      Milestone:  Tor: 0.2.3.x-final
Component:  Tor Bridge  |        Version:                    
 Keywords:              |         Parent:  #3972             
   Points:              |   Actualpoints:                    
------------------------+---------------------------------------------------

Comment(by nickm):

 Replying to [comment:6 asn]:
 > Replying to [comment:3 nickm]:
 > >  * Customizeable start and end time and serial number: these are
 probably a mistake.  Serial number needs to be different for every
 generated cert with the same issuer; start time and end time seem like
 they're begging you to have your Tor not work because you made your own
 cert expire.  Instead let's go with certs that expire after a year or
 something; that seems to be the standard lifetime.
 >
 > You think so?

 I don't say stuff I don't think on trac tickets :)

 >  I see the validity options as a poor man's solution to #4390#comment:1
 > and a much better way to do "start time fuzzing".

 We can get a much better solution by keeping certs around on disk, so we
 actually have start/end times that mean something.

 > We can enforce correct use by doing appropriate checks.
 > I'm already checking that `CertEndDate` > `CertStartDate`. We can also
 check that `CertEndDate` and `CertStartDate` are bigger than time(NULL).
 > We can also add a LOG_WARN message in the startup that "the options you
 set are advanced options.".
 >
 > Of course, they should also be considered advanced options (as the rest
 of the TLSCert* options are). My point is that if at some point censors
 find a way to detect our serial numbers, and *don't* have a way to check
 that a relay's serial number has been the same, bridge operators can
 circumvent blocking by setting their own SNs. The same goes for validity
 times.

 Probably we should look into how self-signed certs' serial numbers are
 generated, and do ours like that instead.  AFAICT, openssl's tools for
 making certs don't ask you for your own serial number: they instead just
 generate a random 64-bit value.

 > I don't see us losing much by implementing this, and we increase our
 versatility.

 I do.  It will make our certs follow a very weird pattern (changing every
 day, but having the same start and end time and serial number each time),
 and will make nodes suddenly stop working when the end date passes without
 people reconfiguring their Tor, and will force people to understand what
 an X509 serial number is.

 Also, once we _do_ have a real solution to this problem (probably
 involving storing the same cert to disk and using it longer-term), we'll
 still be stuck with the code we added to support these options
 indefinitely.

 > >  * It looks like you apply the issuer name stuff to be the name of
 EVERY issuer, and the subject name to be subject name on EVERY cert?  That
 isn't right, if so.  This stuff only wants to apply to the initial
 presented-in-cleartext cert, which now wants to be different from the cert
 chain presented after in the v2 or v3 handshake.  The cert chain probably
 wants to stay unchanged.
 >
 > I agree, I'll try to implement it properly.. I did it like this, because
 I saw the `cname`, `cname_sign` stuff getting applied to all certificates,
 and I didn't want to complicate the implementation.
 >
 > >  * How have you tested this?
 >
 > I ran wireshark and checked out the TLS certificates. I also ran a local
 relay/client and made sure that nothing is screwed up in normal Tor
 operation. I'll do more checks in the latter scenario.

 Okay. in the next round of tests, make sure that the 0.2.2 Tor clients and
 servers can interoperate with clients and servers running this patched
 code.

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