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