Using ziti to provide protection when consuming public APIs

I am working through a scenario at the moment where an application calls a public (non ziti) API.

From within the Ziti overlay

there is no inbound internet traffic because it only allows authorised identities

However, in the case a call needs to be made from an external public API,

the call would be made from within the ziti network

In this case, is it possible that vulnerabilities from within the external API providers can be used to then infiltrate the ziti network?

Would you put in an additional layer of protection.. like a reverse proxy to act as a ziti DMZ.. just in case malicious attackers found a way to access a ziti host?

If you were to do this.. how would you modify the following to implement this?

Any tips?

If the call is made “from within the Ziti network” to the External API server, no inbound port is needed for the Zitified App server.

1 Like

Thanks for the clarification… I still have one lingering question.

Is it possible that the external API can be used as a source of attack… even if the request is triggered with no inbound ports open?

Maybe. I don't know anything about the API or the provider. You'll want to investigate how that provider addresses security and if you are comfortable with it (and maybe recommend they run over OpenZiti :wink: )

1 Like

Is there anyway you can put in contingency… using the super power of ziti… as a just in case precaution?

Not that I can think of. Your app is making a connection to something not over Ziti, so I think it’s up to you/your app to “figure it out” (in conjunction with security provided by the API provider). Anything else would be 3rd party provided (I.e., not provided by Ziti)

1 Like

Thanks for the details.. I followed this up with a friend.. who mentioned that this is really a man in the middle attack.

In this case, maybe all that is needed is a different perspective.. as a recent video was created that talks about how to setup a LAN gateway

So.. maybe.. rather than accepting a 3rd party API over the internet using https.

its better to setup a LAN gateway.. to make it more secure

Does this make sense? or.. is there a better way to approach this?

Not that I have ever heard of.

It could send you back rubbish which might cause your app to work in an unexpected way, but that is what input validation should resolve. So, for example, say you asked an API endpoint for some SQL query (hyperthetical only right), and then you just blindly execute it, that is where the problem exsts. What if it sent you a truncate command! API endpoints are generally JSON/XML and maybe some binary data that you would sanitise before using it and validate it.

As for MITM (Man In The Middle), this is hard to prevent unless they put measures in place. If it is a cloud API endpoint you are probably traversing through a load balancer, which basically is a MITM device anyway.

1 Like

I was reading this thread to make sure it was complete when I read something that made me want to reply.

This is actually quite easy to prevent. TLS does this and OpenZiti also does this out of the box by using end-to-end encryption. A load balancer is not automatically a person-in-the-middle (PITM). It's only a PITM if the load balancer (or router, or 'whatever' is in the middle) actually terminates TLS. Lots of load balancers do not do this. Lots of them cannot do this. It really all depends on what and how you're doing it.

OpenZiti goes out of its way to make sure PITM attacks are totally impossible. MTLS, end-to-end encryption, then whatever encrypted protocol you layer on top of all that makes PITM totally impossible.

Remember it's only a PITM if the piece in the middle can read the traffic. OpenZiti (and just regular TLS) make that impossible.

That said - if you put OpenZiti into a place that has ACTIVE PITM going on (Fortigate, etc). OpenZiti will not work. We won't pass your traffic if you're being PITM'ed.

1 Like

I'm abit late into this, but hopefully I can add some extra color.
First, saying I'm not the biggest security expert (so far an enthusiast), however everytime I do have questions about the solution I'm integrating/creating/etc I normally use a Threat Modeling Tool to know the different possibilities. With that in mind if we put your diagram into one of those tools you'll see that basically you may have 3 different attacks (assuming you're using HTTPS):

Now, is it possible to get attacked? Well as some said before depends. If the public API is a trusted one, it may get difficult (unless a full supply chain attack, and even in that scenario for sure any monitoring tool can detect "faulty data" reducing you MTTD), as the only way to use it as a source is having control of the responses and try to break your code, with some flaws in how you handle the response.

Now, even using OpenZiti you can still getting the benefits of network segregation. You can put the endpoint that going to make external calls in you "DMZ" and only provide access to your trusted network via Ziti. If by any reason you found that the "External API" is attacking the attack surface will be dramatically reduced. And if you zitified the piece of code that is making those connections, you can even isolated even more.

1 Like

Thanks for sharing… very helpful. I can see the value now, especially in reducing the surface area of the attack zone. You can probably try with traditional approaches, but you will experience diminishing returns on effort very quickly… because it either takes too much effort… or is too fragile.

However… with Ziti… it makes what was really hard… quite straight forward with the right planning…

Awesome.
Scott