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

[Tristan Schmelcher]

On Wed, Jun 2, 2010 at 12:47 AM, Magnus Therning <
magnus+stunnel at therning.org <magnus%2Bstunnel at therning.org>> wrote:

> 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 <magnus%2Bstunnel 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.
>
>
Ah, yes that makes sense. I was going off of the behaviour of your original
patch, but I misread it (I expected to see "return" if it short-circuited
the remaining checks, so I didn't notice the "!ok" stuff). :P

In that case the optimal patch would be a combination of mine and yours. I
might see about putting that together.


> >>> 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.
>
>
Yeah, I stated it in the original email.


> /M
>
> --
> Magnus Therning                        (OpenPGP: 0xAB4DFBA4)
> magnus＠therning．org          Jabber: magnus＠therning．org
> http://therning.org/magnus         identi.ca|twitter: magthe
> _______________________________________________
> stunnel-users mailing list
> stunnel-users at mirt.net
> http://stunnel.mirt.net/mailman/listinfo/stunnel-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20100602/32e9afe1/attachment.html>