On Sun, 25 Sep 2005 01:58:35 +0200, Matt Tucker <[EMAIL PROTECTED]>
wrote:
Tjil,
I did that in my first reply, the other problem I pointed out
was in my last reply; Instead of having to steal the DNS
record you can "steal" one that's hardly used or doesn't even
exist. This gives attacks a lot more "stealth".
Are you playing devil's advocate or are you serious? If I had to guess,
I'd say that 99.9% of public XMPP servers are deployed at [domain].com
or [sub].[domain].com. They're not deployed at
[sub].[sub].[sub].[domain].com. This means that there are generally
never "unused" or "hardly used" domains up the tree from any particular
XMPP server that somebody could stealthily take over.
So basically what you're saying is.. you want to solve your problem
(people not able to get a decent (sub)domain), and replace it with the
problem that people can't use, for example jabber.im.example.org
So what if that's 0.1% ? Or 0.01%? What if 0.01% of all users of Firefox
suffer from a buffer overflow. Does that mean you don't fix it?
What I'd love to see is that people generally agree that this algorithm:
* Is a miniscule security risk beyond standard dial-back. If you can't
trust your DNS tree, you can't trust dial-back.
It is a "very high" security risk, because the consequences are very
serious, for the people who are exposed to the risk. Don't compare it with
the security risk associated with Dailback, because, as the examples
givven to you show, that is not true.
The problem I think is, you speak of a "DNS tree". In practise, the DNS
tree exists only 2 levels deep
(subdomains_containing_as_many_dots_as_you_want.domainname.top). You're
algoritim assumes differently. So if you have a server at example.org, and
you want conference.example.org to work without having a record, you can
do this safely. However, the person at jabber.example.org still isn't
safe, and doesn't have any control over his situation. Basically he's at
the mercy of whoever owns example.org. Of course he is too, right now, but
right now the owner of example.org would have to mess with
jabber.example.org itself, to do nasty things. With your hack, that is no
longer needed.
So when all server run on domain.top, we're safe to use your hack.
However, that's usually the people who ARE in the position to make
subdomains.
* Is a reasonable workaround given today's environment.
* Is a hack that it would be great to get rid of if a better
alternative can be thought of.
Security compromising hacks are rarely a "reasonably workaround" in an
open enviroment like the internet. It's better to use one of the mentioned
solutions; running everything on the same domain or getting some free
subdomains from one of the many providers that do this.
If it's not the general community consensus that the above is true,
we'll disable the algorithm by default.
While requiring a signed certificate is a step up, it is only
a small step it. It are still unknown servers you are talking
to, thus unknown certificates.
That's the point of a CA. If a CA signs a cert, that means you should
trust it.
That is a very basic security misunderstanding. CA's do not provide
security, they provide acountability.
Example: If you get a popup in your browser, which basically sais: "This
website wants to run some code locally on your computer." and a friendly
box from your browser telling you it's signed with a VeriSign certificate
from UnknownCompany, does that mean you trust this? By default? Without
even looking??? Not even IE at the height of it's insecurity would do this
(not even MS code!).
Compare it to giving sensitive information to a person. To make it more
safe, you might ask them for a passport first. Does that protect the
information you give them? Of course not. They can still tell it to the
next person they see. But you can check if they are who they claim they
are to you, and thus hold them accountable. You can do that by looking at
the accountability data on the passport (eg. the name, sex, height) by
matching this by what you already know and what you can see. Next, you
have to trust the issuer of this passport; the goverment ("the CA"). If
you're smart you look at the safety measures they build in (watermarkings,
etc.), maybe you even call them up to check a serial number or something
on the passport.
What you're doing with with dailback/sasl is just looking wether they
*have* a passport, and if it's a real passport (well, trust the CA on
that). You don't check if it's *their* passport, or even if the passport
you're seeing is the passport they tried to show you. And then, just
because they *have* one, you think it's safe to tell them sensitive
information.
No security is perfect, but the CA system is the bedrock of
internet security.
For encrypting your data.
Not for trust. The CA system isn't a magic sandbox that makes everything
safe. If I send my creditcard data over a CA signed SSL connection, that
doesn't make whatever happens on the other end of that encrypted pipe any
safer. I should still look at the certificate, the name/address of the
company/person, and say, "Yes, this is the company/person that I know, and
I trust them, not cause of some crazy certificate, but because I know and
I trust them enough that they won't fuck up their security and have my
creditcard details or their certificate stolen."
THAT, and trusting the CAs themself(!!), it the current "bedrock" of
internet security. It's not at all what you propose. What you propose with
dailback/SASL is "hey buddy, you're smart enough to buy or steal this
certificate somewhere from a CA I like, so I'm gonna treat like I can
trust you a lot more then those *ordinary* dailback users". You'll have
the benefit of encryption, sure.. so people not involded witht the two of
you will have a harder time. But that server on the other end still has
the benifit of decryption ;) I wouldn't TRUST them any more than an
ordinary dailback server.
What certificates *can* be used for, is as a stepping stone to develop
more eleborate security/trust systems. When it comes to malicious attacks
from another server, they offer no real advantage over not using them at
all. Well, other than that the entire attack can now be encrypted ;)
(though man in the middle attacks can still be done, of course!)
I don't particularly like how the CA system works,
but that's another issue.
No matter how bad you want a feature, compromising security
is not the right answer.
I disagree. Nothing is a black and white issue -- features always have
to be weighed against security. Many people won't go sky diving, but
most feel reasonably safe driving a car despite the fact that tens of
thousands die each year in car wrecks. For ultimate safety, s2s should
just be disabled. :)
In our opinion, our DNS algorithm isn't a
significant risk beyond what you get with standard dial-back and is a
virtually non-existent risk if you do decide to require CA certs for s2s
connections.
Well, no matter how you twist and turn, that's simply not true. What's
true is that the "edge" cases where, you'll have to admit, the risk is
very significant indeed, are deemed irrelevent by you (in other words:
fuck you, edge cases). The worst thing is they can't possibly defend
themselves from this "Jive attack", because even if they don't run it
themselves, they are still vonurable, the flaw is on your side, not
theirs. As for your second statement, I hope you learned enough about
internet security today to recognize that as bullshit.
