> 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).
OK, I'll concede that; you're right, a DoS has other characteristics that allow it to be identified. Still, it seems useful in the subscribe/verify handshake between the subscriber and the hub, that the subscriber can verify the identity of the hub when processing 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 :) OK, here is where I have to apologize and admit to a mistaken understanding on my part. I was under the impression that the URL was exposed during an HTTPS communication, and only the request content was encrypted. However, since you obviously believed the opposite to be true, I fell back to the old poker adage "if you've been in a poker game for a while and you don't know who the sucker is, get up, it's you". And so I looked it up and guess what, it IS me :-) So, mea maxima culpa and all that. In my defense, I think I said several messages back that I'm not a security expert, and now I've proven it. And so, I admit that if the subscriber uses HTTPS, the callback URL will remain secret. This may put a bit of extra burden on some subscribers (in terms of getting and managing a cert if they're not already doing so), but it's a solution. I hadn't personally been using HTTPS for my callback, but I certainly could. Thanks again for the exchange! -Andy
