Use TLS-dialback even if that mechanism is not advertised
Description
If a TLS-handshake is done to a remote server it should respond with features how the authentication could be done. Some servers don't send features back and the protocoll specification is a inpresice how the initiating server should handle this.
See XEP-0178 Point 3.9: Server2 advertises SASL mechanisms. If the 'from' attribute of the stream header sent by Server1 can be matched against one of the identifiers provided in the certificate following the matching rules from RFC 6125, Server2 SHOULD advertise the SASL EXTERNAL mechanism. If no match is found, Server2 MAY either close Server1's TCP connection or continue with aServer Dialback (XEP-0220) [8] negotiation. So we could close the connection (what OF do until now/3.9.1) or switch back to server dialback over TLS and try it.
My proposed behavior is also more plausible because if SASL EXTERNAL is offered but it doesn't auth the domain there is also a silent fallback to dialback regardless it is offered by the remote server. With my change there is also a TLS-dialback if no SASL EXTERNAL is offered and it's enabled by the server.
I built a SNAPSHOT version and tried it. The encrypted connections very greatly increased to a high level. The member Moonchild tried the same version on his server and reported the same good news.
I would be very glad if you raise a ticket, I provide a simple patch file and you integrate very soon.
Environment
None
Attachments
1
Activity
Show:
Sven Bunge May 3, 2014 at 11:01 AM
Hi Zash,
it seems unreleated to this issue. The server tries to send a ping and a NPE occurs. The connection is still closed. => We see two exceptions. Please open a new issue (or thread on the development forum) and I will dive into. Please provide some steps how I could reproduce the exception. I see it today the first time. Please provide your S2S-SSL-settings as well. I think we still have some issues if an encrypted connection is set to mandatory.
Thanks in advance, Sven
Zash May 3, 2014 at 10:54 AM
Actually, that happens even if the connection uses SASL EXTERNAL.
Zash May 3, 2014 at 10:51 AM
The connection is closed on completion.
Daryl Herzmann April 9, 2014 at 3:00 PM
This change definitely made a difference with the number of secured s2s sessions reported by openfire on igniterealtime. Going to close this as fixed for now.
Daryl Herzmann April 9, 2014 at 2:45 PM
I've committed this patch, will test it on ignite shortly.
If a TLS-handshake is done to a remote server it should respond with features how the authentication could be done. Some servers don't send features back and the protocoll specification is a inpresice how the initiating server should handle this.
See XEP-0178 Point 3.9:
Server2 advertises SASL mechanisms. If the 'from' attribute of the stream header sent by Server1 can be matched against one of the identifiers provided in the certificate following the matching rules from RFC 6125, Server2 SHOULD advertise the SASL EXTERNAL mechanism. If no match is found, Server2 MAY either close Server1's TCP connection or continue with aServer Dialback (XEP-0220) [8] negotiation.
So we could close the connection (what OF do until now/3.9.1) or switch back to server dialback over TLS and try it.
My proposed behavior is also more plausible because if SASL EXTERNAL is offered but it doesn't auth the domain there is also a silent fallback to dialback regardless it is offered by the remote server. With my change there is also a TLS-dialback if no SASL EXTERNAL is offered and it's enabled by the server.
I built a SNAPSHOT version and tried it. The encrypted connections very greatly increased to a high level. The member Moonchild tried the same version on his server and reported the same good news.
I would be very glad if you raise a ticket, I provide a simple patch file and you integrate very soon.