On 2013-09-12 18:20, fslama@comcast.net wrote:

I have a requirement to have stunnel (4.56) validate client certificates and their identity by comparing the its CNAME against the source address.

Can you elaborate on this? What to you mean by source address? IPv4/IPv4 IP address? FQDN retrieved with reverse DNS lookup?

I recall reading one response (which I can't find at the moment) from Marzena Trojnara indicating that this feature won't be supported.

If so, can you explain the rational?

The rationale is as follows:
1. FQDN verification was introduced to check whether the web site the browser connected to is indeed the web site intended by the browser.
2. For server mode (to verify peer clients) it would not be possible to check *intended* peer address, as it is client that initiates the connection and not server, thus a server has no way to know what the *intended* peer is. Comparing CNAME/SubjectAltName against client's IP address or FQDN would be pointless from security perspective, as both are spoofable.
3. For client mode (to verify peer servers) it is much better (i.e. more secure) to just download peer certificate and use "verify = 4". Web browsers have to rely on CNAME/SubjectAltName checks, as unlike stunnel they don't know in advance the identity of servers they'll connect to.
4. Proper FQDN validation is a complex task. There were many security vulnerabilities in mainstream browsers due to the complexity of IDN and wildcard certificates.

I also recommend reading chapter 3 (Endpoint Identification) of RFC 2818 (http://tools.ietf.org/html/rfc2818). This document is specific to HTTPS, as HTTPS is currently the only SSL based protocol that relies on CNAME/SubjectAltName for authentication.

Mike