-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [ old thread alert ]
On 6/13/13 11:47 AM, Justin Karneges wrote: > On 06/13/2013 10:18 AM, Peter Saint-Andre wrote: >> On 6/13/13 8:40 AM, Matt Miller wrote: >>> >>> On Jun 12, 2013, at 8:41 PM, Peter Saint-Andre >>> <[email protected]> wrote: >>> >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>> >>>> On 6/6/13 6:40 AM, Matthew Wild wrote: >>>>> On 6 June 2013 10:21, Simon Tennant <[email protected]> >>>>> wrote: >>>>>> End to end encryption is a worth goal. This is very cool >>>>>> for getting information on the s2s connection. >>>>> >>>>> Perhaps on first sight. However this kind of usage is >>>>> exactly why the XEP died last time around. It isn't >>>>> suitable for anything except purely informational/debugging >>>>> purposes. This is because the link can change - it might be >>>>> encrypted when you check it, and then reconnect unencrypted >>>>> without you knowing. Also, malicious entities can always >>>>> lie. >>>> >>>> What I'd like is to know whether the connection from my >>>> personal IM server (stpeter.im) or my company's IM server >>>> (say, cisco.com) to a random server like prosody.im or >>>> jabber.ietf.org is encrypted. Sure, malicious entities can >>>> lie, but I try not to create accounts or authenticate with >>>> malicious servers. :-) Look, I need to have *some* level of >>>> trust in the server I authenticate with. I just want to know >>>> if the path from there to the next server is encrypted, too. >>>> If I'm a server admin presumably I have some kind of >>>> server-side tool I can use, but that's not the case if I'm >>>> not an admin. >>> >>> >>> I don't disagree that the user is trusting their server by >>> logging in. And if this check were to stop at "my.domain --> >>> other.domain", then I can see some confidence in the results >>> because of the trust. Changes in the state *could* be dealt >>> with by making this information available in a pubsub-like >>> manner (I sensed the collective shudder from some of our server >>> developers and operators before I even typed that sentence (-: >>> ). >>> >>> However, that trust doesn't carry over to the answer for >>> "other.domain --> [email protected]" which users will want >>> so very, very desperately. >>> >>> I don't necessarily have a problem with this as a >>> protocol-level diagnostic tool; it can help users (or rather, >>> the developers of the client the user interacts with) and >>> admins to troubleshoot. But the potential of abuse and >>> over-interpretation is extremely high. >> >> Yes, that is true, and I too don't want people to read more into >> the results than is justified. I will keep that very much in mind >> as I work on the next revision. > > What I'd like to see is an extra attribute on each incoming > stanza, indicating that it was received via a protected s2s > connection. Since the attribute would be per-stanza, it doesn't > have the race condition problem of the hop check. > > My use-case is I'm running a service that allows administration > via XMPP. Users may whitelist JIDs that should have access. The > current drawback with this approach is that it is not ultra secure. > Someone could conceivably make a dialback attack and act as someone > else. My plan is to add a checkbox to the administration config: > "Only allow administration from secure domains". The idea here is > that an incoming stanza would only be trusted if it was flagged as > having arrived via TLS-secured s2s, thus closing the dialback > security hole. True, this does not confirm that the user's client > is using TLS, but I don't think this is something I need to concern > myself with. It would be the user's responsibility to ensure nobody > else can hijack his account (by always using TLS, by using a good > password, and by trusting the admin of his server). > > Just one attribute is needed for this, stamped on by the receiving > server. Perhaps it could be a SHIM header. > > Maybe this should be in a different spec than the hop check. I > just wanted to bring up the idea here since I figure it fits the > discussion. It would provide some amount of tangible security > without having to go full-on e2e. Interesting. I definitely think that's worth pursuing, for the simple reason that it can indeed be stamped by the receiving server (and I can know whether my connection to the receiving server is encrypted). Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSN3t5AAoJEOoGpJErxa2p8e4P/0SKb4zspDpOwGg0QM2n3HQd PCI6a5DZYfkao7hfu2BFzGooN35xVabV5+nHhGg4tkYdJ4teWXYJDCkJYCE99/Z1 2tPWNtz4SfN6AC+kc/zu8aqTCoDNzSV/c3c3ns+XeOO5xtSLuM3PlLW+XdX5Gd0r 09m+TELSIEZ2jccwexQajwO7QRP372yvLuF6Fxzn/DLMc15nJEoX0NAQoAaLo1MS wKXHZovUQMGRPRrcs6KKuXhqNq4LchQJWy9z8jtsQn20VOIjB+Dn731OB4DSZNhC HFiT/kWDXWgNfmNLCPywaP/inQylM3xJobnzNJ8REBBaXWEb2wRwOIs0NwTFkwvE mh15VPbU0lebDqFwqy44rONk4U05yXTfwsqximONEYAi2gxaO3IfvucDL+lVic/Q dy7AvNPbREDwMzHYUMSyZ7/U1o566ckraJO0tITX2hXHTxODu0rIrIcOiou/W+in f4ATd/u7MZzv6fyw8ht5WaUGNZtcyddCvXe93SqjvSrj2bBS37J0FlkbcHzOLaS3 h4QpNpZM1YDZ1TS5NKJ7RMHEcQEFcFHnKo1XxCwSLS8aNcsh5WRlR/tFSXws3sn4 PtHG29lsJdPBPAHDGJ1XsOTSxJDphkftX50SzIv4rcZ4vS+kjNSc9MAkB5HGMBJX NA2W7ZrwDFY5hc21cCHd =KFOl -----END PGP SIGNATURE-----
