[tptacek]

We don't need it, nor does anyone who can set up a WireGuard tunnel between their app instance and their proxy instance, or any other IP-level secure channel, but if you really cared you could write the TLS termination logic to make this work --- every MITM testing proxy has it, and there's Go code to do it. It's just pointless in our environment.

The attacker can currently do anything with the secret by interacting with the sites allowlisted for that secret, but they can't exfiltrate the secret, which is the goal of this security control. You can do better, if you like, by further locking down which endpoints they can call, but the wins past "log carefully and no exfiltration" get smaller and smaller, and at some point you're burning time that can be spent more productively on unrelated controls.

If you get what it's doing, you get it. :)

[lll-o-lll]

I think I get what you’re doing, I’m just struggling to see the significance. The OAuth2 token is supposed to only provide the access the client needs. So you don’t get the raw token and instead need to interact via the proxy, so what? What have you blocked the attacker from doing? [edit] I do see intrinsic value in being able to prevent direct access to the tokens and secrets, it just doesn’t look the game changer implied here. Not to me at least.

[tptacek]

None of this is a game changer. It's just a way to handle secrets and use them with code driven by Rails without giving Rails access to the secret bits in its memory.

[chrismsnz]

> What have you blocked the attacker from doing?

Not blocked necessarily, but if they want to leverage a stolen token, they’re now forced down a more difficult and highly visible pathway.

You can imagine anomaly detection along the lines if “hey your rails app just made a type of request that it has never made before”, but even just monitoring the metrics of the proxy could tip you off if something is going on.