<br><br><div class="gmail_quote">On Wed, Jun 2, 2010 at 12:47 AM, Magnus Therning <span dir="ltr"><<a href="mailto:magnus%2Bstunnel@therning.org">magnus+stunnel@therning.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On Tue, Jun 1, 2010 at 19:46, Tristan Schmelcher<br>
<div class="im"><<a href="mailto:tristan_schmelcher@alumni.uwaterloo.ca">tristan_schmelcher@alumni.uwaterloo.ca</a>> wrote:<br>
><br>
><br>
> On Tue, Jun 1, 2010 at 10:22 AM, Tristan Schmelcher<br>
> <<a href="mailto:tristan_schmelcher@alumni.uwaterloo.ca">tristan_schmelcher@alumni.uwaterloo.ca</a>> wrote:<br>
>> On Tue, Jun 1, 2010 at 12:28 AM, Magnus Therning<br>
>> <<a href="mailto:magnus%2Bstunnel@therning.org">magnus+stunnel@therning.org</a>> wrote:<br>
</div>[...]<br>
<div class="im">>>> 2. Is there any particular reason for not including SAN in the<br>
>>> verification as well?<br>
>><br>
>> I confess that I have never heard of anything called SAN in the context of<br>
>> SSL/TLS, and I can't find anything about it online. Do you have a link?<br>
>><br>
><br>
> Oh, you mean SubjectAltName. I didn't implement that simply because the<br>
> certificates that I deal with do not have DNS names for their<br>
> SubjectAltName. I suppose it makes sense to do it, but it doesn't really add<br>
> any security because the SubjectAltName check passes if-and-only-if it's<br>
> equal to the CN and the CN check passes ... so it only fails if the<br>
> certificate is nonsense.<br>
<br>
</div>I think you've gotten the use of SAN completely wrong. In fact, using the CN<br>
for the hostname is deprecated. This is from RFC 2818:<br>
<br>
If a subjectAltName extension of type dNSName is present, that MUST be used<br>
as the identity. Otherwise, the (most specific) Common Name field in the<br>
Subject field of the certificate MUST be used. Although the use of the<br>
Common Name is existing practice, it is deprecated and Certification<br>
Authorities are encouraged to use the dNSName instead.<br>
<br>
The use of SAN completements wildcards in a way. Using only CN you are in all<br>
practical cases limited to using wildcards, since most verifiers will only<br>
ever consider the first CN in the cert. Using SANs you can more easily<br>
restrict the cert to just a subset of the names that a server is known by.<br>
<div class="im"><br></div></blockquote><div><br></div><div>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</div>
<div><br></div><div>In that case the optimal patch would be a combination of mine and yours. I might see about putting that together.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">
>>> 3. Are the patches released under GPL?<br>
>><br>
>> No, I released them into the public domain since Michel requires that for<br>
>> any patches that are to be incorporated into mainline stunnel.<br>
<br>
</div>Ah, excellent. I probably just missed that in your original email, or in the<br>
patches themselves.<br>
<div class="im"><br></div></blockquote><div><br></div><div>Yeah, I stated it in the original email.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">
/M<br>
<br>
--<br>
Magnus Therning (OpenPGP: 0xAB4DFBA4)<br>
magnus@therning.org Jabber: magnus@therning.org<br>
<a href="http://therning.org/magnus" target="_blank">http://therning.org/magnus</a> <a href="http://identi.ca" target="_blank">identi.ca</a>|twitter: magthe<br>
</div>_______________________________________________<br>
stunnel-users mailing list<br>
<a href="mailto:stunnel-users@mirt.net">stunnel-users@mirt.net</a><br>
<a href="http://stunnel.mirt.net/mailman/listinfo/stunnel-users" target="_blank">http://stunnel.mirt.net/mailman/listinfo/stunnel-users</a><br>
</blockquote></div><br>