Re: [jdev] s2s lookup cascades
On Tuesday 04 July 2006 05:21, Norman Rasmussen 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. Definitely don't cascade. Wildfire does it so people can have jabber subdomains without modifying the DNS, but all this does is break the network for non-Wildfire users. -Justin
Re: [jdev] s2s lookup cascades
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. :-D -- smk
Re: [jdev] s2s lookup cascades
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. -- Jefferson Ogata <[EMAIL PROTECTED]> NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]> "Never try to retrieve anything from a bear."--National Park Service
Re: [jdev] s2s lookup cascades
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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... Peter - -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFErZAONF1RSzyt3NURAglYAJ9UzRal8Ey7k3x94RxleuZbRhmqsgCeOwLO hNQvEBC8kdbxl+Ll4RVx+Qo= =EHub -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature
Re: [jdev] s2s lookup cascades
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
Re: [jdev] s2s lookup cascades
Jefferson Ogata wrote: > 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. I have two issues with this paragraph: The first/obvious one is probably nitpicking anyway, but I'd really like to hear what you call "new breed". http://www.xmpp.org/history.html claims, that jabberd was 1.0 in 2000, which is not that new to me. But as I said, this might be nitpicking. A completely different question comes to my mind when you talk about the certificate: Even if your certificate for the CN example.com would be stolen, what exactly is your connection to other services here? Each service could imo use a different certificate - if you want that. And all your clients should notice a change of a certificate anyway? Pondering, Ben
Re: [jdev] s2s lookup cascades
On 07/12/2006 06:02 AM, Benjamin Podszun wrote: > Jefferson Ogata wrote: >> 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. > > I have two issues with this paragraph: The first/obvious one is probably > nitpicking anyway, but I'd really like to hear what you call "new > breed". http://www.xmpp.org/history.html claims, that jabberd was 1.0 in > 2000, which is not that new to me. But as I said, this might be nitpicking. I'm aware that XMPP has history; I still, however, consider a 2000 1.0 release new. And my strong impression is that there has been very little investigation of security vulnerabilities in XMPP implementations, which is the principle concern. Newness is not the whole story--just look at Sendmail for an example of a program that is about as old as anything in current use, yet another significant vulnerability was disclosed within recent months. Contrast, for example, the audit history of any of the popular jabber servers with that of, say, Apache. Not only are there typically many, many more eyes on Apache, Apache has also been the subject of a great deal of rigorous auditing. So I agree that "new" is a subjective characterization, but I hope you see my point. > A completely different question comes to my mind when you talk about the > certificate: Even if your certificate for the CN example.com would be > stolen, what exactly is your connection to other services here? Each > service could imo use a different certificate - if you want that. And > all your clients should notice a change of a certificate anyway? If the private key for a valid certificate for example.com is stolen, an attacker can use it to spoof any service for example.com. It doesn't matter if you use different certificates for other services. The only thing encoded in the certificate cn is the domain name. (There are usage constraints on certificates that may differentiate SSL server certificates from personal client certificates, for example, but nothing that specifies valid services.) In fact, if you do buy different certificates for different services, you're just throwing money away--a certificate for example.com is valid for any service found at that address. -- Jefferson Ogata <[EMAIL PROTECTED]> NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]> "Never try to retrieve anything from a bear."--National Park Service
