"Clients establish a DTLS 1.2 or DTLS 1.3 session with the Listener's assigned domain and port."
"Every DTLS Listener receives a server certificate and private key managed by Proxylity."
I don't get it. Why would anyone want to send all their private information unencrypted to your serverless server?
"Get fired from your Organization for sending company or private data unencrypted to some random guys on the Internet" as a Service? Based on lossy UDP?
You provide a DTLS to clear-text proxy service, for applications where the client supports DTLS, but the server does not (or vice versa)?
Yeah, why did you build this? It's unclear what the value proposition is, paying for a MitM proxy. It effectively means it cannot be used with secrets, without trusting y'all to not be snooping?
Your summary is about right, but the use case is simply not wanting to run always-on servers around the world (we have anycast IPs backed by handlers around the world). So it's convenience and scale first, and wanting to build with event-driven architectures second.
Yes, your point on security is correct. Since our service terminates the DTLS connection we could see the cleartext (just as any gateway service does, like AWS API Gateway, etc.). We don't touch it except as strictly needed to pass it to the configured integrations.
EDIT: FWIW, using a plain UDP handler you could implement DTLS handling that runs in your control, in which case payloads would be opaque to us. That's a bit of an effort, though. We were asked for this, so we built it.
"Every DTLS Listener receives a server certificate and private key managed by Proxylity."
I don't get it. Why would anyone want to send all their private information unencrypted to your serverless server?
"Get fired from your Organization for sending company or private data unencrypted to some random guys on the Internet" as a Service? Based on lossy UDP?
...What? Why would anyone do that?
I don't get it.
Yeah, why did you build this? It's unclear what the value proposition is, paying for a MitM proxy. It effectively means it cannot be used with secrets, without trusting y'all to not be snooping?
Yes, your point on security is correct. Since our service terminates the DTLS connection we could see the cleartext (just as any gateway service does, like AWS API Gateway, etc.). We don't touch it except as strictly needed to pass it to the configured integrations.
EDIT: FWIW, using a plain UDP handler you could implement DTLS handling that runs in your control, in which case payloads would be opaque to us. That's a bit of an effort, though. We were asked for this, so we built it.