4 ms·

> Modern NGFWs are capable of decrypting/encrypting TLS traffic transparently for the end user and server and inspecting traffic for policy compliance based on

by comex 5y ago

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

slt2021 5y ago
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.
- coffeeandbooks 5y ago
  > 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.
- egberts1 5y ago
  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.

by comex 5y ago

slt2021 5y ago

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.

coffeeandbooks 5y ago
> 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.
egberts1 5y ago
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.