On 01/09/2018 05:55 AM, Florian Schmaus wrote: > On 09.01.2018 05:19, Travis Burtrum wrote: >> It is also clear I didn't think about this too hard when writing >> XEP-0368, because I clearly (to me) assume SRV fallback will happen if a >> complete XMPP connection is not successful, because under Implementation >> Notes I say: >> >>> Server operators should not expect multiplexing (via ALPN) to work in >>> all scenarios and therefore should provide additional SRV record(s) >>> that do not require multiplexing (either standard STARTTLS or >>> dedicated direct XMPP-over-TLS). This is a result of relying on ALPN >>> for multiplexing, where ALPN might not be supported by all devices or >>> may be disabled by a user due to privacy reasons. >> >> While I don't explicitly say it, if a port required ALPN to multiplex, >> it will generally end up connecting you to a non-XMPP server without >> ALPN, meaning you will get back invalid XML, other junk, and/or an >> invalid TLS cert. > > If I understood correctly, then a basic example where a xep368 fallback > after a TCP connection was established would be beneficial is, if there > is a high priority SRV RR pointing to a ALPN required destination. And > another SRV RR with a lower priority pointing to a non-ALPN destination. > > A client supporting xep368 but not ALPN would, without fallback, > immediately fail, neglecting the valid fallback position. You mention > multiple ways in how the non-ALPN client connection to a ALPN-required > destination could fail, (which appears to contribute to the confusion): > - Invalid Cert > - Invalid XML (how could that happen BTW?) > - (are there more?) > > I see the following options: > > 1. xep368 provides an implementation hint that such a fallback would be > a good idea. > 2. xep368 makes ALPN mandatory > 3. do nothing
I think a fallback is a good idea even without xep368, just with regular SRV lookup even. Made up scenario time! 1. The LetsEncrypt renewal bot on your primary server screws up and you don't notice, your secondary (and third/fourth etc) have valid certificates though. Would you like to connect or fail after first attempt? 2. The country of Elbonia publishes bad BGP routes routing traffic to your primary server through them, also they intercept all https traffic, so despite having other servers, you can't connect because fallback has ceased on invalid certificate. This has happened many times [1]. 3. Your local coffee shop wants to put ads in your browser, the owners nephew Timmy has heard of sslstrip and thinks it's cool and turns it on, you cannot connect to XMPP. (even though a fallback to a non-443 port would allow you) 4. Your only choice for ISP, Comcast, injects ads in your web browser and mistakenly sees XML from 5222 and thinks it needs more javascript. Not a made up scenario [2]. They are so proud of it they wrote RFC6108 [3]. Is there any reason why any client would rather fail and show a 'cannot connect' to a user rather than actually allowing them to connect? I can't actually think of one. As to making ALPN mandatory, it actually solves none of the above scenarios, and reveals the underlying stream is XMPP which someone might not want. [1]: https://en.wikipedia.org/wiki/BGP_hijacking#Public_incidents [2]: https://forums.xfinity.com/t5/Customer-Service/Are-you-aware-Comcast-is-injecting-400-lines-of-JavaScript/td-p/3009551 [3]: https://tools.ietf.org/html/rfc6108 _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
