End to end encryption is a worth goal. This is very cool for getting information on the s2s connection.
XEP-0219 makes a lot of assumptions about the network topology always involving the traditional c2s design. How might this XEP report meaningful information back to the user in the following situations: - cleartext BOSH inside SSL terminated HTTP session? - cleartext on loopback to new c2s services like XMPP-FTW or the buddycloud-api? - websockets? S. On 6 June 2013 09:56, Dave Cridland <[email protected]> wrote: > On Thu, Jun 6, 2013 at 6:11 AM, Philipp Hancke > <[email protected]>wrote: > >> I've been thinking I'd like to resurrect the Hop Check proposal >>> (because after further reflection I think it would be useful, even if >>> not perfect): >>> >> >> for debugging/support? +1 >> >> > I've not checked back to see whether I liked this or not before, so I > don't know whether now deciding it'd be a good thing would be an > embarrassing U-Turn or not... > > But FWIW, when this was proposed, I think it was suggested as a "is my > end-to-end path secure?" - to which the answer is "not if you had to ask" - > rather than as a debugging protocol. > > >> [...] >> >> Before I post an updated version, does anyone have requests for data >>> they'd like to see included in the data format? >>> >> >> A bidi flag (for s2s) and the raw certificate data for both dialback and >> external auth. Probably also whether an SRV record was resolved or the A >> fallback is used. >> >> And keep in mind that most s2s connections still aren't bidi, see the >> list archives from 2007 for some discussion ;-) >> > > 1) I'd suggest for most things we just stuff features into the thing if > they've been used, maybe? > > So for XEP-0138, we'd see something like: > > <hop ...> > <compress xmlns='...'><zlib/></compress><!-- Oooh, we used zlib, yay! --> > </hop> > > This'd hold for SASL auth, too: > > <hop ...> > <sasl xmlns='...'> > <mechanism/> > </sasl> > </hop> > > 2) I know that having the certificate chain would also be useful, as well > as any reasoning for trusting it - or not trusting it, perhaps even more > important. There are many times I'd have dearly loved to have been able to > tell why a certificate wasn't trusted by the peer in ways that didn't > involve trying to parse other people's logs, so the reasoning here is more > useful that the certificate chain to me. > > 3) I'd also point out that while it'd be very useful to know how your > victim authenticates, having this as a mandatory feature seems like a > security issue. ("Oh, he authenticates using PLAIN without TLS, does he? > Oh, goody!") > > 4) Some links - S2S, for instance - have have different characteristics on > the return path than the forward path - XEP-0219 never addressed this. I've > a feeling this one came up at the time. > > 5) Currently, this protocol is framed such that each hop is mandated to > ask the next. It might be useful for this to be reframed as an end-to-end > protocol, so that Juliet asks her server, then Juliet asks Romeo's server, > then (possibly) Juliet asks Romeo. > > So, erm, basically that's close to a complete rewrite, I think. :-) > > Dave. > -- Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP
