Decoy Registrar Troubleshooting

[jmwample]

investigating failing connections and unreasonable timeouts when using the decoy registrar

[13:58:35] Sending Reg: x.y.edu, 1.2.3.4:443
[13:58:47] dial tcp 1.2.3.4:443: i/o timeout
[13:58:47] Successfully sent registrations, sleeping for: 26.762s

when one of the registrations times out the entire timeout is considered to be the RTT. The RTT is then used for a sleep which can cause an unreasonably long sleep time.

Issues:

• All decoy dials try to write to set tcp rtt

• the last one to write (i.e. the slowest one) is the one that is kept

  • even things with errors write rtt - so timeout

• DecoyRegistrar.Register() waits for all decoy connections to be finished before returning

  • i.e. if connections to one decoy times out it will wait.
  • EVEN if some succeed, it has to wait for broken ones meaning extremely slow connection overall

  ^ this is not true, the registrar waits until one of the N=width decoy connections succeeds without error to continue. So the only situation where it waits for on broken connections is if all decoy connections fail, timeout, or otherwise break.

---

Now only the fastest successful connection writes to the RTT.

The maximum sleep after reading has also been reduced using a max RTT and more reasonable TLS timeouts.

Fixes issue with PrepareRegKeys() that was introduced by #202

[jmwample]

I added a whole TLS connetion mock to test the reverse encrypt and aes-gcm encoding of the fsp and vsp to ensure that the expected registration information is being sent. This test now passes consistently, HOWEVER, we found that - at least with pipes - golang uses a conservative MTU of 576. which is less than our application data packet size a decent percentage of the time. this is a problem because the station is not keeping state to handle the case where the application data packet containing a registration gets fragmented.

It is unclear if this issue effects normal traffic sent by golang.