<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>