We use a well-known service provider/API management gateway that sits in front of our RESTful APIs providing key management functionality etc. etc.
The service provider was running the dodgy OpenSSL version.
None of our web services have SSL enabled, though we use API keys to throttle API access, measure usage.
Traffic obviously arrives at the service provider's web servers which acts as a proxy and talks to our web servers.
If the infrastructure of the service-provider is such that many customers share a web-server instance and at least one customer has SSL enabled, then does that expose all customers, including those not using SSL, to the threat?
Apparently, the bug will not allow memory to be read outside of the process address space, so the answer is hinged around how the proxy web server runs a process per customer.
Has anyone covered this scenario?
I am a programmer working for APIs-r-Us. Instead of running a separate website and process for each of my thousands of customers, sharding and all that, I write the proxy system as a single stateless web service running in a website instance handling all requests to apisrus.net
My service handles both SSL and non-SSL traffic.
My service uses some rules based on the URL to route requests to different customer web services. API consumers talk to my service and my service talks to the customer's real service, payloads can even be converted or augmented by my service before being sent back to the API consumer.
Loaded into process memory are the various routes and credentials to access my customer's APIs, as well as the keys and hashes use to authenticate the users.
All traffic is going via a single process, so if this process memory is compromised, then all customers are compromised.
I'm assuming that OpenSSL is loaded into the address space of the website (and not the server pipeline).