In my company, we have two internal domains with a firewall between them. When requesting firewall rules for an application with components on domain A and domain B, I was told that encrypted protocols were not allowed through the firewall. (e.g. HTTPS 443, SSH 22).
The rational was that hackers could potentially tunnel over an encrypted protocol and packet inspection would have limited functionality.
Is this a normal practice?
Is this a normal practice?
Well, it's more common (in my limited network security experience) to force the installation of a man-in-the-middle root cert on all clients on that network and then run a tool that uses the MitM certificate authority to decrypt and inspect TLS traffic. This doesn't work perfectly for some programs (which may use certificate pinning or have their own certificate stores) and is TLS-specific (there's an equivalent you could do for SSH, though I've never seen it done).
(You didn't ask, but) Is it a good idea?
Honestly, if it's being done by port filtering, it's pretty trivial to bypass. There's no rule that says SSH must use port 22, or HTTPS (never mind any other TLS protocol) must use 443; those are merely the defaults. I could simply set up an external SSH server listening on another port, then SSH to it and use it as a proxy to bypass the monitoring. You can't even do this by simply whitelisting ports; so long as I don't have anything else (like a web server) running on port 80 on my machine, I could set up my SSH server to listen on that port.
It's much more effective to restrict connections - especially outbound ones - in general. Only allow them with the specific combinations of addresses, ports, and protocols that are required, and nothing more. If you have some specific reason that your machines need to make outbound connections to UDP port 9670 on the 233.14.98.128/25 subnet (all numbers sourced rectally), you can allow exactly those connections and no others.
While this is not "normal" in general it might be a requirement within specific environments: In some cases it is necessary to inspect and/or record all traffic as an audit trail, for example to tightly monitor access to machines, record what an administrator or some remote management is doing etc. These are environments where telnet is still used or where SSH intercepting proxies are used to allow the necessary visibility. If this is the case with your specific environment is not known since nothing is known about your environment at all.
What is a common use, is to forbid all encrypted protocols except for well known servers. The rationale is that encrypted protocols prevent Deep Packet Inspection meaning that an infection on one side could propagate to the other side without giving a chance to the security team to see any warning.
But well know servers are generally managed as exception to avoid users to send their passwords in clear text.
Not allowing those encrypted protocols you will be easily be targeted man-in-the-middle-attack.
It's not normal to block those protocols.
Furthermore, if hackers can easily do tunneling on your network, then there's serious security misconfiguration on your network or servers.
