Try a Tor hidden service, configured with the low-latency/lower-privacy settings. It is slower than many of the other solutions, but very reliable and very simple.
I have worked with implementations of an online digital goods marketplace built by someone who was clever but had no notion of formal accounting, ledgers, etc. Their implementation worked, but was only just barely adequate and would have been more useful with a chart of accounts. Prototyping against an API like this would have been an informative exercise for them and probably saved a lot of time.
Also impossible to properly firewall. By design you give the whole world the opportunity to send you traffic to forward. This does not work for any kind of professional deployment.
This depends on what you mean by "properly" and "impossible" and "professional" and "forward".
Many professional name-brand corporations use Tor daily.
The only ports opened are those you configure to have onion services. Port limiting is one of the major features of firewalls.
You don't get to control source IP ranges, but those aren't generally trustworthy on the open internet anyway.
Also, the traffic isn't "forwarded" -- hidden services shouldn't be run on a relay, actually, so you're not forwarding anybody's traffic but your own.
Also, barring the recent attacks on discovery of onion services, connecting to a tor onion service allows you stronger security guarantees and MitM defense than TCP+DNS+IP routes.
> You don't get to control source IP ranges, but those aren't generally trustworthy on the open internet anyway.
IP ranges are just another layer of security controls. They may be easily spoofed one way. They may be even spoofed in a two-way communication in some situations. But it doesn't mean it's a useless control. If you can filter more traffic you should and Tor makes that hard to achieve.
> Also, the traffic isn't "forwarded" -- hidden services shouldn't be run on a relay, actually, so you're not forwarding anybody's traffic but your own.
Even if you don't participate in the relay of traffic, you're still connecting to the nodes that can send you anything and you need to process it, because it could be traffic addressed to you. I said you may get traffic to forward (or random traffic in general) - it doesn't matter if you're going to actually do it or not. I wouldn't be comfortable running that service. This does not help to reduce your attack surface.
> allows you stronger security guarantees and MitM defense than TCP+DNS+IP routes
It's a tradeoff. You're substituting tested routing mechanism should not be trusted (so we do the AuthN/Z in higher layers), for a relatively new routing mechanism which in duplicates some of the AuthN checking, but at the same time exposes and advertises a new service on your network. You may think it's better, I would disagree.
If I understand what you mean correctly, you end up with just a private onion network. What's the gain in that case over setting up a dedicated VPN network instead?
I generally have the same feeling, though https://github.com/go-gorp/gorp has worked very well for most of the database-heavy Go projects I've worked on over the last few years. It is just enough abstraction to be convenient and consistent and rarely gets in the way.
