[jdev] Why STARTTLS? [was: IMPORTANT www.jabber.org software listings]

[Jefferson Ogata]

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 <Jefferson.Ogata at noaa.gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt at noaa.gov>
"Never try to retrieve anything from a bear."--National Park Service