[stunnel-users] Three patches: DNS CommonName verification support, separated stderr/foreground options, and support for minimal ssl libs

Magnus Therning magnus+stunnel at therning.org
Wed Jun 2 09:47:38 CEST 2010


On Tue, Jun 1, 2010 at 19:46, Tristan Schmelcher
<tristan_schmelcher at alumni.uwaterloo.ca> wrote:
>
>
> On Tue, Jun 1, 2010 at 10:22 AM, Tristan Schmelcher
> <tristan_schmelcher at alumni.uwaterloo.ca> wrote:
>> On Tue, Jun 1, 2010 at 12:28 AM, Magnus Therning
>> <magnus+stunnel at therning.org> wrote:
[...]
>>> 2. Is there any particular reason for not including SAN in the
>>> verification as well?
>>
>> I confess that I have never heard of anything called SAN in the context of
>> SSL/TLS, and I can't find anything about it online. Do you have a link?
>>
>
> Oh, you mean SubjectAltName. I didn't implement that simply because the
> certificates that I deal with do not have DNS names for their
> SubjectAltName. I suppose it makes sense to do it, but it doesn't really add
> any security because the SubjectAltName check passes if-and-only-if it's
> equal to the CN and the CN check passes ... so it only fails if the
> certificate is nonsense.

I think you've gotten the use of SAN completely wrong.  In fact, using the CN
for the hostname is deprecated.  This is from RFC 2818:

 If a subjectAltName extension of type dNSName is present, that MUST be used
 as the identity. Otherwise, the (most specific) Common Name field in the
 Subject field of the certificate MUST be used. Although the use of the
 Common Name is existing practice, it is deprecated and Certification
 Authorities are encouraged to use the dNSName instead.

The use of SAN completements wildcards in a way.  Using only CN you are in all
practical cases limited to using wildcards, since most verifiers will only
ever consider the first CN in the cert.  Using SANs you can more easily
restrict the cert to just a subset of the names that a server is known by.

>>> 3. Are the patches released under GPL?
>>
>> No, I released them into the public domain since Michel requires that for
>> any patches that are to be incorporated into mainline stunnel.

Ah, excellent.  I probably just missed that in your original email, or in the
patches themselves.

/M

-- 
Magnus Therning                        (OpenPGP: 0xAB4DFBA4)
magnus@therning.org          Jabber: magnus@therning.org
http://therning.org/magnus         identi.ca|twitter: magthe



More information about the stunnel-users mailing list