Openfire 是否支持 TLS Over Http-Bind?如果不是,还有什么选择
我提前为这个问题的冗长表示歉意,但我觉得我需要提供一些额外的信息才能正确地描述我当前的困境。
背景
好吧,从很多方面来说,这个问题都是我问的上一个问题是关于 XMPP 通信的 TLS/SSL 加密以及哪些库是最好的。 起初,我只选择使用 .net 库使用 TLS/SSL,但后来扩展到包含 Java 库,这也是一个合适的替代方案,并且还尝试了 Smack API 的简单实现。在对 TLS/SSL 加密进行详尽(且很大程度上是误导性的)研究之后,我意识到,当 Openfire 正确配置为阻止非安全连接时,大多数 XMPP 客户端在连接到 Openfire 时将简单地自动协商 TLS 加密通信,并且只要我控制服务器端的用户名册(即禁用用户从任何客户端创建新帐户的能力),我或多或少可以通过 Openfire 创建安全的端到端 XMPP 协作。
新问题
解决了之前的问题后,我尝试使用此方法通过 Openfire 的 HTTP 绑定功能和端口通过 HTTP 绑定进行安全通信。原因是我们的实施将要求用户从其他网络连接到我们的 Openfire 服务器。此外,也许很明显,我们无法控制如何配置这些用户防火墙以允许通过端口 5222 进行传出套接字连接,更重要的是,由于我们正在实现的系统的性质,我们的任何客户端都不太可能会这样做愿意/允许打开他们的防火墙来建立到我们的 XMPP 服务器的套接字连接。
该问题是由于 Openfire 的 Http-Bind 似乎不支持自动 TLS,而是仅支持(如 Openfire 所说)“旧 SSL”加密方法。 这个和其他 Openfire Socket vs Http 在另一个问题中讨论过,尽管不是但很长
问题(最后)
首先,任何人都可以确认 实际上是通过Openfire进行Http-Bind 不支持自动 TLS?
二、Smack API是否支持 HTTP 绑定?有一个现有 Ignite Realtime 上的票证 网站似乎表明它 但不支持票证 成立于 2007 年,也是最后一个 2011 年 6 月的评论询问是否 对此进行了任何更新 功能尚未消失 无人应答。
第三,这似乎是我的最后一次 采取安全措施 使用 Openfire 进行通信和 Http-bind 将使用“旧” SSL' 方法但这并不 似乎是一个很好的长期解决方案。 此外,Openfire 论坛和其他 各种谣言工厂都表明 SSL 功能将是 未来 Openfire 中已弃用 发布(任何人都可以相信 这个谣言)。所说的一切都是 SSL 我唯一真正的替代方案 使用 Http-bind 进行安全连接。
I apologize in advance for the somewhat long windedness of this question but I feel that I need to provide some additional information in order to properly qualify my current predicament.
Background
Okay so in many ways this question is a follow up to a previous question I asked regarding TLS/SSL encryption for XMPP communication and which libraries were the best. At first I resigned myself to using only .net libraries that used TLS/SSL but have since expanded to include Java libraries as also being a suitable alternative and have attempted a simple implementation of the Smack API as well. After exhaustive (and largely misguided) research regarding TLS/SSL encryption I realized that when Openfire is properly configured to block non-secure connections, most XMPP clients when connecting to Openfire will simply auto-negotiated TLS encrypted communications and that as long as I controlled the user roster on the server side (i.e. disable users abilities to create new accounts from any client) that I could more or less create secure end-to-end XMPP collaboration through Openfire.
The New Problem
Once I got the previous issues settled, I attempted to use this method for secure communication over HTTP-binding via Openfire's HTTP-binding functionality and ports. The reason for this is because our implementation will require users to connect to our Openfire server from additional networks. Additionally, and perhaps obviously, we will have no control over how these users firewalls will be configured to allow outgoing socket connections over port 5222 and whats more due to the nature of the system we are implementing it is highly unlikely that any of our clients will be willing/allowed to open their firewall to establish a socket connection to our XMPP server.
The issue is due to the fact that Openfire's Http-Bind does not appear to support auto TLS and instead only supports (as Openfire puts it) the 'Old SSL' method of encryption. This and other Openfire Socket vs Http are discussed in another question here, although not yet at great length
The Question (Finally)
First, can anyone confirm that
Http-Bind through Openfire actually
does not support auto TLS?Second, does the Smack API support
Http-Bind? There is an existing
ticket on Ignite realtime's
website that seems to state that it
is not supported however the ticket
was created in 2007 and its last
comment from June 2011 that asks if
any update has been made on this
feature has as of yet gone
unanswered.Third, it seems as though my last
resort to achieve secure
communication using Openfire and
Http-bind would be to use the 'Old
SSL' method however this does not
seem like a good long term solution.
Also, the Openfire forums and other
various rumor mills have indicated
that SSL functionality will be
deprecated in future Openfire
releases (can anyone give credence to
this rumor). All that being said, is
SSL my only real alternative to
secure connection using Http-bind.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
默认情况下,Openfire 会打开两个端口用于基于 HTTP 绑定 (BOSH) 的连接。一种是纯文本端口 (7080),一种是 TLS/SSL 加密端口 (7483)。这很像用于常规套接字连接的两个端口 (5222,5223)。
通过非 HTTP、常规套接字端口 (5222) 连接的客户端可以将最初的纯文本通道提升为加密通道(使用 STARTTLS)。当 STARTTLS 被引入时(回到……好吧,那时我还没有孩子),预先存在的 TLS/SSL 加密端口 (5223) 被称为“旧”加密方式。也许有些过于热心,有人提出了一些建议,放弃“旧”技术,转而采用“新”技术。
STARTTLS 尚未显式添加到 HTTP 绑定 (BOSH) 实现的“纯文本”端口 (7080)。这是设计使然。与端口 5222 上的“普通套接字”连接不同,BOSH 使用传输协议:HTTP。 BOSH 的通道加密应在 HTTP(传输)层(端口 7483)完成,而不是在 XMPP(应用程序)层(这会转换回基于非 HTTP 的事物世界中的“旧”处理方式)。顺便说一句,这不是特定于 Openfire 的:它是由 BOSH 协议。
至于弃用基于“旧”SSL 的端口:(Openfire 开发人员之间)的普遍共识是删除“旧”SSL 端口没有意义:尽管该技术有些过时,但它的安全性并不比更现代的技术低。 (STARTTLS)技术。最重要的是,关于删除“旧”SSL 端口的讨论面向非基于 HTTP 的连接(客户端、服务器到服务器、外部组件等的套接字连接)。最后,关于是否更改 BOSH 的默认端口编号的类似但不同的讨论在某种程度上扭曲了该讨论(Openfire 使用 7080/7483 早于标准 BOSH 端口编号的定义)。
由于按照设计,BOSH 实现旨在利用 HTTP 提供的加密,因此其加密端口将继续存在。
至于 Smack-supporting-BOSH 问题:Smack 支持: https://www.igniterealtime.org/builds/smack/docs/latest/javadoc/org/jivesoftware/smack/bosh/XMPPBOSHConnection.html
By default, Openfire opens two ports for HTTP-Binding (BOSH) based connectivity. One is a plain-text port (7080), one is a TLS/SSL-encrypted port (7483). This is much like the two ports used for regular socket connections (5222,5223).
Clients connecting over the non-HTTP, regular socket port (5222) can elevating the initially plain-text channels to encrypted channels (using STARTTLS). When STARTTLS was introduced (back in ... well, I didn't have kids then) the pre-existing, TLS/SSL-encrypted port (5223) got referred to as the 'old' way of doing encryption. Somewhat overzealous perhaps, some suggestions were made to drop the 'old' technique in favor of the 'new' one.
STARTTLS has not been explicitly added to the 'plain text' port (7080) of the HTTP Binding (BOSH) implementation. This is by design. Unlike the 'plain socket' connectivity on port 5222, BOSH makes use of a transport protocol: HTTP. Channel encryption for BOSH should be completed at the HTTP (transport) layer (port 7483), not the XMPP (application) layer (that translates back to the 'old' way of doing things in the non-HTTP based world of things). This is not Openfire-specific, by the way: it's specified by the BOSH protocol.
As for the deprecation of the 'old' SSL based ports: the general consensus (between Openfire developers) is that there's no point in removing the 'old' SSL port: although the technique is somewhat outdated, it's not less secure than the more modern (STARTTLS) technique. On top of that, the discussion to drop 'old' SSL ports is oriented towards the non-HTTP based connectivity (socket connections for clients, server-to-server, external components, etc). And finally, the discussion is somewhat distorted by a similar yet distinct discussion on whether to change the default port numbering for BOSH (Openfire usage of 7080/7483 predates the definition of standard BOSH port numbering).
As, by design, the BOSH implementation is intended to utilize HTTP-provided encryption, its encrypted port will continue to exist.
As for the Smack-supporting-BOSH question: Smack supports that: https://www.igniterealtime.org/builds/smack/docs/latest/javadoc/org/jivesoftware/smack/bosh/XMPPBOSHConnection.html