A Primer on Proxies

https://blog.cloudflare.com/a-primer-on-proxies/

by jgrahamc • 4 years ago

142 25 4 years ago

blog.cloudflare.com

ignoramous2• 4 years ago

Tommy Pauly's EPIQCon 2021 keynote QUIC at Apple is pretty interesting as well: https://www.youtube-nocookie.com/embed/nP1yzxHcgeM

What if we wanted to proxy QUIC? What if we wanted to proxy entire IP datagrams, similar to VPN technologies like IPsec or WireGuard? This is where MASQUE comes in.

Ref: https://ietf-wg-masque.github.io/draft-ietf-masque-connect-i...

eptcyka2• 4 years ago

Thanks for the link to the presentation, I was just debugging some weirdness with PF and unblockable QUIC traffic on macOS Monterey.

ignoramous2• 4 years ago

Np. But you must fills us in: Why was iOS QUIC unblockable at the firewall? And how did the presentation help?

jgrahamc2• 4 years ago

The follow up is also a good read: https://blog.cloudflare.com/unlocking-quic-proxying-potentia...

ThePhysicist• 4 years ago

In my experience HTTP/2 doesn't boost proxy performance significantly, at least for HTTPs workloads. Normally the client sends a single CONNECT [hostname] request to the proxy and after that the proxy just forwards TCP packets on that connection, which is nothing that HTTP/2 can improve. A client can of course use the same HTTP/2 connection for multiple CONNECT requests, but opening several data streams to the proxy in parallel isn't much more costly as those streams tend to be long-lived and will often carry multiplexed HTTP/2 connections themselves, so further multiplexing on the proxy level often has little effect (in my experience at least).

Regarding QUIC/MASQUE it's still difficult to find any clients that support it. I think Chrome supports using QUIC to connect to a regular HTTP CONNECT proxy, but I don't know of any browsers that have even experimental support for MASQUE as of now. Will be pretty great tough I think once it's supported more widely.

Liuser• 4 years ago

Normally the client sends a single CONNECT [hostname] request to the proxy and after that the proxy just forwards TCP packets on that connection, which is nothing that HTTP/2 can improve.

Trying to test my understanding - Does the CONNECT HTTP protocol need to match the underlying payload protocol. Eg After CONNECT over HTTP/1.1 tunnel is established it’s still possible for the client to still use HTTP/2 with the upstream server for its underlying payloads correct?

My intuition is that it doesn’t need to match because the proxy has no way to know what http protocol is being used when the workload is encrypted.

simmervigor2• 4 years ago

The vanilla CONNECT method is an instruction to open a TCP connection to the target server. What is sent over that is entirely up to client and target the server it doesn't need to match. Its often TLS carrying HTTP but it could be anything.

The proxy could inspect the traffic it is carrying and try to enforce some access control or policy. However, the use of TLS or other encrypted protocols limits the ability to do see what is happening. Then you get into a different logical layer of whether there is MITM happening, but that is tangential to conventional use case for HTTP proxy.

latchkey• 4 years ago

It would be nice if there was a way to more easily debug caching issues with CF workers being used as proxies. There is very little visibility into how headers affect things and it is poking in the dark to make it all work.

matt-attack• 4 years ago

Is it ok if I don’t like the term “reverse proxy”?

I find it entirely confusing and non-intuitive. I put it up there with idiotic terms like “OTT” which AFAIK just means “connected to the internet”.

jgrahamc2• 4 years ago

Has always bothered me also, but that's the industry term so we are kind of stuck with it.

simmervigor2• 4 years ago

Proxy components are officially called Intermediaries in thr HTTP semantic specification; see https://httpwg.org/http-core/draft-ietf-httpbis-semantics-la....

Intermediaries can have different purposes. The official alternative to reverse proxy is "gateway", which is unfortunately overloaded with other kinds of gateways in networking.

Naming things is hard. Reverse proxy isn't great but all things considered is unique enough to allow folks to discriminate the sort of HTTP proxying that is happening

yjftsjthsd-h• 4 years ago

What would be a more intuitive term for it?

unethical_ban• 4 years ago

Server-side proxy, or inbound proxy, perhaps.

whoknew11223• 4 years ago

I always enjoy the articles Cloudflare publishes. I still really don't like the company, but good job to the individuals who wrote the primer.

datalopers• 4 years ago

I still really don't like the company

Is that because they provide TLS termination for an increasingly large chunk of all internet traffic?

whoknew11223• 4 years ago

I really don't want to get sidetracked into a political or philosophical conversation. But to me, a policy of content neutrality is tacitly supporting extremist content. Cloudflare has to be dragged kicking and screaming before it stops profiting and protecting extremist sites and sites which host illegal content.

The concentration of internet infrastructure into a few companies is something to be concerned about. But my bigger beef with Cloudflare is that they profit from and protect despicable websites and only cave when public pressure is high enough.

kazinator• 4 years ago

I haven't paid much attention to this stuff, but recently I discovered a trick for slowly migrating the web services on an old server to a new one: via reverse proxy definitions on the new server that pass through selective paths to the old one. To the outside, it looks like one server. The new server has the SSL identity with up-to-date crypto and all and terminates the HTTPS connections. As I'm doing this, suddenly it hits me: oh so this is Cloudfare in a mini nutshell?

A Primer on Proxies

Related Stories