I am trying to understand how underlying ziti works technically. I tried looking into the code and understood that the communication between routers happens via channels.
I also assume that the communication between the SDK(on the client) and the first router in the circuit also happens as a channel.
I wanted to understand on how TLS does not break on such an architecture?
Is the channel just a wrapper to carry any data. If so then how does the terminator know what to do with the data ?
I am also trying to understand on how this setup would work if the server had client certificate authentication enabled ?
While others can give much better answers, this is a great place to start - Connection Security | OpenZiti. You see there are 2 encryptions in the data plane, mTLS between each hop, and E2EE from ingress to egress endpoint.
Hi @adithya, welcome to the community and to OpenZiti!
Fundamentally, OpenZiti is an overlay network that takes bytes from one identity and sends them to another identity, quickly, securely and reliably. You mention TLS but I presume you're also thinking about our tunneling tech that transports classic underlay traffic from one location to another. Those tunnelers are specially built apps that are capable of capturing traffic, encapsulating the traffic in a slim protocol so the overlay can route the traffic to the proper identity, and then if there's a tunneling app on the other side, offload the traffic towards the final destination.
Yes it's just a wrapper to carry data, and that is why/how TLS doesn't break. The terminator knows what to do with the bytes because in this scenario it's a tunneler app and those apps have "config" data attached to each service indicating where the traffic is to be sent. If you look at examples in the docs or here on discourse, you'll find "host.v1" config referenced which is what a tunneler uses to know what to do with the data when it arrives at that tunneler.
Since OpenZiti simply transports bytes with no manipulation, it'll work perfectly fine. Ssh'ing through an OpenZiti tunnel works as expected, as would HTTPS with client/server certificate auth (mutual TLS)
I have tried the demo echo client and server. As per my understanding
The client has the SDK and the the service (echo server) is unmodified
The client(SDK) communicates with the controller and gets a session and a edge router to communicate with
The client(SDK) communicates with provided edge router.
2.1) client(SDK) creates a channel connection with the edge router
2.2) The edge router accepts the channel and starts TX and RX thread for the channel
The Edge router knowing that it is a terminator to the service, dials to the service and obtains a connection.
Once this is established, the data flows through the established channel. The data that the actual client sends is agnostic to the ZITI channels.
Am I correct with the above understanding ? So the TLS communication is untouched. The client hello from the actual client is sent only after the above process is complete ?
I'm actually not certain about the exact sequence, but that's effectively the case yes. If the server were to provide a TLS listener, then the TLS handshake is untouched and will complete accordingly. One thing that might not be obvious, but in the situation you outlined using the sdk echo client/server, OpenZiti has end-to-end encryption enabled by default so that communication is already encrypted between the client and server, even though the listener is not a TLS listener.
If you had an HTTP listener on the sever side, and used a tunneler on the client side, that would be a good use of a TLS(https) listener. In that case, the comms from the browser to the tunneler would be encrypted as well, which would not be the case if using http only. Without https, the traffic before being intercepted by the tunneler would be http.
Hi, I'm not the original poster but was also puzzled around this subject have questions.
If a client uses a ziti tunnel to connect to a server. Will that mean the network traffic between the client and the server in the tunnel will be encrypted?
Is this encryption similar to the encryption of SSL connections when making a request to an https url?
If this is the case, is it still beneficial to use https connections within the tunnel?
Is it safe to rely on ziti encryption in the tunnel and use http within the tunnel?
Also we are currently exposing our app via a load balancer that accepts a TLS encrypted connection, it adds a forwarded HTTP header to the request, such as X-Forwarded-Proto: https. Is it possible to have the ziti router also forward these same header? (I'm assuming the ziti router is the one sending the traffic to the host
If a client uses a ziti tunnel to connect to a server. Will that mean the network traffic between the client and the server in the tunnel will be encrypted?
You need to define "client". If the client is a browser, then no. If the "client" means the ziti-edge-tunnel then yes. In the case of a browser being the client, then the leg from "client" to the intercepting tunneler (usually entirely local to the machine) is before hitting OpenZIti. That means it's before OpenZiti's end-to-end encryption. In that case, if you're using http (not https), a malicious actor able to sniff packets on that machine would see the http traffic in the clear. Many people consider local http traffic to be secure, but it depends on your own definition.
"similar" is a fine way to put it, yes
Generally speaking, I'd say it depends on your specific definition of safe/secure. To use the example from before, if a bad actor is able to install a packet capture application and you use http-only with a browser, then that might not be good enough. You might ALSO want https to cover that small window. However, the OP was asking about a truly application-embedded zero trust. The client in that case is NOT a browser, it's a go program and the traffic is terminating inside another go program on the server side. In that specific example, https is entirely worthless and unnecessary overhead. So it does depend on the exact use case.
I feel like I've answered this in the previous answers.
No. OpenZiti doesn't have a way to operate at layer 7 to add HTTP headers. It might be an interesting extension to the host.v1 config (or perhaps a different config type entirely) to do something like this, but it's not on the roadmap that I know of yet (someone else can correct me if I'm mistaken there).
Since you mentioned about Layer 7, I would like to clarify one more thing
Is it correct to say that the Ziti overlay deals with traffic from the transport layer and anything above it is an abstraction to it.
I see all terminators/ Exgress implementations dealing with transport layer protocols.
Is my assumption correct with that ?
If that is the case, then another way to put why SSL doesnt break is because the SSL layer in the network stack has been abstracted to open Ziti
I wouldn't describe it that way. It makes it sound like OpenZiti will manage/deliver server certificates to client connections but that's not the case. The target server can still serve it's own tls-secured connection over OpenZiti. Also this wording implies using a tunneler that's concerning underlay traffic to overlay traffic to me.
TLS doesn't break because the OpenZiti tunnelers intercept and transport the raw bytes received without decrypting the stream.
