<p dir="ltr">This is the latest traffic on DNS..may be helpful</p>
<div class="gmail_quote">---------- Forwarded message ----------<br>From: "Michal Trojnara" <<a href="mailto:Michal.Trojnara@mirt.net">Michal.Trojnara@mirt.net</a>><br>Date: Sep 19, 2013 4:04 PM<br>Subject: Re: [stunnel-users] Hostname verification, support for, and patches<br>
To: <<a href="mailto:stunnel-users@stunnel.org">stunnel-users@stunnel.org</a>><br>Cc: <br><br type="attribution">
<div text="#000000" bgcolor="#FFFFFF">
<div>On 2013-09-12 18:20, <a href="mailto:fslama@comcast.net" target="_blank">fslama@comcast.net</a>
wrote:<br>
</div>
<blockquote type="cite">
<div style="font-size:12pt;font-family:Arial">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 type="cite">
<div style="font-size:12pt;font-family:Arial">
<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" target="_blank">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>_______________________________________________<br>
stunnel-users mailing list<br>
<a href="mailto:stunnel-users@stunnel.org">stunnel-users@stunnel.org</a><br>
<a href="https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users" target="_blank">https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users</a><br>
<br></div>