Serverd now fails handshake from early on, if no client certificate is presented by the peer.
Beatify source.
tls_generic_test now creates a different directory on each run.

Previously every time it failed we had to manually remove the
/tmp/tls_test directory, else it failed with different errors when
rerunning the test!
Update tls_generic_test.
Fortify the TLS handshake callback.

Up to now the TLS handshake callback was always returning success, and
key checks were performed manually after a small identification
dialog. Today this is still the case, with some extra checks in the
handshake.

The reason is that the same callback is used not only for the initial
handshake, but for any "TLS renegotiation" handshake. During such a
handshake, either the client or the server can change almost every
parameter of the secure session, even their certificates. For our custom
usage of the TLS protocol this shouldn't be an issue, since we disregard
anything about certificates and only care about the first presented key
which we compare to the one in ppkeys directory.

However an attack was recently published ("triple handshake" attack, see
[1]), which is applicable to the TLS protocol up to and including
version 1.2, that requires an /active/ and /trusted server/ as man in
the middle attacker exploiting session resumption and renegotiation,
both standard TLS features. CFEngine is using TLS in a very custom
manner and is not in danger from that attack.

[1] https://www.secure-resumption.com/

Nevertheless, this patchset employs the countermeasures suggested by the
authors of the attack. In particular, if any change of certificate is
detected during renegotiation, the renegotiation handshake is denied. In
addition, many rigorous sanity tests were added in the handshake
callback, and CFEngine refuses the connection if anything seems to be
fishy. All checks were added in both server and client side.
Merge pull request #1727 from jimis/fortify_tls_handshake

Fortify tls handshake