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
signature.asc
Description: OpenPGP digital signature
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
