5 ms·

The guy's rationale may be kind of dubious but it's clearly stated: there aren't any tools that do DPI on TLS 1.3 sessions right now.

jrockway 10y ago
You don't need to do deep packet inspection when you just MITM all the traffic.
- blazespin 10y ago
  Infrastructure upgrades are required. tls1.3 will be expensive
  - vacri 10y ago
    So let the CEOs have a year of $40M bonuses instead of $50M bonuses. A small price to pay for better security for the rest of us.
- lisivka 10y ago
  MITM introduces significant delays, yet another single point of failure, adds significant risk of leakage. Current DPI are passive, so they have no such problems.
  - ivan_gammel 10y ago
    It's technical problem, that can be solved. Dedicated hardware optimized for MITM, probably.
    - bchociej 10y ago
      It's already in use, in fact.
      - ChoHag 10y ago
        Who'd have thought banks would look for ways to save money? Madness!
  - anonymousDan 10y ago
    Could you elaborate a bit on what kind of passive DPI you can usefully do on an encrypted TLS session? Do you mean something like this? https://arxiv.org/pdf/1607.01639v1.pdf https://arxiv.org/pdf/1607.01639v1.pdf
  - kijin 10y ago
    Deliberately weakening encryption also adds significant risk of leakage, this time on a global scale.
  - bchociej 10y ago
    There are absolutely "bump-in-the-wire" intrusion prevention systems with MITM capability.
- zigzigzag 10y ago
  You're getting mixed up. DPI on TLS sessions requires a MITM. The problem is (apparently) that there are no enterprise-grade MITM solutions that support TLS 1.3
  - kijin 10y ago
    That argument is a non-starter. Surely somebody will build and market such solutions once TLS 1.3 becomes widely used. The protocol must be finalized before enterprise-grade products can use it, not the other way around.
  - jrockway 10y ago
    So here's how I'm imagining the current solution, as implemented at the bank I worked at. Remember first off, there is no route to the Internet from workstations. Everything goes through a regular old HTTP proxy running on a server that accesses both the intra and Inter nets. You send it the host you want ("GET https://example.com/" https://example.com/"), it fetches it and returns the HTML. It is nothing more complicated than: socat tcp-listen:8080,reuseaddr,fork 'system:curl $(grep -m 1 GET | cut -d " " -f 2)' with a little logging to put Nefarious Sites on your Permanent Record.

jrockway 10y ago

You don't need to do deep packet inspection when you just MITM all the traffic.

blazespin 10y ago
Infrastructure upgrades are required. tls1.3 will be expensive
- vacri 10y ago
  So let the CEOs have a year of $40M bonuses instead of $50M bonuses. A small price to pay for better security for the rest of us.
lisivka 10y ago
MITM introduces significant delays, yet another single point of failure, adds significant risk of leakage. Current DPI are passive, so they have no such problems.
- ivan_gammel 10y ago
  It's technical problem, that can be solved. Dedicated hardware optimized for MITM, probably.
  - bchociej 10y ago
    It's already in use, in fact.
    - ChoHag 10y ago
      Who'd have thought banks would look for ways to save money? Madness!
- anonymousDan 10y ago
  Could you elaborate a bit on what kind of passive DPI you can usefully do on an encrypted TLS session? Do you mean something like this? https://arxiv.org/pdf/1607.01639v1.pdf https://arxiv.org/pdf/1607.01639v1.pdf
- kijin 10y ago
  Deliberately weakening encryption also adds significant risk of leakage, this time on a global scale.
- bchociej 10y ago
  There are absolutely "bump-in-the-wire" intrusion prevention systems with MITM capability.
zigzigzag 10y ago
You're getting mixed up. DPI on TLS sessions requires a MITM. The problem is (apparently) that there are no enterprise-grade MITM solutions that support TLS 1.3
- kijin 10y ago
  That argument is a non-starter. Surely somebody will build and market such solutions once TLS 1.3 becomes widely used. The protocol must be finalized before enterprise-grade products can use it, not the other way around.
- jrockway 10y ago
  So here's how I'm imagining the current solution, as implemented at the bank I worked at. Remember first off, there is no route to the Internet from workstations. Everything goes through a regular old HTTP proxy running on a server that accesses both the intra and Inter nets. You send it the host you want ("GET https://example.com/" https://example.com/"), it fetches it and returns the HTML. It is nothing more complicated than: socat tcp-listen:8080,reuseaddr,fork 'system:curl $(grep -m 1 GET | cut -d " " -f 2)' with a little logging to put Nefarious Sites on your Permanent Record.