[sorry for broken address in previous version, trying new mail client 8^)]
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 client in the context of "the hostname of the site the user wants to connect to". You shouldn't be doing anything like following DNS-provided CNAME chains to come up with the name.
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 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.
The actual check is stricter than is actually specified in the RFC. I will change it to confirm to the spec, but I would also be interested in finding out if there actually are any certificates out there that would not pass the current check. Specifically, the current checks are stricter because: 1) they are case sensitive, 2) they don't allow certificates specified for multiple hosts. I don't really like how I implemented this whole validation step so I will redo a part of it anyway.
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 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.
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.
- RL "Bob"
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
