4 ms·

> The problem with hardware is you can’t always just patch fault. That is the part that is "next level negligence". If you're making "security products" and yo

by hannob 5y ago

> The problem with hardware is you can’t always just patch fault. That is the part that is "next level negligence". If you're making "security products" and you are not able to cover basic security - i.e. have a working update process and communicate to your customers that they should actually use that working update process and not actively disable it - then you failed at your job.

tg180 5y ago
Serious DPI vendors should really implement a proper state machine, so that they can't be fooled that easily. But middleboxes are not "security products", they can't be. "Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection" was published in 1998 [https://apps.dtic.mil/dtic/tr/fulltext/u2/a391565.pdf https://apps.dtic.mil/dtic/tr/fulltext/u2/a391565.pdf]. We should know that DPI is not reliable. In fact Geneva is a research project that expands and extends the concepts of fragrouting, applying a genetic algorithm to automatically find flaws in censoring middleboxes [https://raw.githubusercontent.com/Kkevsterrr/geneva/master/evolve.py https://raw.githubusercontent.com/Kkevsterrr/geneva/master/e...]. It is expected that a research project of this type exposes these kind of bugs. And the reason why they can research these things is because "there isn't enough information on the wire". Bugs of this type are egregious for their danger and simplicity, but patched these there will always be.
- acdha 5y ago
  I would characterize that differently: they are security products — that’s how they’re marketed – but they aren’t perfect and are only effective against certain behavior. That means you can’t rely on them alone for everything but it doesn’t mean they don’t have a security function.
  - tg180 5y ago
    My issue is exactly with how they're marketed and sold. Information theory proves there's an infinite number of ways in which you can codify something. The subset of encodings that meets the rules imposed by any middlebox is in turn infinite. > they aren’t perfect and are only effective against certain behavior This means that they are only effective against default behavior. Anything else is out of scope for these products, which I think is what @laumars was referring to with "outside the bounds of normal expected operation". Marketing sophisms can be fun, but defining something as a "security product" when it is mathematically proven that there are infinite ways to bypass the provided "security guarantees" is ... simply something I refuse to do.
tialaramex 5y ago
They're not making security products. They're making "security" products. Imagine you're working on products for airport security. Should you focus on stuff that might actually be useful to improve the security of the airport and planes? Or, should you focus on useless security theatre for the well-funded TSA and similar entities? You won't find these "security" products in environments where actual security was crucial and the operators understood what they were doing. What you see there is Zero Trust, low friction but effective authentication, and occasionally actual real air-gapping, because somebody says "It would be easier if this wasn't air-gapped but that's inherently unsafe and the risk is unacceptable, so we're doing it the hard way". But lots of places want to play pretend and for them a "security" product is perfect, it checks off the box for the relevant CxO role and causes some level of irritation while making no practical difference to actual security. Perfect. Reminds me of the first question you ask about a "Secure" site (e.g. a data centre) to understand if they really mean "Secure" or not. "Who cleans this place?" If the answer is "Nobody, it's a mess" or "sigh we all have to take turns" then maybe it's actually secure. But if there's some bullshit about "vetting" of staff paid minimum wage to go wherever they want, unremarked, carrying large black bags of unknown objects then the facility is not, in fact, secure.

by hannob 5y ago

tg180 5y ago

Serious DPI vendors should really implement a proper state machine, so that they can't be fooled that easily. But middleboxes are not "security products", they can't be. "Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection" was published in 1998 [https://apps.dtic.mil/dtic/tr/fulltext/u2/a391565.pdf https://apps.dtic.mil/dtic/tr/fulltext/u2/a391565.pdf]. We should know that DPI is not reliable. In fact Geneva is a research project that expands and extends the concepts of fragrouting, applying a genetic algorithm to automatically find flaws in censoring middleboxes [https://raw.githubusercontent.com/Kkevsterrr/geneva/master/evolve.py https://raw.githubusercontent.com/Kkevsterrr/geneva/master/e...]. It is expected that a research project of this type exposes these kind of bugs. And the reason why they can research these things is because "there isn't enough information on the wire". Bugs of this type are egregious for their danger and simplicity, but patched these there will always be.

acdha 5y ago
I would characterize that differently: they are security products — that’s how they’re marketed – but they aren’t perfect and are only effective against certain behavior. That means you can’t rely on them alone for everything but it doesn’t mean they don’t have a security function.
- tg180 5y ago
  My issue is exactly with how they're marketed and sold. Information theory proves there's an infinite number of ways in which you can codify something. The subset of encodings that meets the rules imposed by any middlebox is in turn infinite. > they aren’t perfect and are only effective against certain behavior This means that they are only effective against default behavior. Anything else is out of scope for these products, which I think is what @laumars was referring to with "outside the bounds of normal expected operation". Marketing sophisms can be fun, but defining something as a "security product" when it is mathematically proven that there are infinite ways to bypass the provided "security guarantees" is ... simply something I refuse to do.

tialaramex 5y ago

They're not making security products. They're making "security" products. Imagine you're working on products for airport security. Should you focus on stuff that might actually be useful to improve the security of the airport and planes? Or, should you focus on useless security theatre for the well-funded TSA and similar entities? You won't find these "security" products in environments where actual security was crucial and the operators understood what they were doing. What you see there is Zero Trust, low friction but effective authentication, and occasionally actual real air-gapping, because somebody says "It would be easier if this wasn't air-gapped but that's inherently unsafe and the risk is unacceptable, so we're doing it the hard way". But lots of places want to play pretend and for them a "security" product is perfect, it checks off the box for the relevant CxO role and causes some level of irritation while making no practical difference to actual security. Perfect. Reminds me of the first question you ask about a "Secure" site (e.g. a data centre) to understand if they really mean "Secure" or not. "Who cleans this place?" If the answer is "Nobody, it's a mess" or "sigh we all have to take turns" then maybe it's actually secure. But if there's some bullshit about "vetting" of staff paid minimum wage to go wherever they want, unremarked, carrying large black bags of unknown objects then the facility is not, in fact, secure.