After scouring the net I've found several isolated discussions regarding stunnel hostname validation. And also some patches that seem to implement hostname validation:
https://www.stunnel.org/pipermail/stunnel-users/2010-March/002613.html
I have a requirement to have stunnel (4.56) validate client certificates and their identity by comparing the its CNAME against the source address.
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?
Are there sanctioned patches out there today?
Regards, -Fred
On 2013-09-12 18:20, fslama@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
Hi Mike,
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). 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. 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.
It looks like your comment (#2) explains the problem with this approach. "Comparing CNAME/SubjectAltName against client's IP address or FQDN would be pointless from security perspective, as both are spoofable."
This statement is predicated on the DNS being tampered with, correct? In our scenario it is unlikely that DNS would be tampered with -- of course, nothing is 100% guaranteed.
Thoughts?
I'll take a look at the link you suggested.
Regards, -Fred
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. PPS> Kudos on a well implemented tool.
On Sep 19, 2013, at 4:04 PM, Michal Trojnara Michal.Trojnara@mirt.net wrote:
On 2013-09-12 18:20, fslama@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:
- FQDN verification was introduced to check whether the web site the browser connected to is indeed the web site intended by the browser.
- 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.
- 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.
- 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@stunnel.org https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
This is the latest traffic on DNS..may be helpful ---------- Forwarded message ---------- From: "Michal Trojnara" Michal.Trojnara@mirt.net Date: Sep 19, 2013 4:04 PM Subject: Re: [stunnel-users] Hostname verification, support for, and patches To: stunnel-users@stunnel.org Cc:
On 2013-09-12 18:20, fslama@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@stunnel.org https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
-
Brian Wilkins -
Frederick Slama -
fslama＠comcast.net
-
Michal Trojnara