On Sun, 11 May 2014 00:22:48 +0200 Benny Baumann <be...@geshi.org> wrote: > When a server-to-server (s2s) SSL connection cannot be established there is no > fallback or backoff configurable that would try to use e.g. other parameters > like different set of offered cipher suites
So if the TLS handshake fails, ejabberd should retry with a different set of cipher suites? Why wouldn't you just specify the full set of acceptable ciphers in the first place? What other TLS parameters do you have in mind? Is there other software that provides such a feature? > or even would try without encryption - if encryption has been configured to be > optional for (outgoing) s2s connections. So if the TLS handshake fails, ejabberd should fall back to a non-TLS connection if both servers are configured to accept that? Note that the remote server will usually connect back to yours, and chances are that this connection runs into the same TLS issues. So in practice, falling back to a non-TLS connection will usually only help if the remote server does the same thing. Otherwise, you'll end up being able to send outgoing traffic but not being able to receive incoming traffic. Therefore, I think it would make more sense to implement a way for disabling TLS entirely for certain remote servers. > Furthermore ejabberd fails to report the cause of the s2s connection failure > in > a reasonable way thus only an unspecific "remote-host-not-found" is returned > to > the user even though the plaintext part of a STARTTLS session could > successfully > be performed. I agree the error reporting for server-to-server connection issues should be improved. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
