What do you call "fraudulent reuse."? I guess that's what it's coming down to :)...
And I do disagree with Brett's point, 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. The HTTPS comes with a cert, so the subscriber can verify that he is talking to the right HUB. The subscriber then _knows_ that the right hub got the callback (and the hub only). Now, 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. (of course someone could randomly find the callback url, but that is true for the verify token too). You are right that the url is not encrypted in the verification request, but again, that is the same with the verify token. 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. Another option would be for subscribers to refuse 2nd confirmation and resubscribe with a different callback when in doubt. Both of these suggestions do mitigate the issue (the second one work exactly like the disposable verify_token, and is even more secure, I would argue). Now, IIRC , at the time when the verify_token was added to the spec, nobody really thought about using a different callback url for each subscription (the idea came from Jeff Lindsay's feedback). In that context, yes, having a verify token made sense, because it allowed the subscriber to know what was being confirmed. Julien On Tue, Feb 21, 2012 at 3:23 PM, Andy Dennie <[email protected]>wrote: > To Antoine: if there was a way to use the hub.secret/HMAC technique > effectively on the verification request, that would seem like a good > approach. I'm not a security expert, but I think the issue there is that > because there is no payload in a verification request, there isn't much in > the way of input data to be used in the signature computation (there's the > callback URL itself, but it's small, and besides that, it doesn't change, > therefore, in the absence of SSL, a signature based on the callback URL > could be sniffed once and reused later). > > To Julien: I agree that the callback URL serves equally well as the > verify_token up to the point of the first use (i.e. it's encrypted on the > way to the hub and only known to the hub at the time of the first > verification request to the callback URL), but since the callback URL needs > to be reused later, it can't be thrown away by the subscriber to thwart > fraudulent reuse. As far as whether there is anything to fear, well, you > know what they say, "it's not paranoia if they really ARE out to get you" > :-). > > As Brett pointed out later on in the thread I linked to earlier [**]: > > The role of verify_token is to prevent any DoS attacks against a subscriber > URL by a third party. > > > That is, by invalidating the verify_token after its first use, the > subscriber can quickly reject any subsequent illegitimate verification > requests. > > Perhaps I'm being dense, and as soon as I hit "send" I'll realize my > mistake, but for the moment I'm not seeing how an HTTPS callback URL, in > the absence of a one-time-use secret, helps to authenticate the hub for the > verification request. The URL itself wouldn't be encrypted during the > verification request, so it would be available to sniffers, who could then > use it to send their own fake verification requests to the HTTPS callback > URL, which the subscriber wouldn't be able to detect as fake. > > I think this may be the point that Brett was making also, when he referred > to the DoS issue in response to Pádraic Brady's suggestion that SSL would > solve the problem. > > [**] For those following along at home, that thread is a good read in > regards to this whole category of issues, so here's a > link<https://groups.google.com/d/topic/pubsubhubbub/hfXUeXTlcAg/discussion> to > the top of it, if you're interested. > > -Andy > > > >
