[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 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 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 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.
I don't see us losing much by implementing this, and we increase our
versatility.
> * tor_X509_name_new now has tons of copy-and-paste code. That's not so
good; let's use a function or a macro to make it shorter.
> * There's no need to use BN_pseudo_rand to get a random number; just
use Tor's crypto_rand_int or whatever it's called.
> * The documentation for tor_decorate_cert makes no sense to me. How
does stuff "float around" ? What does it mean to "decorate" a cert?
Which certs get decorated? Why is this a separate function?
> * Looks like the covert-channel-in-the-serialnumber junk is still in
here too; it'll need to come out.
>
> Questions/ideas:
>
> * 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.
> * Maybe we should have the ability to store these and the corresponding
link keys in the datadir. If so, that should probably get done along with
the "load a custom cert from disk" work.
Yes, this can be done along with #4550.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/4549#comment:6>
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