Optionally validate certificates on TLS server links
Bugzilla#120 is a *really* long-standing issue, and it's a very
important one: The peer's certificate is *not* validated on a server
link, rendering the security on such links useless since a
man-in-the-middle attacker can easily capture all the traffic and
re-encode it without even being noticed.
More than five years ago, Florian Westphal wrote a patch to mitigate
the issue but it was never completed nor made it to master. So I
took the liberty to rebase the patch onto rel-22, update the
configuration variables to reflect the rel-19-ish configuration
changes, and to fix a common error in certificate validation: The
certificate's CN must match the host name the client connects to.
This is anything but ready for prime time. Please test in every
conceivable way, there are many. Especially CRL is completely
untested. If you have an SSL/TLS guru at hand, please seek his advice.
There are many, many pitfalls in this area and certainly some are
still present. Host name validation should not solely done against the
CN, this is rather a last resort [citation needed]. Also, an outgoing
connection probably does not work against work SNI but certainly
should.
Also to do: Minor code style cleanup, some more error checking.
Cheers,
Christoph, beware of easter eggs
Based on
From: Florian Westphal <fw@strlen.de>
Date: Mon, 18 May 2009 00:29:02 +0200
Subject: [PATCH] SSL/TLS: add initial certificate support to openssl backend