You are not being a pain in whatever :) I deleted the things that are not worth keeping.
On Tue, Feb 21, 2012 at 6:16 PM, Andy Dennie <[email protected]>wrote: > Let my try responding one point at a time, it makes for easier reading, I > think. > > > verify_token won't prevent any DoS attack. If someone sniffed the > callback url (with or without the verify token), nothing will prevent > someone from doing a DoS attack. ' > > Nothing will prevent the attack itself, but the attack can be recognized > as fraudulent, and the requests quickly rejected without acting upon them, > by virtue of the verify_token no longer being valid (since it was > previously discarded by the subscriber). > I'm pretty sure a DoS can be considered as an attack without even caring about any other hint. So if a hub (or an hub-impersonator) DoS a subscriber, the subscriber should take adequate measures wether there is (or not a verify token). > > >if he gets verification on that callback, it knows it comes from the > hub, because the hub only knows about this url at this point. > > Right, but after that point, the callback url has been exposed, and since > it's not a used-once-and-discarded secret, it doesn't help thwart > subsequent illegitimate verification requests. > > >The only "difference" would be for later reconfirmations of intent, > which, with the callback could be "spoofed". If someone found the callback > url, they could reconfirm with the susbcriber that he still wants the data. > That doesn't seem so bad, and for the cases where it is (a subscriber may > want any 3rd party to know that it's getting content from a specific hub), > then, the use of HTTPS on the callback url just solves that. > > [I assume you meant "a subscriber may NOT want"...] > Exactly! > I'm a little confused; the use of HTTPS on the callback doesn't > authenticate the hub to the subscriber, it authenticates the subscriber to > the hub. Unless you're talking about using client certificates (i.e. the > hub provides a client certificate to the subscriber on the verification > request) ? > But if the hub uses HTTPs to communicate with the subscriber how can anyone "snif" the callback url? since the callback url was only communicated over HTTPs to the hub, and then back to the subscriber, there is no way anyone can snif anything :) > > > Another option would be for subscribers to refuse 2nd confirmation and > resubscribe with a different callback when in doubt. > > > Hmm, that's an idea, let me think this through... > > - Subscriber's subscription request to hub includes callback=" > http://www.myapp.com/subscriber?sub_id=12345"; > - Hub's verification request to callback URL is accepted by > subscriber, who records the acceptance in some way > - DoS attacker sends verification requests to callback URL, subscriber > rejects them because they're not the first one. So far, so good. > - Subscriber sends unsubscription request to the hub, supplying the > original callback URL > - ... OK here's a problem, I think... at this point the subscriber > can't distinguish between a legitimate unsub verification request from the > hub, and an illegitimate one from an imposter, because we're past the point > where only the hub knows the callback URL. > > No it's not. If the subscriber performs an unsubscription request, it should not expect anything from the hub on that callback (provided he uses HTTPS and the hub identity was confirmed). The verification process is for the hub, not for the subscriber. So, now the subscriber has discarded the subscription and its callback. He MUST ignore anything else on this callback (and confirm he doesn't want that content). > > - > > > At this point in the conversation, I feel like I should pause and say that > I'm not trying to be a pain in the a** (although it probably seems like > it). This has been a good conversation and I appreciate the interaction. > I just want to make sure that before something is removed from the spec, > the use case that it addressed is either addressed another way, or agreed > to be not important to address. > I believe both things are true, and I believe (from an implementor's perspective) that the verify_token has been a pain in the ass for many people who implemented PubSubHubbub because they couldn't really understand what it was for and how it was useful in any way. Julien > -Andy >
