Re: [Standards] XEP-0156 _xmppconnect is vulnerable to MITM

[JC Brand]

On February 11, 2022 3:48:47 AM GMT+01:00, Peter Saint-Andre 
 wrote:
 
>  but that raises the issue of whether we should still 
>recommend BOSH, since it was a pre-websockets workaround for long polling.

The Peertube webchat plugin uses BOSH because IIRC it has to run in an iframe 
and can therefore not use a websocket (I assume due to XSS restrictions).

Just mentioning this to highlight the fact that there are still apparently 
legitimate usecases for BOSH.

https://github.com/JohnXLivingston/peertube-plugin-livechat
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0156 _xmppconnect is vulnerable to MITM

[Travis Burtrum]

Hi all,

I went ahead and removed the DNS method from XEP-0156 instead, and 
updated the security considerations and business rules to explain that 
TLS should always be used and what to send in SNI and what to look for 
in the certificates.


Please let me know if anyone has concerns with this.

Thanks much,
Travis

On 2/13/22 15:52, Sonny Piers wrote:
Thanks you Travis for taking the time to make individual reports for 
each implementations. I fixed it in xmpp.js 0.13.1 .


If that works for everybody - I'm happy to remove BOSH / and XEP-0156 
from XMPP Compliance Suites 2022.


If someone disagree please come up with a different solution than 
obsoleting XEP-0156 all together .
BOSH without an endpoint discovery mechanism doesn't make sense in a 
compliance suite.



On jeu., févr. 10 2022 at 19:48:47 -0700, Peter Saint-Andre 
 wrote:
Co-author of XEP-0156 here. Thanks for raising this issue. I would go 
even farther and note that DNS TXT records were never a great idea for 
this functionality (they're actively discouraged in the DNS community 
for application-level uses like this). On 2/9/22 4:29 PM, Travis 
Burtrum wrote:


Hi all, The long story short (is outside of DNSSEC) it's
impossible to use _xmppconnect TXT records to securely connect to
BOSH or WebSockets. Every client I've been able to find that
supported this is vulnerable to trivial MITM (Man-In-The-Middle)
via DNS spoofing.  If you have a client that uses it, switch to
grabbing host-meta via HTTPS per [RFC-7395] immediately, maybe
grab a CVE if you wish. 

Sonny commented on your PR that "RFC 7395 doesn't define bosh 
lookups"; this might be true but that raises the issue of whether we 
should still recommend BOSH, since it was a pre-websockets workaround 
for long polling.


I propose we litter [XEP-0156] with warnings explaining why it's
insecure and should never be done, and obsolete it, instead
referring people to the single host-meta method that [RFC-7395]
defines, which provides secure delegation when grabbed over HTTPS. 

In general, +1 to what you propose. Peter 
___ Standards mailing list 
Info: https://mail.jabber.org/mailman/listinfo/standards 
 Unsubscribe: 
standards-unsubscr...@xmpp.org  
___ 


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0156 _xmppconnect is vulnerable to MITM

[Sonny Piers]

Thanks you Travis for taking the time to make individual reports for 
each implementations. I fixed it in xmpp.js 0.13.1 .


If that works for everybody - I'm happy to remove BOSH / and XEP-0156 
from XMPP Compliance Suites 2022.


If someone disagree please come up with a different solution than 
obsoleting XEP-0156 all together .
BOSH without an endpoint discovery mechanism doesn't make sense in a 
compliance suite.



On jeu., févr. 10 2022 at 19:48:47 -0700, Peter Saint-Andre 
 wrote:

Co-author of XEP-0156 here.

Thanks for raising this issue.

I would go even farther and note that DNS TXT records were never a 
great idea for this functionality (they're actively discouraged in 
the DNS community for application-level uses like this).


On 2/9/22 4:29 PM, Travis Burtrum wrote:

Hi all,

The long story short (is outside of DNSSEC) it's impossible to use 
_xmppconnect TXT records to securely connect to BOSH or WebSockets. 
Every client I've been able to find that supported this is 
vulnerable to trivial MITM (Man-In-The-Middle) via DNS spoofing.  
If you have a client that uses it, switch to grabbing host-meta via 
HTTPS per [RFC-7395] immediately, maybe grab a CVE if you wish.


Sonny commented on your PR that "RFC 7395 doesn't define bosh 
lookups"; this might be true but that raises the issue of whether we 
should still recommend BOSH, since it was a pre-websockets workaround 
for long polling.


I propose we litter [XEP-0156] with warnings explaining why it's 
insecure and should never be done, and obsolete it, instead 
referring people to the single host-meta method that [RFC-7395] 
defines, which provides secure delegation when grabbed over HTTPS.


In general, +1 to what you propose.

Peter
___
Standards mailing list
Info: 
Unsubscribe: standards-unsubscr...@xmpp.org 


___


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0156 _xmppconnect is vulnerable to MITM

[Peter Saint-Andre]

Co-author of XEP-0156 here.

Thanks for raising this issue.

I would go even farther and note that DNS TXT records were never a great 
idea for this functionality (they're actively discouraged in the DNS 
community for application-level uses like this).


On 2/9/22 4:29 PM, Travis Burtrum wrote:

Hi all,

The long story short (is outside of DNSSEC) it's impossible to use 
_xmppconnect TXT records to securely connect to BOSH or WebSockets. 
Every client I've been able to find that supported this is vulnerable to 
trivial MITM (Man-In-The-Middle) via DNS spoofing.  If you have a client 
that uses it, switch to grabbing host-meta via HTTPS per [RFC-7395] 
immediately, maybe grab a CVE if you wish.


Sonny commented on your PR that "RFC 7395 doesn't define bosh lookups"; 
this might be true but that raises the issue of whether we should still 
recommend BOSH, since it was a pre-websockets workaround for long polling.


I propose we litter [XEP-0156] with warnings explaining why it's 
insecure and should never be done, and obsolete it, instead referring 
people to the single host-meta method that [RFC-7395] defines, which 
provides secure delegation when grabbed over HTTPS.


In general, +1 to what you propose.

Peter
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0156 _xmppconnect is vulnerable to MITM

[Travis Burtrum]

PR implementing my proposal https://github.com/xsf/xeps/pull/1158
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0156 _xmppconnect is vulnerable to MITM

[Travis Burtrum]

Issues I know about right now:

https://github.com/processone/docs.ejabberd.im/issues/113
https://github.com/JustOxlamon/TwoRatChat/issues/2
https://github.com/poVoq/converse_wp/issues/2
https://github.com/BombusMod/BombusMod/issues/130
https://github.com/hesa2020/Twitch-To-League-by-Hesa/issues/1
https://github.com/xmppjs/xmpp.js/issues/933
https://github.com/tigase/tigase-http-api/issues/8
https://github.com/tigase/tigase-extras/issues/3

https://dev.gajim.org/gajim/python-nbxmpp/-/issues/124

Tigase devs confirmed sure.im is vulnerable

libpurple and therefore pidgin, adium, chatty, thunderbird, others? 
support BOSH and are vulnerable


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___