Mostly from f01e92dd.

The Elligator inverse map uses the least significant bits of the private
key, which clamping sets to 0, to choose a random low-order point to add
to the public key, to ensure uniformity of representatives.

The other ways that the private key is used, namely in calls to
curve25519.ScalarMult and curve25519.ScalarBaseMult, do their own
clamping when necessary and are documented to accept a uniformly random
scalar.

See discussion under "Step 2" at https://elligator.org/key-exchange.

While this was a good idea back when I did it:

 * People don't like the fact that it requires a fork of utls to fix
   compatibility issues, and would rather spend 3 years complaining
   about it instead of spending a weekend to fix the issues in
   upstream.

 * Tor over meek is trivially identifiable regardless of utls or not.

 * Malware asshats ruined domain fronting for everybody.

Fix a comment, no functional changes.

Replace agl's Elligator2 implementation with a different one, that fixes
the various distinguishers stemming from bugs in the original
implementation and "The Elligator paper is extremely hard to read".

All releases prior to this commit are trivially distinguishable with
simple math, so upgrading is strongly recommended.  The upgrade is fully
backward-compatible with existing implementations, however the
non-upgraded side will emit traffic that is trivially distinguishable
from random.

Special thanks to Loup Vaillant for his body of work on this primitive,
and for motivating me to fix it.

And add the Chrome 83 fingerprint.

Obfs4proxy implements the -unsafeLogging switch but it's been ignored so
far.  This patch makes it work.

Microsoft recently updated the root CA certificates that are served to
Azure clients.  See the following article for more details:
https://docs.microsoft.com/en-us/azure/security/fundamentals/tls-certificate-changes



This change broke meek-lite because none of its pins work anymore.  That
means that Tor Browser users can no longer use meek-azure or moat as
both rely on meek-lite.

This patch fixes the problem by updating the certificate pins.

Signed-off-by: Yawning Angel <yawning@schwanenlied.me>

I really didn't want to do this, but this should make `go get` work
again, and maybe people will leave me alone.

The old behavior closed the connection on handshake failure after:
 * The first N bytes (random on a per-server basis).
 * The first M seconds (random on a per-server basis).

Whichever came first.  As Sergey Frolov kindly points out, depending on
which conditions cause termination, the server will send either a FIN or
a RST.  This change will remove the "amount read" based termination
threshold, so that connections that cause failed handshakes will discard
all data received until the teardown time is reached.

Thanks to Sergey Frolov for bringing this issue to my attention.

 * Bump the module import to a new tag
 * Bump the rest of the dependencies while I'm here
 * Add some new fingerprints from upstream
 * Disable my fork's AES timing sidechannel defenses

Upstream fixed a bug, so use a tag that has the important parts
cherry-picked.

This should give me more time before I need to update this.

Mostly since the built-in pins will likely become invalid once the
certificates I used to generate them start to expire.

HPKP is effectively dead as far as a standard goes, but the idea has
merit in certain use cases, this being one of them.

As a TLS MITM essentially will strip whatever obfuscation that the
transport may provide, the digests of the SubjectPublicKeyInfo fields
of the Tor Browser Azure meek host are now hardcoded.

The behavior can be disabled by passing `disableHPKP=true` on the bridge
line, for cases where comaptibility is prefered over security.

Changes:
 * Use a fork of utls with some compatibility improvements.
 * Switch the default ClientHello profile to `HelloFirefox_Auto`.
 * Add the `HelloChrome_71` profile.

The existing `HelloFirefox_Auto` profile that points to
`HelloFirefox_63` also matches the (common) behavior of Firefox 65,
assuming that 3DES ciphersuites are not disabled.

Fix `getDialTLSAddr` to always return a integer port.  Thanks to dcf for
reporting the issue.