4

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.

Google Maps has an API key that you need to expose in public - it lives in the JavaScript - and access to the service can be locked down by the hosting domain name (REFERER header) - so this doesn't need (and doesn't require) SSL. (This is most commonly used in an end-user-to-server model, but it is at least possible to think of this in server-to-server scenario. We can all at least understand the logic.)

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

Improve this question
2
  • 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
    Commented Feb 25, 2012 at 2:14
  • 1
    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
    Commented Feb 27, 2012 at 14:32

5 Answers 5

Reset to default
5

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

Improve this answer
4
  • 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
    Commented Feb 25, 2012 at 2:10
  • 2
    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
    Commented Feb 25, 2012 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
    Commented Feb 25, 2012 at 12:31
  • 2
    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
    Commented Feb 25, 2012 at 16:26
5

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
Improve this answer
5
  • 1
    +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
    Commented Feb 25, 2012 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
    Commented Feb 25, 2012 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
    Commented Feb 25, 2012 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
    Commented Feb 25, 2012 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
    Commented Feb 26, 2012 at 18:16
5

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.

Improve this answer
1

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.

Improve this answer
1
  • What if there was a private VPN or dedicated circuit in the B2B connection? (cc: also @Thomas Pornin)
    – makerofthings7
    Commented Apr 22, 2013 at 13:59
0

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .