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.
Comments
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.