Agreed on the 2 use cases, but I a disagree with the 2nd one. Using HTTPS allows : 1) that the subscriber knows it sent the subscription request to the right hub (verification of the SSL cert is obviously required) 2) that the callback is encrypted
So when the subscriber gets a verification request on the right callback (which was encrypted...), we are in the exact same situation that you described with verify_token: "the subscriber can be confident that whoever first supplies that same callback back in a verification request *must be* the intended hub, because nobody else (at that point) could know it." I would add that even if someone sniffed the callback url, it doesn't change much, as what matters if the notifications that MUST not be forged. If the worst case is that someone knows about a callback url, then, there isn't much to fear. And if a susbcriber cannot accept that, then, well, nothing prevents them from using HTTPS for their callback urls :) So, even by Brett's definition, I think the verify_token is useless. Julien On Tue, Feb 21, 2012 at 2:08 AM, Antoine Imbert <[email protected]>wrote: > Andy, you’re right that there are two different use cases, and that > they should probably not be mixed. > > About subscription identification: > IMHO the specs should strongly encourage users to put an id in their > callback URLs. It seems strange to me to rely on the content of the > ping to identify the subscription. I think it’d be great to see > Pubsubhubbub evolving into something that is not only about feeds. An > idea for the next spec version maybe. > > About impostor hubs: > As you said, the verify_token is really efficient for this purpose > only if used with https for the “subscriber to hub” request. > And if originally it was designed to verify that the subscriber is > talking to the same hub, the current spec is less clear about that, it > says “to assist the subscriber in identifying which subscription” > (6.1). > In my opinion, for real protection against impostor hubs, the best > would be to use hub.secret + https and then HMAC for the verification > request (same as the authenticated ping 7.4). We could then drop the > verify_token param that I find confusing. > > Antoine > > On Mon, Feb 20, 2012 at 2:33 PM, Andy Dennie <[email protected]> > wrote: > > I think we're talking about two different things here. Julien and > Antoine, > > you are talking about using the verify_token as a means for the > subscriber > > to match up the subscription/unsubscription verification request with the > > associated feed on the subscriber side. But there is already a way to > > accomplish that, namely by making the callback URL unique on a > > per-subscription basis. > > > > My understanding of the purpose of the verify_token is, to quote Brett > > Slatkin: > > > > > > - Used by the subscriber to verify that the hub verifying a > > subscription request is the correct hub and not an impostor. > > - Used once and thrown away. > > - Secret known by both the publisher and subscriber. > > - Transmitted from the subscriber to the hub and back again to verify > > the subscription. > > - Could be stolen by a snooping party > > > > > > [Note: Brett also described it as required, but I'm assuming it was > > subsequently made optional]. > > > > Also, section 8.2 of the spec states: > > > > The hub.verify_token parameter in subscription requests enables > subscribers > > to verify the identity and intent of the hub making the verification > > request. > > > > > > That is, using https in the subscription request to the hub may secure > the > > request to the hub, but it doesn't do anything to authenticate the hub to > > the subscriber in the verification request. However, by supplying the > > verify_token in the payload of the encrypted subscription request, the > > subscriber can be confident that whoever first supplies that same value > back > > in a verification request to the callback URL must be the intended hub, > > because nobody else (at that point) could know it. It could be sniffed > off > > the wire during the verification request, but would be of no value to an > > imposter in spoofing subsequent verification requests, since the > subscriber > > would only consider it to be valid once. > > > > So, the elegance, or lack thereof, in including the verify_token in the > > callback URL depends on whether you consider it to be a feed identifier, > or > > a hub authenticator for the verification request. I don't look at it as > a > > feed identifier, since my callback URL already identifies the feed > uniquely > > (via a query string param). If you accept Brett's definition of its > > purpose, then including it in all future requests to the callback URL > (not > > just the verification request) doesn't seem helpful, and could be > confusing, > > since its useful lifetime ends after the verification request. > > > > -Andy > > > > >
