views:

369

answers:

2

I've been looking around at various APIs, and since twitter seems to be a common discussion point, I'll use it as an example.

A lot of APIs are implementing oAuth which is great for allowing the service to authenicate and authorize the application connecting to it, however, from what I have seen there doesnt seem to be a way for the application to verify that Twitter is actually Twitter (and not a man in the middle based attack)? I would expect to see some kind of signature (using a shared / public key) of the response body which I can use to validate that twitter signed it.

Is it just because currently there isnt really a point to a man in the middle attack with twitter tweets since currently, whats the worst that can happen (and why would someone want to give me invalid tweets)

On this point, if you were to sign the response, what method would you use? Im currently considering a HMAC-SHA1 signature of the response body using a shared key.

+1  A: 

This is what the 'trust' part of SSL does.

-- Edit

I note this has been downvoted, but it's important that other readers realise it's due to a personal disagreement, not due to incorrectness.

Noon Silk
SSL seems like a lot of overhead - especially for a service that is receiving hundreds of thousands of requests...
RM
As I've hinted at in the comment in your post; if you don't validate it and use SSL, even if you check, by some scheme, that it's who you think it is as first, if the connection isn't protected from change (i.e. SSL) it doesn't matter; you can't trust what you're receiving. The bottom line for you is obvious: Either you accept the latency with SSL, or you accept that you don't know where the data is coming from.
Noon Silk
@silky, I think we're looking at two different things here, I want to validate the message, you seem to want to validate the transport mechanism, i.e. if you sign each message you could print it, email it, use UDP do what ever you want with it and integrity can always be maintained. I'm refering to a signing scheme per message, not a once off transport level scheme. (i.e. im refering to HMAC-SH1 hashing http://en.wikipedia.org/wiki/HMAC-SHA1 or similar)
RM
RM: No, we're not, I'm sorry but you just don't understand what it is you're trying to do. I'll leave it to someone else to explain, as for whatever reason, there appears to be a general problem communicating.
Noon Silk
@RM, I agree with you - you're talking about two different things. SSL is for encryption, which you've clearly indicated you don't need. I say HMAC-SHA1 is a good choice for what you're trying to achieve.
Michael Hart
SHA1 is not a good choice for any cryptographically-related hashing scheme. (http://valerieaurora.org/hash.html)
Noon Silk
@silky, that's such an awesome comment. Out of interest, which SSL provider do you use?
Michael Hart
Michael: Just because they haven't caught up doesn't mean you shouldn't. I'm guessing there is some attitude in your comment, but there is no real point engaging that here (any moment now it's probably worthwhile flagging this whole discussing as useless; though it is important people realise that SHA1 is actually, effectively, dead).
Noon Silk
A: 

In the .NET world we use WCF, which has many different security models, including signing (and if desired encrypting) each message/response. This adds up to a non-trivial amount of overhead, but can give you more 'trust' in the security model. You can switch to using binary-serialized data to cut down on the bloat and message size if you desire.

I'm not sure what other Web Service APIs offer in that area, though I'm sure someone else can add further details as needed.

Timothy Walters
Yeah thats the sort of thing i mean (signing, not encryption), but for standard REST or POX services such as Twitter.
RM