[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