Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote 2 down vote favorite

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 B2B 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.

share|improve this question
6  
facepalm..... – Kyle Feb 24 '12 at 19:45
1  
@Kyle - not sure why asking this question is a facepalm ( which I had to look up: urbandictionary.com/define.php?term=face%20palm ). Care to speculate as to why these high profile sites allow their API keys to travel in the clear? – codingoutloud Feb 25 '12 at 2:14
As mentioned below, my guess would be that the sites you mentioned are not sharing information that isn't already public so there's no need to secure it. The API key is probably merely just to enforce some level of throttling. If you're passing information that is sensitive you have an obligation to your users to use https – Kyle Feb 27 '12 at 14:32

5 Answers

up vote 0 down vote

Whether it's two servers communicating (web services) or you are making requests from a browser, the protocol that carries your data is still HTTP. HTTP by default provides no security and sends all the data in plain text over the wire. Whenever there is critical data (credit card details,identity information etc.) involved it is recommended to use HTTPS.

Using plain HTTP makes the communication vulnerable to attacks like MITM. Simple packet capturing will lead to loss of critical information.

If there are any public APIs involving key exchange over http keys then those keys are supposed to be public.

share|improve this answer
up vote 3 down vote

Suppose you are a business. Business is no country for weaklings. Whatever you do, you are bound to have that special kind of enemy known as competitors.

Your competitors are not nice people. Nothing would please them more than to, metaphorically, enter your house, empty your fridge, drink all your wine, molest your dog, and leave with your TV and your daughter. They might express it as "gaining market shares", but that's just an euphemism.

Now suppose that you send to your competitors a nice letter containing a copy of your front and back door keys, detailed information about when you will go on holiday, and the mobile phone number of your daughter. Still metaphorically, that's what you do by using plain HTTP for your B2B connections.

How do you reason about risks involved by plain HTTP ? By remembering that it is a bloody stupid thing to do. Risk vs cost analyses are fine in principle, but when the risk is that high and the cost that low, they become totally ridiculous. Plain HTTP is vulnerable to everything. HTTPS is cheap.

share|improve this answer
up vote 1 down vote

Practical risks include: you are vulnerable to eavesdropping, DNS hijacking, and BGP attacks.

Also, if you're unlucky/not careful, cryptographic keys and other secrets in the URL or query parameters may be recorded in logs or possibly even leaked to third parties in Referer: headers.

For these reasons, I recommend you just use HTTPS. It is usually easy to turn on and eliminates one class of security risks. Even if those risks are not the most likely ones facing you, the cost of eliminating them is often very low, so the cost-benefit tradeoff is probably worthwhile.

share|improve this answer
What if there was a private VPN or dedicated circuit in the B2B connection? (cc: also @Thomas Pornin) – makerofthings7 Apr 22 at 13:59
up vote 3 down vote

Choosing what you should use depends on what information will be shared between the servers.

If you're going to share sensitive/confidential information such as banking data(credit/debit cards etc), medical information or something like that you should DEFINITELY USE SSL! You should also make sure your servers have a firewall and are visible only to each other (Company A->Company B and Company B->Company A).

On the other hand if the companies will share only non-confidential information then PROBABLY you may use only http.

Regarding the sniff - it's possible and many attackers use it. The possibilities are endless. An attacker may sniff your packets, then try to send similar packets to confuse both of the servers. Eventually the attacker may gain control on both of the servers.

The reason Posterous, Tumblr, Bing, GoodGuide and Flickr (and others) allow http is probably because they're not sharing information about users that's not already public. I surely doubt they share their user's passwords via the API :)

Though I tried to explain it the easy way, for your own good, please read a couple of articles/books about how encryption works, why and when it's required. It's a really big that can't be explained in 5-10 sentences.

Here are a couple of links that can help you understand:

  1. http://tldp.org/HOWTO/SSL-Certificates-HOWTO/x64.html
  2. http://www.globalsign.com/ssl-information-center/what-is-an-ssl-certificate.html
  3. http://shop.oreilly.com/product/9780596002701.do
share|improve this answer
+1 for PROBABLY comment since security is a trade-off [“Security is always a tradeoff; it must be balanced with the cost.” - Bruce Schneier]. Interestingly, Posterous, et al, do expose a key that can be used to make changes on behalf of user, not just view public data. I appreciate the links. It is not that I don't understand encryption, it is that I am trying to understand the risk. My "How does one reason about the associated risk?" question in my post speaks to my curiosity around how to model it. Modeling requires cost of loss (which I did not specify) + chance of loss (big question). – codingoutloud Feb 25 '12 at 2:05
I haven't used Posterous but probably they have at least some kind of encryption going on in the api while the client/server communicates. I don't think they'd leave it just plain http. If they did - they're open to a potential attack. If you go to their site though you'll see it instantly redirects to the https. So probably they have something else going on behind the scene :) – tftd Feb 25 '12 at 4:02
That is for the consumer site, I assume. My (non-rigorous!) experiment just now with a call to an API endpoint does not appear to redirect to SSL. And the "key" this API wants includes a username and password (!). Anyway, even if it did redirect, the damage would have been done. – codingoutloud Feb 25 '12 at 4:59
What I meant to say is the API may have it's own encryption going on inside the code. Anyway sending sensitive information (like username & password) over http is not best practice. Of course you can do it but this opens up a big whole in the security. – tftd Feb 25 '12 at 13:55
1  
I'd add credit/debit card will trigger things like PCI-DSS audits that must be used and followed or incur fines from the merchant bank. – ewanm89 Feb 26 '12 at 18:16
up vote 4 down vote

"I know it is possible to snoop the traffic. Not sure this is likely, just possible. How does one reason about the associated risk?"

It's thinking like this that costs companies millions - if they would have just secured the information in the first place, it would be a non-issue.

Simple - how much will it cost you if someone steals data from company a or company b - if its more than the cost of buying a cheap SSL cert then it's justified. It's no longer a question of "if" it will happen, it's a matter of "when".

share|improve this answer
Thank you for the response. Why do you think Posterous et al allow their callers to expose a key in the clear? I can only guess they did some cost/risk tradeoff and decided it was okay to allow. Other APIs, such as from Twitter and Twilio, only appear to offer secure endpoints. – codingoutloud Feb 25 '12 at 2:10
Regarding "how much will it cost you if someone steals data from company a or company b - if its more than the cost of buying a cheap SSL cert then it's justified." Respectfully, I do not believe a proper model can be that simple. Is it not also a function of the probability of compromise? This was the thrust of the question "How does one reason about the associated risk?" – codingoutloud Feb 25 '12 at 5:07
I would add that one does not neccersarrily need to buy cert authority signature if one gives a self signed cert to the admin of the other server via a side channel (if the companies are setting up private communications channels in some sort of simple partnership). If it's a lot of different servers calling the endpoint like for twitter then this becomes unfeasible to manage in most cases (it can be done). – ewanm89 Feb 25 '12 at 12:31
Fair point @ewanm89. I will add also that the cash outlay of a commercial cert ($100?) can be dwarfed anyway by other staff costs (dev, test, ops - depends # machines & complexity of apps & APIs). It is this human cost (perhaps better thought about as "complexity") that I am guessing these high profile sites assumed to be not worth forcing on their customers. – codingoutloud Feb 25 '12 at 14:48
The simple point I was trying to make was does the cost of losing information out way the cost of securing it. In most cases, it's far cheaper to secure it in the first place than to deal with disaster recovery (including tarnished reputation) if data is breached. – Colette Chamberland Feb 25 '12 at 16:26

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.