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/