Zero-Knowledge Middleboxes: enforce network policies on encrypted traffic | Hacker News Reader

Zero-Knowledge Middleboxes: enforce network policies on encrypted traffic

eprint.iacr.org

82 pointsself20 comments

From a quick skim of this paper, I see no mention of ossification. The biggest advantage of the current "encrypt all the things" push is that protocol evolution is no longer constrained by middleboxes; making the contents of the encrypted connection transparent again, even in a zero-knowledge way, means that once again important parts of the protocol become frozen. For instance, the paper says "[...] Many extensions to this basic request format have been developed during the long lifetime of DNS, but they don’t affect the invariant that we rely on, namely that the DNS question starts at the thirteenth byte of the request. [...]", and as far as I understand from my cursory reading, then goes on to depend on that fact. Which means that future extensions to the protocol which change that offset, which might depend on encrypted connections being truly end-to-end and therefore only the endpoints having to understand them correctly, would then break unless all middleboxes (and in this case, also the complex zero-knowledge proof mechanisms) are upgraded.

Prevention of ossification isn't just a neat side effect of the "encrypt all the things" approach, it's the stated goal, and absolutely necessary.

Normally, I'd agree with your concern, but I'm not worried about this specific one, because it seems entirely impractical and should thus remain an academic exercise:

> Clients send the middlebox zero-knowledge proofs that their traffic is policy-compliant

- this requires integrating software with the clients sending the traffic

> performance is in striking distance of practicality; an example ... In such configurations ... client latency to create a proof is several seconds.

In other words, it's still entirely impractical. This is rounded off by:

> On the other hand, clients may have to store hundreds of MBs depending on the underlying zero-knowledge proof machinery, and for some applications, latency is tens of seconds.

The performance of ZK systems is improving rapidly, for example the startup I'm at has one which is likely already much faster than what the authors used (development is ongoing): https://github.com/risc0/risc0

The security implications of current decrypting MITM middleboxes are pretty bad so it's worth going to some lengths to find an alternative.

Can’t wait for the corporate security industry to get hold of this. Yet another way to make corporate policy compliant workstations slower and less usable than a 10 year old linux box.

I hope someone finds a way to completely break this. Otherwise, imagine when the censors get ahold of it. (If you're not convinced this is a bad thing, read "their traffic is policy-compliant" as "they aren't trying to visit any Web pages that acknowledge that the Tiananmen Square Massacre occurred", for example.)

I hope these cat and mouse games end someday. We don't want anyone enforcing "policies" on us. Maybe one day we'll have technology that will finally render them powerless.

The paper was presented last year at sdns://2021: https://youtu.be/ihFmYs3Bi_c

I like this idea and this is very much the future. I wish it wasn't out of band and these proofs could be embedded in the relatively small address space of IP headers. This also lets us take advantage of merchant silicon for branching logic.

Obviously some work is needed in the host IP stack for per packet tagging (DCSP/traffic class) rather than per socket and then flushing.

TL;DR This is a way for admins to enforce network policies without needing to see the decrypted traffic. You can use this to enforce domain blocklists for DNS over HTTPS: client proves their requested domain is not banned (a few sec) and middlebox verifies (a few millisec)

Some of the citations are factually incorrect, do people actually check this papers out before they get published?

Dodgy Science & whitepapers!

Author of the paper here - can you be more specific about which citations are factually incorrect?

Interesting profile https://cs.nyu.edu/dynamic/news/colloquium/1170/

BREAKING AND BUILDING END-TO-END ENCRYPTED SYSTEMS Speaker: Paul Allen Grubbs, Cornell University

Today’s computer systems and their owners fail to protect data. Exacerbating this are new threats stemming from the rise of cloud computing. The consequences are dire: sensitive information like financial statements, medical records, and private messages are disclosed to malicious parties. In my research at the intersection of security, cryptography, and systems, I work to change this by breaking and building efficient end-to-end (E2E) encrypted systems, which protect data by keeping it encrypted throughout processing and storage. In this talk, I’ll explain some of the flaws I’ve found in existing E2E-encrypted systems deployed to billions of users, how the flaws have led me to a new methodology for building these systems that’s rooted in co-design of cryptography and systems, and some of the new E2E-encrypted systems I’m building.

Here's one!

[126] Amar Toor. UK to block all online porn by default later this year. The Verge, 2013.

From the Paper:

> For example, adult content blocking is legally mandated for U.S. K–12 school networks [27, 63] and commercial U.K. ISPs [126]

From Wikipedia:

> Pornography is one of the types of content blocked by the Internet filtering systems used by UK Internet Service Providers (ISPs). Since the end of 2013 a program of applying filtering to new ISP customers has been in place, and this has been extended to existing users on a rolling basis. A voluntary code of practice agreed by all four major ISPs[75] means that customers have to 'opt out' of the ISP filtering to gain access to the blocked content.

https://en.wikipedia.org/wiki/Pornography_in_the_United_King...

You consider that factually incorrect?

Bit watered down dont you think, considering some of the things that appear on Reddit!

tldr: paper is an attempt of applying crypto/blockchain related ZK-SNARKs to network security.

But modern network security and firewalling is completely different and became very advanced. Nobody is blocking http port by port nowadays. Modern NGFWs are capable of decrypting/encrypting TLS traffic transparently for the end user and server and inspecting traffic for policy compliance based on any attribute in the request payload. and it runs on dedicated ASICs on specialized network appliances in realtime.

Just another crypto tech looking for a problem to solve

> Modern NGFWs are capable of decrypting/encrypting TLS traffic transparently for the end user and server and inspecting traffic for policy compliance based on any attribute in the request payload.

Of course they are. But then the middlebox sees the plaintext and can log it, whether by policy or due to a compromise. The point of this approach is to better protect privacy by letting the middlebox validate the plaintext without actually seeing it.

It’s not really practical, given the extreme performance cost compared to the limited amounts it can accomplish, but to be fair, the abstract only calls it “in striking distance of practicality”.

middlebox doesnt see plaintext, it sees encrypted TLS, decrypts it, inspects in memory, and ecnrypts it back again to send it to next hop. Plaintext exists only for a brief amount of CPU cycles somewhere on a chip's memory and is immediately replaced with continuous data stream of subsequent traffic.

there are other examples in the paper that dont make any sense.

For example HTTP Firewalling use case, author refers to check HTTP 1.1 version use case, but for any network box the entirety of TLS(https) traffic is encrypted and you cant look at it without the key. And if you have key - you pretty much see entire HTTP session and there is no privacy. Same problem with DNS query. You cant claim to provide privacy, if you rely on decryption TLS traffic, even messing with TLS encryption parameters, algorithm selection, authentication scheme selection can be a serious compromise to privacy and security.

Author mixes up concepts from different OSI layers, like transport (TCP/TLS) and application (HTTP/UDP) that don't have any knowledge of each other and operate independently. TLS is just an encrypted transport, it can move http traffic, or it can move any other traffic, and it doesn't care nor know the payload. As soon as you look into payload you lose privacy claim.

Typical case when knowledge in one technology in single domain (crypto/blockchain/web3) does not translate well to different domain, like network security.

I would like to see a proof of concept in code working end to end, just to see how it wont work in practice.

> middlebox doesnt see plaintext, it sees encrypted TLS, decrypts it, inspects in memory, and ecnrypts it back again to send it to next hop.

So it sees the plaintext.

so at one given point of time, that middle box had access to plaintext as well?

It may not be accessible plaintext when the middlebox is at resting state, but it certainly has access to plaintext at its active state.

Given enough time, such Middlebox too may succumb to a malicious payload whose active but plaintext memory region gets targeted and exploited by.

Reply on news.ycombinator.com