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