Ask HN: Is a self-MitM HTTPS proxy that injects API keys useful?

https://news.ycombinator.com/item?id=34635129

by stanleydrew • 3 years ago

2 5 3 years ago

news.ycombinator.com

In the course of working on a side project, I've built a small HTTPS forward (i.e. egress) proxy to sit between my application servers and all external HTTP APIs. My proxy injects API keys into requests so that my application doesn't have to think about that.

My question is whether this is useful to anyone else or not? There are perhaps other useful things you could do with it, like add some observability features?

Thanks in advance for any feedback.

jonahbenton• 3 years ago

Typical use cases for tools like this are:

- comply with egress security policies more generally

- comply with rate limits and meters for costly APIs

- monitor outgoing request payloads so nothing sensitive goes over the wire

- caching and deduping large responses

- act as the starting point for adding crawling type workloads

These tend to be pretty limited and special case, and there are lots of other ways of solving each, but sometimes an egress proxy is the thing.

tony-allan2• 3 years ago

MITM is aways wrong and dangerous!

I would create a separate protected API that has an additional header such as:

  Forward-To-API: database-prod

And have that service lookup the URL and credentials in a secure database and create it's own request to the external service. Even better it could also be your audit log.

The Forward-To-API header would be stripped and the rest of the query would be passed through.

-- This is so obvious that it must already exist!

tony-allan2• 3 years ago

Hard coding credentials is wrong but here is an example:

http://shairosenfeld.blogspot.com/2011/03/authorization-head...

akerl_• 3 years ago

You’ve just described an HTTP-based MITM.

stanleydrew• 3 years ago

I did start out this way, but I was trying to make something that would achieve the goal without requiring any changes to my application code. Setting the HTTPS_PROXY environment variable on the app server and adding the internal CA cert to the set of trusted authorities s is all that's required to get it working now, which is nice.

The thing you've described is still a MitM (the "protected API" can still see all of the request contents on their way to the destination).

Ask HN: Is a self-MitM HTTPS proxy that injects API keys useful?

Related Stories