Hi Kim - what happens from the end-user POV when that module is in place? Will most clients reliably report that back?
I'm really hesitant to implement a massive restriction like this precisely because it is invisible to the end user, and is just going to lead to more people going "well, I can't talk to f...@some.im any more, it worked last week" and giving up on XMPP. It'd be much better to warn a user that their encryption is not up to standard, and letting them make a decision or tell their contact about it. If we just flat cut off their ability to communicate event that there's a problem it's not very user-friendly at all. Is there a defined way that we can reliably send meta-information back to a user about their connection to a remote server while still allowing the connection to proceed? Maybe just via a server announcement when they make an outbound connection that falls below a defined threshold to be considered secure? I have enough trouble convincing people that XMPP is worth the bother as it is, without making sudden changes that invisibly break functionality. I will continue to keep my end up to date and ensure that I'm capable of forward secrecy, but I'm not going to mandate it yet. On 13 September 2015 at 05:33, Kim Alvefur <z...@zash.se> wrote: > Hi all! > > At the last summit in Brussels, at some point, the issue of how > reporting errors from TLS cipher mismatches is kinda horrible. So the > idea of allowing a more liberal set of ciphers but throwing a > <stream:error> at the application level came up and I wrote a > proof-of-concept plugin for Prosody doing just this. > > http://modules.prosody.im/mod_tls_policy.html > > It will basically run a pattern match on the cipher string and, if it > does not match, close the connection with: > <stream:error> > <policy-violation/> > <text>TLS cipher 'RC4-MD5' not acceptable</text> > </stream:error> > > -- > Kim "Zash" Alvefur >
