[Dev] IMAP and SMTP over SSL secure - finally

[Heikki Toivonen]

RL 'Bob' Morgan wrote:
> Heikki Toivonen wrote:
>
>> I just enabled the final piece in the SSL support for IMAP and SSL. We
>> now check the X.509 certificate that was returned by the server and make
>> sure that the host it was issued to is the same host we connected to.
>
> Just to make sure:  the name that your client should be comparing with
> (ie, the one it has, as opposed to one of the names it finds in the
> cert) is the name "as entered by the user" or otherwise obtained by the

Yes, that is what I believe is implemented right now. That's one thing
that we need to either devise a test for and/or confirm this in an audit.

> Also, in terms of what's in the cert, it's important to provide support
> for getting the name from the subjectAltName field as well as the more

Yes, there's support for that already. Only one subjectAltName is
supported at the moment, though (several could be specified in the
certificate).

> usual (but unfortunately entirely bogus from a spec point of view)
> CN-in-the-Subject-DN.  Also worth noting that behavior is undefined if
> there happens to be more than one CN RDN in the Subject DN; probably the
> right thing to do is to check against the last one in the sequence.

I've heard some others checking only first one in case it is unclear
what to do.

> I would avoid doing a case-sensitive check, it can only lead to
> mysterious problems.  That said, I have no idea how IDN affects this

You mean upper/lowercasing string before comparison could produce
different results? The only character that I know of with this problem
is the Turkish I (I don't remember the exact rules, but going from lower
case i to upper case I and back will get you different letter than going
from upper case I to lower and back - or something like that). Anyway,
as far as I understand the spec does require case insensitive
comparison, so that is what is now implemented (first converted to lower
case, then compared).

> practice, I'm sure the right thing in the long run is to do an
> octet-string match, but in the meantime I don't think we want to have to
> figure out failure cases where the user entered "Foo.Bar.Edu" as the
> hostname for some reason.

IDN is a whole can of worms that I haven't paid any attention to yet. I
don't know when IDN support is even in the plans for Chandler (for
example Internet Explorer does not support IDN although there is a
plugin from Verisign that enables them for IE).

IDN causes security problems in browsers, see
http://www.shmoo.com/idn/homograph.txt. Some are of the opinion that the
problem is not in browsers but organizations that give out domain names
and certificates (they should not give out names that can be used to
spoof users).

> But what I really want to write about is the multiple host thing.
> Unfortunately wildcard behavior is also not well-standardized, but it is
> also common practice.  At our site we depend on the ability to tell
> users to configure their clients to go to
> <username>.mailserver.washington.edu, have DNS resolve to the address of
> their mailserver, have all the servers use a *.mailserver.washington.edu
> cert, and have clients accept that as matching their user-entered
> service name.  As far as I know this works with all IMAP clients we've
> tried (some of which has required complaints to vendors in the past).
>
> I suspect that code varies a lot on exactly which wildcard forms are
> supported ( *.foo.bar.com, *foo.bar.com, *.*.bar.com, etc), and I don't
> believe there's a single written-down spec to follow, but I believe that
> at least the *.foo.bar.com style is widely supported and widely used.

I understood from the specs that * can match to the nearest
beginning/end of line and/or dot. So m*.example.com would match
my.example.com for example. What was not clear to me is if multiple
asterisks are allowed. Right now Chandler supports one asterisk that is
matched as I explained above (and works with all your samples as well
except the one with two asterisks).

--
   Heikki Toivonen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://lists.osafoundation.org/pipermail/dev/attachments/20050211/1e79f746/signature.bin