[stunnel-users] Fwd: Re: Hostname verification, support for, and patches

[Brian Wilkins]

This is the latest traffic on DNS..may be helpful
---------- Forwarded message ----------
From: "Michal Trojnara" <Michal.Trojnara at mirt.net>
Date: Sep 19, 2013 4:04 PM
Subject: Re: [stunnel-users] Hostname verification, support for, and patches
To: <stunnel-users at stunnel.org>
Cc:

 On 2013-09-12 18:20, fslama at 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

_______________________________________________
stunnel-users mailing list
stunnel-users at stunnel.org
https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20131206/b44272ae/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: not available
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20131206/b44272ae/attachment.sig>