@rsrinivasanhome wrote:
Query on "Firewall Hardening essentials"
I am new to infra had a question on an article present in the magazine - InfoSecurity-Professional - May/June 2021 .
Does our firewall in general ssl inspect both inbound and outbound traffic ? In our case inbound traffic is external client traffic reaching our server(via firewall) and outbound traffic is traffic where our server (via firewall ) communicates with external clouds Is my assumption correct ? Below is extract from the InfoSecurity-Professional magazine.
"A common issue relates to how organizations deal with encrypted traffic. The obvious first step is to apply inspection of SSL to outbound web traffic—a relatively easy task, although issues such as certificate pinning require some administration and effort. One of the more difficult challenges is handling of inbound encrypted traffic. While the technical solutions are simple, there are high expectations for external web applications, and such inspection may add considerable latency. This creates a dangerous blind spot, since the cert usually is on the load balancer or app server, meaning the firewall is potentially blind to attacks over a connection directly to an application. It is possible for an attacker to perform an exploit over 443 and obtain a reverse web shell, without the firewall ever seeing anything unusual, if the attack is well executed and traffic is not decrypted."
How can we decrypt outbound traffic ? For inbound traffic we have the certificate / private key to do so . How does certificate pinning help ?
Srinivasan,
To answer your questions, we first must review which keys are used in each transaction.
1. Outbound traffic is encrypted with the RECEIVER's public encryption key. That way only the receiver, who has the paired private key, can decrypt it.
Thus, to know the content of outbound encrypted traffic, you must implement a proxy encryption server at the enterprise boundary, which holds the external entity's public key. That proxy, in turn, communicates with the internal actor via local internal key pairs. Outbound traffic from the individual encrypts outbound traffic with the proxy servers public key, not the external actor's. That encrypted local traffic inside the enterprise is decrypted by the proxy server, the content in cleartext is inspected, and then the proxy server re-encrypts the content using the external actor's public key for transmission from the enterprise to the external receiver.
2. Encrypted inbound traffic was encrypted using the local public key provided via certificate to the external partner. When you say "we have the certificate / private key to do so" you may have described a problematic local key management process. Your enterprise inspection system could decrypt all inbound traffic as you describe only if all internal actors use the same certificate and key pair, or if you routinely hold all of your employees private keys in escrow, but routinely use them to decrypt. Neither practice is considered proper. Your employees must be able to totally control their own encryption of legally protected private information to which the enterprise has no right to see. These include HIPPA (in USA) medical communications, personal communication s with financial institutions, lawyers, other legal aspects, etc.
The method my last employer used was as follows: The proxy encryption server at the enterprise boundary (as described above) monitored all encrypted traffic. If the traffic was to or from a privacy-protected entity, such as a bank, lawyer, medical service, etc,, the traffic was sent on to the addressee without decryption. All of those entities were kept on a white list, to which employees could nominate additional enterprises which match the basic criteria. All other encrypted traffic, in both directions, was decrypted and re-encrypted as described above, so that the external entity was always working with the proxy server's certificates and keys, never the individual actual sender's keys.
Note that the issue of key escrow is a separate discussion, but essentially private keys for all employee's signing certificates should never be escrowed, to protect non-repudiation arguments, but every employee's private encryption key should be escrowed and protected in a controlled access digital vault, to protect the enterprise's access to enterprise data in cases of employee loss, departure, death, or malfeasance.
Good questions, and one that many folks should understand more clearly. Thank you.
Craig
