Serverless DTLS(proxylity.com)
11 pointsby mlhpdx6 hours ago3 comments
  • freeone30003 hours ago
    Like. It’s already over the internet. If I have to send it unencrypted to you, why not just send it unencrypted to the destination? The cat’s already out of the bagel, so to speak.
    • mlhpdx3 hours ago
      DTLS is TLS encrypted, so I think you're talking about plain UDP as the transport? There are use cases for that, for sure, but more for protected content over WireGuard or DTLS (we support both 1.2 and 1.3).
  • Fischgericht5 hours ago
    "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?

    ...What? Why would anyone do that?

    I don't get it.

    • mlhpdx5 hours ago
      I understand the concern. It can be a great convenience to not run the servers yourself, as people have been doing for decades with respect to websites, apps and APIs. That's essentially the same model, with the host terminating HTTPS for you.

      > ...lossy UDP

      All networks are lossy, and all transports. The difference between UDP and TCP based transports is who decides how to handle it. With UDP the application developer decides; with TCP (and QUIC) the protocol decides. More and more projects are taking-on the reliability decision, for a lot of reasons that trace back to this difference.

      > ..some random guys on the Internet

      Essentially; and that's how everything starts. We've been in production since early last year and have maintained >99.99% availability. We're a certified partner with AWS, and have "qualified software" (it passed their security review), and our security posture report is available from AWS Marketplace. We aren't SOC-2 audited yet because we want to do it right rather than pay for a rubber-stamp report, and that takes time and a lot of money.

    • ranger_danger25 minutes ago
      Most traffic on the Internet flows unencrypted through a portion of some reverse proxy MITM-as-a-service provider's gear like Cloudflare, Cloudfront, Akamai etc.

      You can't proxy TLS for people without having the ability to see the decrypted data somewhere inside the server software/RAM. They (or a government) may or may not be looking at it or storing it, but the possibility is there.

  • mlhpdx6 hours ago
    Founder of Proxylity here. I'm happy to answer questions about how this works, why we built it, and where it is (and isn't) a good fit.
    • oarsinsync5 hours ago
      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?

      • philsnowan hour ago
        > It's unclear what the value proposition is, paying for a MitM proxy.

        Is that not exactly cloudflare?

      • mlhpdx5 hours ago
        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.