> The HTTPS trigger is intercepting all my traffic?
> No, your data are safe if your server support HTTPS protocol. All the data exchanged between your server and your clients is encrypted and not accessible by us.
Unless there's an IP allocated to each user, I don't think this is accurate. With SSL, the HTTP headers are encrypted, so there would be no way to know where know where to route the request without first decrypting the data, and thus having access to the data.
SNI was added on top of TLS to allow one server to serve multiple certificates. SNI is different than the hostname header, and in fact no headers are available until the traffic is decrypted post-handshake, which Hakuna can't see if it's not terminating TLS. But SNI lets the hostnames be available outside the encrypted TLS stream on hello.
From a comment above, it seems like Hakuna requires a FQDN of each AWS server it's serving traffic to, so if you're not MITM'ing traffic, this FQDN I'm guessing sits in with SNI and is used for routing rather than serving certificates. I don't think I've personally dealt with this use case on SNI, but it makes sense.
The whole header is encrypted, including the Host header and request line. Certificate selection and routing relies on SNI[1]. The server name in the TLS client hello message is almost always, but not necessarily, a copy of the value of the Host header field.
> The HTTPS trigger is intercepting all my traffic? > No, your data are safe if your server support HTTPS protocol. All the data exchanged between your server and your clients is encrypted and not accessible by us.
Unless there's an IP allocated to each user, I don't think this is accurate. With SSL, the HTTP headers are encrypted, so there would be no way to know where know where to route the request without first decrypting the data, and thus having access to the data.