On Mon, Apr 27, 2009 at 12:07:57PM +0200, Steffen DETTMER wrote:
> The more secure way is to use existing
> crypto schemes (like TLS) and the safer way is to base on
> existing implementations (like stunnel), I think.
It should be noted that stunnel in client-mode does not verify the server
peername with verify=2 (verify=2 has questionable client-mode semantics).
To properly verify a peer server in an stunnel client is verify=3.
Here's an example for SMTP tunneling:
[smtp]
protocol = smtp
accept = 587
connect = smtp.example.com:587
CAfile = /etc/stunnel/smtp.example.com:587.pem
client = yes
verify = 3
In the CAfile include not only the trusted root that signs the peer
cert or top-level intermediate CA, but also certificate(s) whose
subject-name(s) exactly match the target peer(s). The contents of the
certs don't matter, and in fact it is best if the certs' keys ae lost,
are expired, ... so that they not mis-used for any other purpose.
Here's an example of how to build the fake cert:
$ SUBJ=$(openssl x509 -in server-cert.pem -noout -subject) || exit 1
$ SUBJ=$(echo "$SUBJ" | sed -e 's/^subject= *//') || exit 1
$ openssl req -new -x509 -out fake-cert.pem -subj "$SUBJ" \
-days 1 -nodes -newkey rsa:1024 -keyout /dev/null -extensions v3_req
$ cat fake-cert.pem >> /etc/stunnel/smtp.example.com:587.pem
With verify=3 stunnel ensures that the leaf certificate subject is listed
in CAfile (or CApath) and this effectively verifies the peername. If
the connection endpoint represents multiple hosts with separate certs,
list them all in CAfile. There is no support for match patterns, ... all
matches are exact matches on the full subject name.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [email protected]
Automated List Manager [email protected]
