Thank YOU! It was a good way for me to think more about the issue. There is really no harm done...
Ju On Tue, Feb 21, 2012 at 7:45 PM, Andy Dennie <[email protected]>wrote: > > 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 >
