Fix active attack on length field
There is an active attack to identify obfs4. Each data packet begins with an unauthenticated 2-byte length field. That length field is encrypted but it can be modified in a predictable way because the encryption is XORing. The adversary can therefore test if there is an encrypted two-byte length field by flipping some bits, which adds a known amount X to the received length if the adversary has seen the entire message and thus knows its true length. The adversary then follows that up with X arbitrary bytes, and the advesrary concludes the connection is running obfs4 if the server immediately closes the connection after the Xth added byte is sent (because at that point it believes it has the whole message and attempts unsuccessfully to authenticate the message). Having an obfuscated 2-byte length field at the beginning of data packets seems unique to obfs4, at least among all the encrypted protocols that I am familiar with.
Unfortunately, there is no obviously great solution to this problem. An obvious "fix" is to add a 16-byte MAC tag on (and immediately after) the 2-byte length field. This solution does still allow the adversary to test for such structure in the packet by flipping some bits in the length field and observing if the server closes the connection as soon as the subsequent 16 bytes are received. An authenticated 2-byte field beginning a data packet seems fairly unique as well.
Another option is to get rid of the length field and instead use a sentinal field marking the end of a variable-length message. This strategy is actually used by obfs4 for the handshake packets. Of course, the sentinal byte would have to look random, achievable easily enough by adding a counter into the HMAC. The adversary could, however, test for this strategy as well by replacing all data with random bytes to see at what point the server closes the connection, which would presumably happen when some fixed maximum frame length is reached. Perhaps that maximum frame length could be somewhat randomly chosen per-server, based on the bridge nodeID and/or public key.