We test-ran the fix on ignite - works fine!

My earlier fix changed TLS failure handling on the connection used after a S2S connection was successfully established. In this issue, we're not getting to that point (the earlier fix itself is an improvement though, but not for the issue at hand).

A problem occurs before the S2S connection is established, on the connection used for dialback. The changes for add TLS support to Dialback, but won't allow for TLS to fail.

PR https://github.com/igniterealtime/Openfire/pull/489 allows Dialback to be retried after a TLS failure occurred, skipping TLS.

talkonaut.com kindly engaged us on this and noted the following stanza

https://github.com/igniterealtime/Openfire/pull/466 changes the event from an 'exceptional' handshake failure to a normal one. This should make logging less verbose.

This does not, however, fix the issue with S2S to talkanout.com - I'm guessing that new default settings for TLS now simply disallow federation.

TLS (and SSLv3 before it) include an Alert record which, amongst other things, indicates the session is being closed, in order to protect against a truncation attack where you kill a session (by spoofing TCP RST packets, etc) before all the data is across.

HTTP/1.1 is somewhat immune to this, and it has no effect at all on XMPP.

Swallowing this stack trace would be fine.

I note though that we're being a little over the top in validating certificates at the moment - I'll review that code over the next week or so and see if we can make it work a little closer to expectations.