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 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