Peter Saint-Andre wrote:
Does anyone have further thoughts on the use of TLS?

Peter Saint-Andre wrote:
Forwarding an older message from the [EMAIL PROTECTED] list...


-------- Original Message --------
Date:     Tue, 13 Feb 2007 14:40:43 -0800
From:     Steve Shaffer <[EMAIL PROTECTED]>
To:     [EMAIL PROTECTED]
Subject:     [Standards] XEP 0124 section 9?

[...]
Item 3)
I'd also suggest t the connection manager SHOULD reject https connection
requests if the connection manager can not establish a secure connection
to the server.  Otherwise the browser based connections may appear to be
secure even when the XML stanzas are passed in the clear between the
connection manager and the server.
[...]
Isn't this already partially covered by the 'secure' attribute in init request?

from XEP-0124:
>>>
A client MAY include a 'secure' attribute to specify that communications between the connection manager and the server must be "secure". (Note: The 'secure' attribute is of type xs:boolean (see XML Schema Part 2 [16]) and the default value is "false". [17]) If a connection manager receives a session request with the 'secure' attribute set to "true" or "1", then it MUST respond to the client with a remote-connection-failed error as soon as it determines that it cannot communicate in a secure way with the server. A connection manager SHOULD consider communications with the server to be "secure" if they are encrypted using SSL or TLS with verified certificates, or if it is running on the same physical machine as the server. A connection manager MAY consider communications over a "private" network to be secure, even without SSL or TLS; however, a network SHOULD be considered "private" only if the administrator of the connection manager is sure that unknown individuals or processes do not have access to the network (i.e., individuals or processes who do not have access to either the connection manager or the server). The connection manager SHOULD try to establish a secure connection with the server even if the client does not specifically require it.
>>>

i.e. if client sets 'secure' to true and CM can't estabilish connection in a secure way, CM will respond with remote-connection-failed in init response.

Then maybe sth like

If client is using TLS in connection to CM, then it MUST set the secure attribute to true.

would eliminate the possibility of having TLS between client and CM and plain connection between CM and XMPP sever.

tomk

--
Tomas Karasek

jabber: tom.to.the.k at jabber.cz
GSoC blog: http://tomk-soc08.blogspot.com/

Reply via email to