3 ms·

I remember a Hacker News post that many of the top Firewall vendors suggest disabling UDP over port 443. Apparently it's hard for packet inspection, restricted

by GNOMES 6y ago

I remember a Hacker News post that many of the top Firewall vendors suggest disabling UDP over port 443. Apparently it's hard for packet inspection, restricted browsing etc in the enterprise space. Have there been any leaps in Firewall tech, or will most companies still disable this?

microcolonel 6y ago
> Have there been any leaps in Firewall tech, or will most companies still disable this? QUIC is explicitly designed to frustrate this sort of thing, so the enterprise will just have to choose between having and not having it, or switch from MITM to endpoint backdoors.
- cheschire 6y ago
  Or go full BYOD and forego the network equivalent of 14th century defenses
  - thisisnico 6y ago
    Even with BYOD, you still need a firewall... Source: Am Enterprise IT.
  - unethical_ban 6y ago
    I think you underestimate the complexity of securing data in a privileged network.
  - microcolonel 6y ago
    The solution for us is total endpoint control. Our application endpoints have their own DNS root. :+ )
driverdan 6y ago
Defeating firewalls is a feature.
tialaramex 6y ago
If you do what the specification told you, in TLS 1.3 or in QUIC, you can build these products and they'll work as intended for web browsing. In TLS 1.3 there is even a whole section of the RFC (under "Invariants") that explains how to do this properly. What you end up with is two connections. A connection from the browser to your product, and then a connection from your product to the web site. Your product is in the middle and can apply any policies whatsoever that it desires. There are two things about this that vendors do not like, or which their customers do not like and the vendors would prefer somebody else take the blame for not them. 1. For this to work the browser needs to trust the product. The product will need to mint its own certificates for each site visited, and it can't make genuine ones, so it'll need to be explicitly trusted by the browser. This requires more honesty from your customer (the product's operator) in regard to their users (employees / students / visitors / whatever) where previously a product might try to snoop unobtrusively. That's no longer an option. 2. Actually doing all this heavy lifting costs money. More CPU power, more RAM, even more network bandwidth because you can't just snoop a few frames at the start of a connection you need to proxy decrypt/ re-encrypt every single byte even if you realised very quickly that it was actually fine. This makes the product more expensive, even though it's also worse because their users ask awkward questions now.

by GNOMES 6y ago

microcolonel 6y ago

> Have there been any leaps in Firewall tech, or will most companies still disable this? QUIC is explicitly designed to frustrate this sort of thing, so the enterprise will just have to choose between having and not having it, or switch from MITM to endpoint backdoors.

cheschire 6y ago
Or go full BYOD and forego the network equivalent of 14th century defenses
- thisisnico 6y ago
  Even with BYOD, you still need a firewall... Source: Am Enterprise IT.
- unethical_ban 6y ago
  I think you underestimate the complexity of securing data in a privileged network.
- microcolonel 6y ago
  The solution for us is total endpoint control. Our application endpoints have their own DNS root. :+ )

driverdan 6y ago

Defeating firewalls is a feature.

tialaramex 6y ago

If you do what the specification told you, in TLS 1.3 or in QUIC, you can build these products and they'll work as intended for web browsing. In TLS 1.3 there is even a whole section of the RFC (under "Invariants") that explains how to do this properly. What you end up with is two connections. A connection from the browser to your product, and then a connection from your product to the web site. Your product is in the middle and can apply any policies whatsoever that it desires. There are two things about this that vendors do not like, or which their customers do not like and the vendors would prefer somebody else take the blame for not them. 1. For this to work the browser needs to trust the product. The product will need to mint its own certificates for each site visited, and it can't make genuine ones, so it'll need to be explicitly trusted by the browser. This requires more honesty from your customer (the product's operator) in regard to their users (employees / students / visitors / whatever) where previously a product might try to snoop unobtrusively. That's no longer an option. 2. Actually doing all this heavy lifting costs money. More CPU power, more RAM, even more network bandwidth because you can't just snoop a few frames at the start of a connection you need to proxy decrypt/ re-encrypt every single byte even if you realised very quickly that it was actually fine. This makes the product more expensive, even though it's also worse because their users ask awkward questions now.