That's actually a good idea,I should get around to adding a list of inaccessible servers on my site as well.<br /><br /><br />15:39, 5 October 2015, Vicious Feline :<br /><blockquote>Im running my servers since five years now. I have a good documentation on my page which servers are not reachable. It's a point where I am very strict. No s2s encryption no service. In those five years I had two tickets from users which tried to reach a server which was not able to encrypt. <br /><br />Von: Matthew Wild<br />Gesendet: ‎05.‎10.‎2015 15:26<br />An: XMPP Operators Group<br />Betreff: Re: [Operators] Please enable Forward Secrecy for your servers!<br /><br /><br />On 5 October 2015 at 02:04, Mike Barnes  wrote:<br />> What we need to be doing is putting information about the quality of<br />> encryption used in a conversation in front of the users, and letting<br />> them make informed decisions, instead of fracturing the network<br />> invisibly.<br /><br />I semi-agree. Once I would have completely agreed :)<br /><br />One problem is that this approach leads to overloading the user with<br />information (that they aren't really qualified to make a choice on).<br />You will notice that the current trend in browsers is now removing<br />this information as much as possible, and just doing the "right"<br />thing. Websites with incorrect certificates used to show a warning<br />padlock, now they throw up big alert pages that are hard to bypass.<br /><br />> Is there any defined mechanism to do this? Users are accustomed to the<br />> little padlock icons on web URLs, can XMPP client software easily<br />> implement something like this or will it need server extensions to<br />> report back? As a temporary measure, could the server send a direct<br />> message to a user alerting them if the encryption on a connection they<br />> initiate falls below a desired threshold?<br /><br />It would need the server's help. This has in fact been discussed<br />before, a long time ago. I think there was even a XEP. The problem is<br />that it wasn't enough. The server doesn't always have a connection<br />open to the remote server, so it doesn't know (in advance) what<br />security proprties it has.<br /><br />Then, when it does have a connection, this is easily changed. An<br />attacker with access to the network could let the secure connection<br />through, so that the client displays the padlock. Then when the client<br />sends a message, quickly break the secure connection, and ensure only<br />an insecure one can be established.<br /><br />> Inform the users, don't cut them off from their contacts and leave<br />> them no path to even tell them why.<br /><br />I think a better option is to let the user decide whether what they<br />are sending is sensitive or not, and the level of security to apply to<br />that particular message. That way, their (obviously trusted) server<br />will never send a sensitive message over an insecure connection, etc.<br />A failure would result in a delivery error, which can be handled by<br />the user's client.<br /><br />This is technically achievable using security labels<br />(http://xmpp.org/extensions/xep-0258.html ), though it hasn't really<br />been deployed that way on the public network, and not many clients<br />support it (though Swift and Gajim both do, and they are<br />cross-platform).<br /><br />Regards,<br />Matthew<br /><br /></blockquote><br /><br />-- <br />Sent from Yandex.Mail for mobile