[TLS] Downgrade protection, fallbacks, and server time

[David Benjamin <[e-mail]>]

In case folks hoped we could bump the ClientHello version without those
dreaded browser fallbacks, I have bad news. :-( 1.3 intolerance very much
exists. (Maybe we should just give up on ClientHello.version and use an
extension? Extensions have rusted less.)

I picked a large list of top sites and tried connecting to them. Just under
2% of them could handle a TLS 1.2 ClientHello, but not the same ClientHello
with the version switched to 1.3 (no other changes, so I haven't tested a
real 1.3 ClientHello). They're not unknown hosts either. I expect if you
probe any top site list, you'll very quickly find some.

Fortunately, the ServerHello.random trick fixes this. But it currently
clobbers the old server timestamp which tlsdate[1] uses for clock
synchronization. There really should be a less silly secure timestamping
protocol, but, today, tlsdate has users. Any servers which expect to be a
tlsdate target can't honor this MUST without tlsdate gone.

(FALLBACK_SCSV works fine as well, but I gather people prefer the
ServerHello.random one and would be unhappy having to implement both in
clients with a fallback because not all servers do the latter.)

I mentioned this before, but rather than clobbering the first 8 bytes, the
last 8 bytes seems as reasonable and avoids this unnecessary complication
to TLS 1.3 deployment. If folks agree now that the fallback's resurrection
is more certain, I'm happy to put together a PR.

David

[1] https://github.com/ioerror/tlsdate