On 2006-07-06 22:34, Peter Saint-Andre wrote: > Jefferson Ogata wrote: >>> On 07/06/2006 06:21 PM, Tomasz Sterna wrote: >>>> On 7/4/06, Norman Rasmussen <[EMAIL PROTECTED]> wrote: >>>>> Most jabber servers seem to give up and _not_ do the dns cascade, but >>>>> Wildfire seems to do the cascade DNS, generating lots of 'Failed to >>>>> lookup .de', or 'Failed to lookup .org' records in the log files. >>>> So you say if I'm hosting your parent domain I could take-over and >>>> spoof your non-functioning (DDoS'ed) XMPP server? Sending SPIM, >>>> harvesting password. Possibilities are endless. Great, just great. >>> Given jabber clients' genearlly poor support of SSL/TLS certificate >>> verification (kudos to Psi for doing it right), resistance to DNS-based >>> attacks seems like a definite non-priority for the jabber community. > > RFC 3920 says how to properly handle certificates. Unfortunately, server > certificates are not widespread yet (let alone client certificates). But > I'm working to change that...
Indeed I think the RFC is pretty much on target in its SSL/TLS specification. My criticism above is that clients have failed to follow the RFC. There are in fact many servers using self-signed certificates but that accomplishes very little when clients don't even bother to warn users about bad certificate chains. In a way, the current focus on getting server certificates signed by a CA is a red herring; it doesn't matter so much if they're self-signed AS LONG AS the client WARNS the user that the cert can't be verified. After all, the user can import a self-signed certificate into his or her local trust database at first use and at least be alerted when the certificate CHANGES, indicating an attack either now or at the time of import. This is not an uncommon protocol--just look at SSH host key handling. I do have a concern about the RFC, in the details of cn matching performed when SRV records are involved. While clearly you do the right thing in ignoring the hostname returned in an SRV record for purposes of cn matching, the defined approach imposes a problematic constraint on servers: if I want to offer a certificate for users @example.com, I must use a certificate for "example.com". Because the cn of this certificate is the domain root, if stolen it could be used to spoof other services for the domain root itself. Meanwhile, since jabber servers are a new breed, there remains a great deal of unaudited server code. The prospect of having a certificate for my domain root running in an unaudited piece of server software exposed to the world is one I do not relish. An alternative might have been to match the cn against the same name used in the successful SRV query (the query, not the result). So if for example the successful SRV query was for _xmpp-server._tcp.example.com, the certificate cn could have that same name, in addition to example.com. This would allow use of server certs that don't have as much value to an attacker if compromised. I'm not certain exactly what the best approach would be, but the status quo is not ideal in my view. -- Jefferson Ogata <[EMAIL PROTECTED]> NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]> "Never try to retrieve anything from a bear."--National Park Service
