<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body 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; color: #000000">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; color: #000000">
<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>
</body>
</html>