4 ms·

> 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

> 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

Fischgericht 23d ago
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.
- ranger_danger 23d ago
  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.
  - Fischgericht 23d ago
    Then probably a hybrid approach would make sense. Public non-confidential data can be Man-in-the-middled, but confidential data must be e2ee.
    - mitxela 22d ago
      that doesn't make sense. if you have E2EE working you might as well use it for everything.
- mlhpdx 21d ago
  While small devices can technically do TLS, it’s a significant battery drain because of the acknowledgements (keeping the radio on while waiting). Anything battery powered is likely to eschew TLS for DTLS 1.2 + CID or TLS 1.3 with early data. FWIW, Proxylity supports plain UDP as well as DTLS so it’s possible to build a paas-through proxy for DTLS to Lambda, for example. But then you’ll need to implement DTLS in Lambda. People have done it, but it’s a heavy lift. The idea with the DTLS support is protecting content in traffic, and the handling it in your own AWS account. For some cases it isn’t acceptable to have Proxylity or AWS to have any chance to seeing the data. But for the most it’s not a problem and the convenience of what the service provides is worth it. But I hear the concern. I guess I just expect folks will make good decisions for their use cases.

Fischgericht 23d ago

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.

ranger_danger 23d ago
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.
- Fischgericht 23d ago
  Then probably a hybrid approach would make sense. Public non-confidential data can be Man-in-the-middled, but confidential data must be e2ee.
  - mitxela 22d ago
    that doesn't make sense. if you have E2EE working you might as well use it for everything.
mlhpdx 21d ago
While small devices can technically do TLS, it’s a significant battery drain because of the acknowledgements (keeping the radio on while waiting). Anything battery powered is likely to eschew TLS for DTLS 1.2 + CID or TLS 1.3 with early data. FWIW, Proxylity supports plain UDP as well as DTLS so it’s possible to build a paas-through proxy for DTLS to Lambda, for example. But then you’ll need to implement DTLS in Lambda. People have done it, but it’s a heavy lift. The idea with the DTLS support is protecting content in traffic, and the handling it in your own AWS account. For some cases it isn’t acceptable to have Proxylity or AWS to have any chance to seeing the data. But for the most it’s not a problem and the convenience of what the service provides is worth it. But I hear the concern. I guess I just expect folks will make good decisions for their use cases.