On 2008-02-25 15:50, Tomasz Sterna wrote:
Dnia 2008-02-25, Pn o godzinie 15:13 +0000, Jefferson Ogata pisze:
That reminds me: I've been wondering why Jabber folks have been
encouraging STARTTLS? In general, STARTTLS has the flaw of allowing
misconfigured clients (of any protocol) to transmit credentials in
the
clear; people who want to ensure clients are not exposing credentials
are safer with an SSL wrapper. Meanwhile, as Peter points out,
STARTTLS
makes it harder to test services.
If you configure your server to not offer plaintext authentication
methods over an unencrypted channel, there is no way that properly
written client would transmit credentials in the clear.
Note that there are two caveats involved in your scenario: properly
configured server, and correctly implemented client. SSL is much more
bulletproof in that regard.
What advantage does STARTTLS provide to offset these annoyances?
You know which domain client is connecting, so you may present a correct
certificate with TLS.
How, exactly, do you know? I.e. what specific prenegotiation informs the
XMPP server which domain certificate to use? Traditional STARTTLS (e.g.
in ESMTP and LDAP), AFAIK, has no such provision; this would have to be
an XMPP-specific augmentation.
And how useful is this? The traditional place where polymorphic
certificates have been desired is in HTTP servers, where running
multiple SSL services requires an IP for each. Do people actually do
this with XMPP as well? Often?
In SSL you are encrypting the channel before the stream opening.
Which is why it's better, the only drawback being that you have to
dedicate an IP to each certificate. In most cases, this is not a hardship.
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
"Never try to retrieve anything from a bear."--National Park Service
