search

interledger4j / ilpv4-connector

An ILPv4 Connector implemented in Java
https://java-connector.ilpv4.dev
Apache License 2.0
19 stars 10 forks source link

Secure SettlementEngine<->Connector API HTTP calls. #226

Open sappenin opened 5 years ago

sappenin commented 5 years ago

Currently the XRPL Settlement Engine doesn't use any security for its HTTP calls (to the Connector or vice-versa), so these endpoints are unsecured for now.

In Rust and Javascript, the API endpoints to support SE interactions are actually operated on a different port from the main /ilp endpoint, so presumably the idea there is that these endpoints would not be exposed to the outside world due to not exposing those ports.

However, in a production deployment, even this type of deployment would require these endpoints to be secured internally (to guard against internal bad actors), so we need to have the SEs implement some sort of security protocol (e.g., see the suggestion in https://github.com/interledger/rfcs/pull/531).

This may require some updates to the RFC, but probably just means we should add secure calls to the XRPL Settlement Engine project in a manner that makes sense for a typcial operation (E.g., see some suggestions in https://github.com/interledger/rfcs/pull/531)

gakonst commented 5 years ago

Couldn't you run the API behind an authenticated proxy? That was my initial rationale for splitting it to a separate port.

sappenin commented 5 years ago

Couldn't you run the API behind an authenticated proxy?

Yes, absolutely.

This issue is more for how to secure the endpoints internally. There are a million ways to do this, so this maybe isn't a pressing issue today (and probably deserves more conversation with some Ops people). However, as an example, if an attacker gained access to your internal network, we want more layers of security to prevent that attacker from having free reign on the SE and/or internal connector settlement endpoints.