by Shijaz Abdulla
on 13.06.2010 at 20:52
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.
- 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.
Hope you enjoyed this article. Subscribe to this blog for more how-to’s on TMG and other Forefront products.
by Shijaz Abdulla
on 10.04.2008 at 13:56
If you have installed Exchange 2007 Client Access Servers in your organization, and if you have installed your SSL certificates (even commercial ones) on IIS, Outlook MAPI users may receive ‘Security Alert’ messages similar to the above in Outlook.
The name on the security certificate is invalid or does not match the name of the site.
This is because of the certificate that you have installed on IIS. Outlook 2007 MAPI clients use Client Access Servers for the Autodiscover service. The Autodiscovery web service (a virtual directory on the Client Access Server) is used for automatically finding the mailbox server for a given user. When the Autodiscover service is accessed by Outlook, and the name on the security certificate installed in IIS doesn’t match the internal FQDN of the Client Access server (CAS), this error results.
Suppose your company’s public domain name is mycompany.com. You may have obtained a certificate for webmail.mycompany.com and installed on the IIS of your Client Access Server. This is correct because users on the internet will type the public name.
However, the same IIS on the CAS is hosts the Autodiscover virtual directory as well and this certificate applies. Your internal domain name might be mycmpny.local and the client access server FQDN might be CAS1.mycmpny.local. Outlooks 2007 uses this internal name to connect to Autodiscovery, and hence the mismatch error.
To fix this problem, open Exchange Management Shell and type the following commands:
Set-ClientAccessServer -Identity CAS1 -AutodiscoverServiceInternalUri https://webmail.mycompany.com/autodiscover/autodiscover.xml
Set-WebServicesVirtualDirectory -Identity “CAS1EWS (Default Web Site)” -InternalUrl https://webmail.mycompany.com/ews/exchange.asmx
Set-OABVirtualDirectory -Identity “CAS1oab (Default Web Site)” -InternalUrl https://webmail.mycompany.com/oab
Set-UMVirtualDirectory -Identity “CAS1unifiedmessaging (Default Web Site)” -InternalUrl https://webmail.mycompany.com/unifiedmessaging/service.asmx
Pay attention to the text in red, you will need to change it to reflect your server’s running parameters. Recycle the MSExchangeAutodiscoverAppPool. Your users should no longer receive the security alert.
by Shijaz Abdulla
on 01.10.2007 at 09:31
A client wanted to publish two web services on SSL using ISA Server 2006: Outlook Web Access and Sharepoint Portal Server.
We know that ISA Server can only bind one SSL certificate per socket. This translates to one HTTPS URL/website per socket. What does this mean? Lets say I have my OWA at https://owa.shijaz.com/ and I have an SSL certificate issued to owa.shijaz.com. I also have my Sharepoint portal at https://portal.shijaz.com/ for which I have acquired a certificate with common name portal.shijaz.com.
While publishing, I can have only one web listener per socket and a web listener can accept at most ONE SSL certificate. If I apply the owa.shijaz.com certificate on my web listener, OWA will work fine, but users browsing to portal.shijaz.com will get a certificate warning/error. If I apply the portal.shijaz.com certificate, users browsing to owa.shijaz.com will get a certificate warning/error.
So what’s the solution? Wouldn’t it be great if we could order a certificate with common name *.shijaz.com and use the same certificate for both (or more) websites? Yes, you can! That’s called the WILDCARD Certificate!
Ordering a wildcard certificate is fairly simple, if you know how to order a normal SSL certificate. While generating an SSL request, simply enter *.yourdomain.com as the common name for the new certificate.
Wildcard certificates have a limitation that they are not available in 128-bit SGC and available only in standard encryption. The encryption level is decided by the user’s browser, rather than the certificate. So, if you’re securing a electronic payment website or a finance-related website, a wildcard certificate may not be what you should be looking at.
by Shijaz Abdulla
on 02.09.2007 at 08:53
In my earlier post on Intelligent Application Gateway (IAG 2007), I explained how we can download a fully-functional VHD image that simulates the IAG appliance and how to get started with it.
One of the interesting features in IAG that I came across is the ability to verify how secure the endpoint is (endpoint: client computer from which the user establishes the SSL-VPN session). The administrator can define endpoint policies that define the minimum security requirements that the client computer must have, in order to be able to connect to a particular internal application or service via IAG.
For instance, users may connect from home PCs or internet kiosks to access file servers while out of office. In order to secure file servers from possible malware attacks, we can require that all client computers that request access to file servers should have anti-malware software installed, failing which connections should be disallowed.
Lets take a closer look:
In the IAG console, under the portal for HTTPS connections, I open the properties page for File Access and specify an Endpoint Policy that requires that Windows Defender be installed on any endpoint that requires access to file servers.
On an external client machine that does not have Windows Defender installed, I try to access the IAG portal. I note that even before showing me the login form, the portal quickly gathers and sends information to IAG to verify compliance with endpoint policy.
Now I login to the IAG Portal:
And – as expected – I find that File Access is disabled!
If I click Details, I am informed why my endpoint is not allowed to connect to this service.
This is indeed a very nice feature. Reminds me of quarantined VPN clients in ISA Server.
If you have read my earlier post on extending access to file servers from OWA, you will note that this amount flexibility of endpoint security compliance check is not available while allowing direct file access through OWA. In OWA, you can only set separate policies for ‘Public’ and ‘Private’ computers, as selected by the user on the login form. And of course, this can be over-ridden by the user when he/she logs in, so it really isn’t much of an enforcement.
by Shijaz Abdulla
on 24.08.2007 at 13:46
Outlook Web Access (OWA) on Exchange Server 2007 now supports direct file access, which means users can connect to internal file servers over the web using the standard OWA interface.
Readers of my earlier posting on Intelligent Application Gateway 2007 will agree that, if SSL is configured on Outlook Web Access (OWA) with internal file server access enabled, and it is published using ISA Server 2006, this gives you the equivalent of a browser-based SSL-VPN connection to the file server! Think about it.
This is good news for organizations who want to publish their file servers securely for home users but cannot afford a secure VPN solution.
Similarly, users can access internal Sharepoint sites from OWA if this is enabled on Exchange Server 2007. Certainly good news for organizations that tried to publish both OWA and SharePoint server over SSL on the same ISA Server installation — and then daunted away because it meant replacing the SSL certificate a wildcard certificate (which offers weaker encryption than a normal SSL certificate).
For step-by-step instructions on how to configure direct file access, see my article Configuring direct file server access from Outlook Web Access in Exchange Server 2007
by Shijaz Abdulla
on 28.07.2007 at 14:06
Intelligent Application Gateway 2007 (IAG) is Microsoft’s new addition to the ForeFront Edge Security family. IAG provides web-based SSL-VPN connections for secure access to applications from outside the organization’s network perimeter. IAG 2007 was previously known as Whale SSL VPN before Microsoft acquired Whale Communications.
I had always wanted to get my hands on an IAG appliance, but appliances are costly, and the only way to work on one was to get my company to buy one of those babies. However, I was excited when I saw that the IAG VHD is available for download! It’s a scenario-based demo, which involves a virtual machine image (VHD) running DC/Exchange 2007/SPS 2007 and another virtual machine running the IAG appliance itself. Also, there were two client machine VHDs – one ‘managed’ and the other an ‘unmanaged’ client.
I downloaded the whole demo lab, and put it together on my 64-bit Virtual Server 2005 R2. I got a preview of the IAG features, but found that the Network Connector feature (the one that lets a remote client connect to the corporate network – ‘VPN-style’) wasn’t working. Upon closer examination, I found that the “Whale Network Connector Server” service was not running on the IAG virtual machine. When I tried to manually start the “Whale Network Connector Server” service, i got the message that the service stopped after starting. My repeated attempts to start the service were in vain.
So I opened the IAG Configuration console, and navigated to Admin > Network Connector Server option. IAG appliance has two physical network cards – one sticking in to the internal network and the other sticking in to the external network. There is a third network interface named Whale Network Connector (a virtual NIC), which appears to be “unplugged”. I made sure that the correct network interface card was selected (it should be the NIC thats on the internal network), and then de-activated Network Connector by de-selecting the “Activate Network Connector” checkbox. Then, I applied my changes by clicking File > Activate.
Once again, I navigated to Admin > Network Connector Server. This time I selected the “Activate Network Connector” and click OK. Once again I applied my changes by clicking Activate. In a few moments, the “Whale Network Connector Server” services started and a third network interface (Whale Network Connector) started showing status as “Active”.
In short, I just de-activated and re-activated the Network Connector Server after making sure that the correct internal NIC is configured on it. So if you’ve downloaded the IAG demo lab, hope this helps you!