Submitted by: Marcelo Cerri

This fixes problems in POD list formatting: extra or missing =back
sequences.

doc/ssl/SSL_CTX_set1_curves.pod around line 90: =back without =over
doc/ssl/SSL_CTX_set1_verify_cert_store.pod around line 73: =back without =over
doc/ssl/SSL_CTX_add1_chain_cert.pod around line 82: =back without =over
doc/crypto/evp.pod around line 40: '=item' outside of any '=over'
crypto/des/des.pod around line 184: You forgot a '=back' before '=head1'

PR#3147

Newer pod2man considers =item [1-9] part of a numbered list, while =item
0 starts an unnumbered list. Add a zero effect formatting mark to override
this.

doc/apps/smime.pod around line 315: Expected text after =item, not a
number
...

PR#3146

Instead, send random bytes, unless SSL_SEND_{CLIENT,SERVER}RANDOM_MODE
is set.

This is a forward-port of commits:
  4af79303
  f4c93b46
  3da721da
  25832701

While the gmt_unix_time record was added in an ostensible attempt to
mitigate the dangers of a bad RNG, its presence leaks the host's view
of the current time in the clear.  This minor leak can help
fingerprint TLS instances across networks and protocols... and what's
worse, it's doubtful thet the gmt_unix_time record does any good at
all for its intended purpose, since:

    * It's quite possible to open two TLS connections in one second.

    * If the PRNG output is prone to repeat itself, ephemeral
      handshakes (and who knows what else besides) are broken.

Extend SSL_CONF to return command value types.

Add certificate and key options.

Update documentation.

The function gettimeofday() is not supported on all platforms. Use
more portable versions. Adapted from FIPS code.

Removing RSA+MD5 from the default signature algorithm list
prevents its use by default.

If a broken implementation attempts to use RSA+MD5 anyway the sanity
checking of signature algorithms will cause a fatal alert.

Suggested by: Anton Blanchard

Latest MIPS ISA specification declared 'branch likely' instructions
obsolete. To makes code future-proof replace them with equivalent.

Excessive fragmentation put additional burden (of addtional MAC
calculations) on the other size and limiting fragments it to 1KB
limits the overhead to ~6%.

PR: 3139