"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?
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.
I know it is a marketing thing, but I simply dislike someone offering a server calling it serverless.
That being said: OK, so basically your service is to be treated as an Internet overlay. That can be fine. But then you should point the advantages of that. Using anycast and your internal peerings, are you better at routing packets than BGP on the open Internet? Are you able to hole-punch NAT to connect two NATted endpoints?
If so, this would be a service I might want to use.
As others have pointed out: End-To-End-Encryption with DTLS is possible by using SNI inspection on the Client Hello packet. You either do that and advertise this as a secure service OR you say "this is unreliable unencrypted transport, do your own thing over it".
I just don't think you are explaining your value proposition properly.
We had CDNs for ages. They are fine for static content. But no, you should not proxy any confidential or personal data unencrypted through a third party, that is crazy. That stuff must be end-to-end encrypted between you and your peer.
I think the marketing terms here are blurring the vision of developers. You need to understand what you are doing. "Can this data be handed over to a man in the middle?" must be something you actively think about, then making a decision.
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.
You can. What you do is take the Client Hello packet, and inspect the public SNI field. This will show you the destination to proxy to. Your forward to that server, and that server then completes the handshake.
No matter if you are using TLS over TCP (or HTTPS) or DTLS - end-to-end-encryption can be kept up simply by proxying on the first step of the Handshake.
I should have clarified... when I said "proxy TLS" I meant while retaining the typical features that reverse proxy providers offer like those I mentioned here: https://news.ycombinator.com/item?id=49662319
If for example Cloudflare decided to offer this SNI-based TLS passthrough, they could no longer give you adequate DDoS protection, caching, analytics etc.
I disagree. What you do (well, and what I do in my code) is this: You cache the original IP packets containing the Client Hello. You inspect those packets. And you make your DDoS protection etc based on this. And if you decide the packet is OK forwarding, only then you replay the original IP packets to the destination.
I know that you can not inspect content this way. But there simply are situations where content SHOULD NOT be inspected.
Why would an origin be unable to speak TLS? An ESP can speak TLS. A RP2040 can speak TLS. My watch can speak TLS. TLS even is implemented on the Commodore 64 by now.
For the features you mention: Yes, you need meta-data for this. But you don't need to see the payload, a picture of my naked 4 year old kid.
I didn't mean it so much as a physical constraint, but an operational one.
Not everyone wants to (or their policy allows them to) manage TLS certs directly on their origin servers, and some services only allow plaintext HTTP origins, like AWS ALB/ELB. In that particular case it's "ok" because the load balancer is placed inside your VPC, so cleartext traffic is not visible to other customers or networks.
Also, ESNI/ECH would make TLS passthrough problematic.
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.
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).
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.
"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.
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.
I know it is a marketing thing, but I simply dislike someone offering a server calling it serverless.
That being said: OK, so basically your service is to be treated as an Internet overlay. That can be fine. But then you should point the advantages of that. Using anycast and your internal peerings, are you better at routing packets than BGP on the open Internet? Are you able to hole-punch NAT to connect two NATted endpoints?
If so, this would be a service I might want to use.
As others have pointed out: End-To-End-Encryption with DTLS is possible by using SNI inspection on the Client Hello packet. You either do that and advertise this as a secure service OR you say "this is unreliable unencrypted transport, do your own thing over it".
I just don't think you are explaining your value proposition properly.
You're basically asking "why would anyone use Cloudflare?"
Or "why aren't you just saying what this is?".
We had CDNs for ages. They are fine for static content. But no, you should not proxy any confidential or personal data unencrypted through a third party, that is crazy. That stuff must be end-to-end encrypted between you and your peer.
I think the marketing terms here are blurring the vision of developers. You need to understand what you are doing. "Can this data be handed over to a man in the middle?" must be something you actively think about, then making a decision.
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.
You can. What you do is take the Client Hello packet, and inspect the public SNI field. This will show you the destination to proxy to. Your forward to that server, and that server then completes the handshake.
No matter if you are using TLS over TCP (or HTTPS) or DTLS - end-to-end-encryption can be kept up simply by proxying on the first step of the Handshake.
That is the correct way how to do it.
I should have clarified... when I said "proxy TLS" I meant while retaining the typical features that reverse proxy providers offer like those I mentioned here: https://news.ycombinator.com/item?id=49662319
If for example Cloudflare decided to offer this SNI-based TLS passthrough, they could no longer give you adequate DDoS protection, caching, analytics etc.
I disagree. What you do (well, and what I do in my code) is this: You cache the original IP packets containing the Client Hello. You inspect those packets. And you make your DDoS protection etc based on this. And if you decide the packet is OK forwarding, only then you replay the original IP packets to the destination.
I know that you can not inspect content this way. But there simply are situations where content SHOULD NOT be inspected.
Actually, you could proxy based on SNI alone. They don't, because they want to intercept all your traffic so the NSA gets a copy.
> Actually, you could proxy based on SNI alone
If you assume the origin speaks TLS and holds the cert/private key, and isn't using ESNI/ECH, then I suppose in a limited way it's possible. But...
> because they want to intercept all your traffic so the NSA gets a copy.
I don't believe that is the reason. I believe it's for features.
You need actual TLS termination to do most things CDNs and reverse proxies offer, such as:
- caching and compression
- WAF / bot detection
- URL-based routing
- header manipulation and redirects
- application-layer DDoS filtering
- analytics
- edge functions and content transformation
Why would an origin be unable to speak TLS? An ESP can speak TLS. A RP2040 can speak TLS. My watch can speak TLS. TLS even is implemented on the Commodore 64 by now.
For the features you mention: Yes, you need meta-data for this. But you don't need to see the payload, a picture of my naked 4 year old kid.
I didn't mean it so much as a physical constraint, but an operational one.
Not everyone wants to (or their policy allows them to) manage TLS certs directly on their origin servers, and some services only allow plaintext HTTP origins, like AWS ALB/ELB. In that particular case it's "ok" because the load balancer is placed inside your VPC, so cleartext traffic is not visible to other customers or networks.
Also, ESNI/ECH would make TLS passthrough problematic.
Then probably a hybrid approach would make sense. Public non-confidential data can be Man-in-the-middled, but confidential data must be e2ee.
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.
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).
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.
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.
> It's unclear what the value proposition is, paying for a MitM proxy.
Is that not exactly cloudflare?