What is Forward HTTPS Inspection or Outbound HTTPS Inspection?
In ISA Server 2004/2006, we had Inbound HTTPS inspection, which we are familiar with by the name “SSL Bridging”. SSL Bridging or Inbound HTTPS inspection is used to protect published web servers from malicious requests originating from the Internet/external network. In essence, the ISA Server had the same SSL certificate that the web server had, along with its private key. When an HTTPS request reaches the ISA Server, it decrypts the request using the certificate and inspects it. If it is found to be safe, the ISA Server establishes another SSL session between itself and the published web server.
SSL Bridging was an excellent piece of technology for inspecting inbound HTTPS traffic, but ISA Server did not have a feature to inspect “outbound” HTTPS traffic.
Okay – so what’s Outbound HTTPS Inspection?
Outbound HTTPS traffic refers to the HTTPS requests originating from the internal network to the Internet, (for example, user’s internet browser). Why is this required? Often blocked websites or services can be accessed through an HTTPS session because the proxy servers do not have visibility of the content that is passing inside the HTTPS session.
This is often the technique used by many anonymizers, P2P software, and applications like Skype to evade being blocked by a proxy server. More dangerously, it is often used by modern malware to pass undetected between your internal network and the internet, as your edge security products simply cannot see what’s inside the SSL.
So, how does HTTPS Inspection work? I’m putting it down in *very* simple terms below:
1. TMG Server has an SSL CA Certificate on it (can be self-generated or from Active Directory). However, all client computers in your internal network must trust TMG’s HTTPS Inspection certificate.
2. User’s computer tries to access an HTTPS website (or other HTTPS content) on the Internet.
3. TMG does not blindly “proxy” the request to remote HTTPS server. Instead, TMG Server acts like a client and talks to the remote HTTPS website.
4. TMG validates the site’s certificate, copies the details of that certificate and creates a new SSL certificate with those exact same details and signs it with its own CA Certificate. It then returns this certificate to the internal client.
Since TMG pretends to be the client to the remote server, it gets to decrypt the content sent back and perform malware inspection and policy based filtering on the content returned.
5. What you get here is two different tunnels, one from TMG to the remote HTTPS server and another from TMG to the internal client – a perfect “man-in-the-middle attack”. I like to call it the “good-man-in-the-middle attack”.
With the connection being “cut” into two different tunnels, TMG server can decrypt, inspect and re-encrypt all communication between the client and the remote HTTPS server.
Let’s now roll up our sleeves and see how to turn on HTTPS inspection.
In ISA Server 2004/2006, we had Inbound HTTPS inspection, which we are familiar with by the name “SSL Bridging”. SSL Bridging or Inbound HTTPS inspection is used to protect published web servers from malicious requests originating from the Internet/external network. In essence, the ISA Server had the same SSL certificate that the web server had, along with its private key. When an HTTPS request reaches the ISA Server, it decrypts the request using the certificate and inspects it. If it is found to be safe, the ISA Server establishes another SSL session between itself and the published web server.
SSL Bridging was an excellent piece of technology for inspecting inbound HTTPS traffic, but ISA Server did not have a feature to inspect “outbound” HTTPS traffic.
Okay – so what’s Outbound HTTPS Inspection?
Outbound HTTPS traffic refers to the HTTPS requests originating from the internal network to the Internet, (for example, user’s internet browser). Why is this required? Often blocked websites or services can be accessed through an HTTPS session because the proxy servers do not have visibility of the content that is passing inside the HTTPS session.
This is often the technique used by many anonymizers, P2P software, and applications like Skype to evade being blocked by a proxy server. More dangerously, it is often used by modern malware to pass undetected between your internal network and the internet, as your edge security products simply cannot see what’s inside the SSL.
So, how does HTTPS Inspection work? I’m putting it down in *very* simple terms below:
1. TMG Server has an SSL CA Certificate on it (can be self-generated or from Active Directory). However, all client computers in your internal network must trust TMG’s HTTPS Inspection certificate.
2. User’s computer tries to access an HTTPS website (or other HTTPS content) on the Internet.
3. TMG does not blindly “proxy” the request to remote HTTPS server. Instead, TMG Server acts like a client and talks to the remote HTTPS website.
4. TMG validates the site’s certificate, copies the details of that certificate and creates a new SSL certificate with those exact same details and signs it with its own CA Certificate. It then returns this certificate to the internal client.
Since TMG pretends to be the client to the remote server, it gets to decrypt the content sent back and perform malware inspection and policy based filtering on the content returned.
5. What you get here is two different tunnels, one from TMG to the remote HTTPS server and another from TMG to the internal client – a perfect “man-in-the-middle attack”. I like to call it the “good-man-in-the-middle attack”.
With the connection being “cut” into two different tunnels, TMG server can decrypt, inspect and re-encrypt all communication between the client and the remote HTTPS server.Let’s now roll up our sleeves and see how to turn on HTTPS inspection.
- Right click on Web Access Policy. Choose “Configure” > “HTTPS Inspection”
- Choose “Enable HTTPS inspection”
- You can choose to Inspect traffic and validate site certificates (recommended).
- Under the HTTPS Inspection Certificate settings, you have two options – Use TMG to generate a certificate or Import a certificate already issued by your Enterprise Root CA trusted by your organization or issued by a third party certificate. In either case, all client computers in your network MUST trust the CA certificate.
- If you used Forefront TMG to generate the certificate, make sure you save the CA certificate in the Trusted Root CA store on all your computers. You can automatically deploy the certificate by clicking on the HTTPS Inspection Trusted Root CA Certificate Options button. You will need domain administrator credentials.
0 comments:
Post a Comment