<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hi Mike,</div><div><br></div><div>Our application is not browser/HTTP based. We are running a daemon which does not have native SSL support. The clients have been modified to "speak" SSL (using java SSLSocket).</div><div>Our application runs within a secure network, however we want to encrypt the sensitive content of the protocol. Server-side host verification of the client seemed like a good way to authenticate the client.</div><div>Stunnel runs in server mode. We were contemplating the possibility of comparing the client's source address (from reverse DNS lookup) with the CNAME in the certificate.</div><div><br></div><div>It looks like your comment (#2) explains the problem with this approach.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>"Comparing CNAME/SubjectAltName against client's IP address or FQDN would be pointless from security perspective, as both are spoofable."</div><div><br></div><div>This statement is predicated on the DNS being tampered with, correct?</div><div>In our scenario it is unlikely that DNS would be tampered with -- of course, nothing is 100% guaranteed.</div><div><br></div><div>Thoughts?</div><div><br></div><div>I'll take a look at the link you suggested.</div><div><br></div><div><br></div><div>Regards,</div><div>-Fred</div><div><br></div><div><div>PS> As a disclaimer I am coming up to speed on SSL/TLS, so please excuse me if my questions/assumptions are 101 in nature.</div></div><div>PPS> Kudos on a well implemented tool.</div><div><br></div><div><br></div><br><div><div>On Sep 19, 2013, at 4:04 PM, Michal Trojnara <<a href="mailto:Michal.Trojnara@mirt.net">Michal.Trojnara@mirt.net</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 2013-09-12 18:20, <a class="moz-txt-link-abbreviated" href="mailto:fslama@comcast.net">fslama@comcast.net</a>
wrote:<br>
</div>
<blockquote cite="mid:1350163619.2676997.1379002805271.JavaMail.root@comcast.net" type="cite">
<div style="font-family: Arial; font-size: 12pt; ">I
have a requirement to have stunnel (4.56) validate client
certificates and their identity by comparing the its CNAME
against the source address.</div>
</blockquote>
Can you elaborate on this? What to you mean by source address?
IPv4/IPv4 IP address? FQDN retrieved with reverse DNS lookup?<br>
<br>
<blockquote cite="mid:1350163619.2676997.1379002805271.JavaMail.root@comcast.net" type="cite">
<div style="font-family: Arial; font-size: 12pt; ">
<div>I recall reading one response (which I can't find at the
moment) from Marzena Trojnara indicating that this feature
won't be supported.</div>
<div>If so, can you explain the rational?</div>
</div>
</blockquote>
The rationale is as follows:<br>
1. FQDN verification was introduced to check whether the web site
the browser connected to is indeed the web site intended by the
browser.<br>
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.<br>
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.<br>
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.<br>
<br>
I also recommend reading chapter 3 (Endpoint Identification) of RFC
2818 (<a href="http://tools.ietf.org/html/rfc2818">http://tools.ietf.org/html/rfc2818</a>).
This document is specific to HTTPS, as HTTPS is currently the only
SSL based protocol that relies on CNAME/SubjectAltName for
authentication.<br>
<br>
Mike<br>
</div>
_______________________________________________<br>stunnel-users mailing list<br><a href="mailto:stunnel-users@stunnel.org">stunnel-users@stunnel.org</a><br>https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users<br></blockquote></div><br></body></html>