What are some of the practical risks that come with a server-to-server connection over http (not secured with https/SSL)? There are no users involved, just a server-to-server connection from one company to another.
Business A will call a web service endpoint at Business B. An API key will be included in the call to be used to gate access (e.g., key must be valid, in good standing).
I know it is possible to snoop the traffic. Not sure this is likely, just possible. How does one reason about the associated risk?
What are other practical risks?
EDIT: For additional context, some public web APIs support http-based calls with key passed either in payload or URL. For example: Posterous, Tumblr (new API supports OAuth over http), Bing, GoodGuide and Flickr.
EDIT 2 17-Mar-2014: I posed this question two years ago. It stemmed mostly out of my curiosity about real attack vectors in server-to-server scenarios since most of the visibility is around end-user attacks or hacking into servers. But I've rarely heard "if only we'd used server-to-server SSL!" (though I do recall one exception - the 2006 TJX breach - where credit cards stolen from unsecured wifi channel, with I suppose plain http within it - though wifi is your not typical server-to-server scenario).
It isn't that I don't understand or know how to use SSL (I do, I use it, and I understand the crypto behind it), so this isn't ignorance of the tool set. In the answers thus far, nobody considered that the web APIs I list above could all be used to compromise sensitive data (a private photo in Flickr, posting some malicious content to my account in Tumlbr (Posterous is gone!), accessing my personal (could be very private) search queries in Bing and GoodGuide).
Since the complexity of offering APIs over HTTPS falls entirely on the service - it is easy to choose HTTPS as a client (even though, in the scenario of interest here, the "client" is another server) - I supposed that the likes of the vendors producing the APIs listed above carefully weighed the pros and cons and decided allowing HTTP was okay.
I do agree that any time we are in charge of confidential or sensitive end user or company data, we have an implied fiduciary duty to treat it responsibly on the wire (whether production, dev, or test - if it deserves protection). But this isn't every scenario (again, which is why I posed this question).
Here are some tradeoffs that might come to mind in the general case.
Also, dev and test instances of many services ofter are better off without SSL. They are easier to debug on the wire when the traffic isn't encrypted. Additionally, it is extra painful to set up SSL certs for most of the environments because they will often have ad hoc ever-changing domain names on the endpoints as environments come and go, perhaps not even consistent enough for a wild-card cert.
There are also server-to-server scenarios that are less vulnerable than others - even if there is sensitive data being transmitted. For example, consider servers belonging to different divisions within the same company, and the data doesn't travel over the public internet (e.g., 192.168 address range).
As another example, consider servers running in a public cloud platform (Amazon or Azure, for instance) - I don't think you can run into trouble from other servers running in the same data center region because no code (other than the platform host) will have the ability to elevate permissions on the hypervisor to set the NIC card to promiscuous mode to snoop traffic (and even if it could, it could not see it through the hypervisor (I think), and even it if could it could only snoop traffic within its own VNET).