What is SSL?
Secure Sockets Layer (SSL) is a security standard designed to provide secure connections over the Internet. With SSL, you can encrypt confidential data and exchange it via the Internet with various web servers and users. The minimum required set of components for establishing an SSL connection includes: a server allowing you to process SSL connections, a client that can initiate secure SSL connections and a certificate installed on the server (most often), on the client (an exception mostly) or on both sides. The certificate contains a public key.
How SSL works in Microsoft ISA Server (Forefront TMG)
Microsoft ISA Server (Forefront TMG) allows clients on the company's LAN to initiate outbound SSL connections, but it does not allow these connections to be analyzed. You can see the reason for it from the following chart:
- the user's browser initiates a connection to a secure resource.
- ISA Server (Forefront TMG) understands it and establishes a direct connection (tunnel) with this resource.
- after the connection is successfully established, ISA Server (Forefront TMG) notifies the user and from now on the user's browser and the web server of the secure site exchange data directly via the created tunnel.
Advantages and disadvantages of using SSL. Possible dangers
There is only one and most important advantage of using SSL: encrypting all data transferred between the client and the server. This advantage is inherent in the very nature and purpose of SSL. The main drawbacks of SSL include low performance resulting from the total encryption of data going through the tunnel.
As it often happens, a wrong person turns drawbacks into dangerous tools. What problems are possible in a company that uses SSL?
- Unauthorized access to websites
Since Microsoft ISA Server (Forefront TMG) does not allow you to take a look inside SSL traffic, even the most sophisticated permitting and forbidding rules worked out by administrators become just useless. ISA Server (Forefront TMG) cannot analyze requested objects, their names, file extensions, data types, headers, length and so on. As a result, the user can access any forbidden site via a public SSL Web Proxy. ANY SITE!
- Impossible to check the content by all kinds of Content Analyzers.
As well as the rest, this issue results from the first one. Since ISA Server (Forefront TMG) cannot access the content of request objects, it is impossible to check them, for example, for viruses and other badware. This results in the potential danger of infecting the client's workstation and jeopardizing the security of the entire LAN.
- Confidential information leak
The user can smuggle out any information from the company by just sending it via a secure SSL connection. And Microsoft ISA Server (Forefront TMG) will not even understand what has just left the local area network.
SSL Decoder (hereinafter, SSL Decoder) is a special web filter allowing you to peek inside SSL traffic. It means that in fact it eliminates all the above disadvantages of using SSL with Microsoft ISA Server (Forefront TMG).
You get the following opportunities after you install the program:
- see the complete URLs of all objects requested by users, the sizes of received objects, their data types and everything else that an administrator can see in case of regular HTTP requests.
Note that traffic becomes visible only for ISA Server (Forefront TMG). Unencrypted content does not get outside. Thus, an external viewer will see traffic outgoing from the external interface of ISA Server (Forefront TMG) as secure SSL traffic. Unencrypted traffic is available only within the local area network (in most cases it does not even leave the computer where ISA Server (Forefront TMG) is running).
- analyze the content of pages and objects received by the user. If necessary, these pages can be modified on the fly with special web filters, for example, Response Modifier. Or you can check the content of pages for viruses using all kinds of third-party solutions.
- increase the performance due to caching. Since traffic is now turned into regular HTTP traffic, all objects the user requests via a SSL connection get into the ISA Server (Forefront TMG) cache after being processed by SSL Decoder. And naturally, the content will be taken not from the Internet, but from the cache in case the same object is requested again. As a result, HTML pages are displayed 15-20% faster.
- forget about secure connections while creating Policy Rules. Now all SSL traffic previously invisible looks like regular HTTP and, therefore, all connection attributes can be used while creating Policy Rules.
SSL Decoder disadvantages:
- a slowdown in processing SSL traffic due to additional encryption/decryption operations. However, this slowdown is incomparable with the speedup resulting from caching requested objects on ISA Server (Forefront TMG).
- ethical issues. The administrator gains access to the list of all objects requested by users. Everything that was invisible becomes visible. It is recommended to notify LAN users about it.
How the program works
When an outbound request for a connection to an external secure server is received, ISA Server (Forefront TMG) establishes a secure connection with the web server and then notifies the user that it is ready to provide its service as an intermediate link in transferring an encrypted byte flow. Thus, you can see that the process is logically split into three steps:
- the client connects to ISA server (Forefront TMG)
- ISA Server (Forefront TMG) connects to the remote web server
- data is transferred
SSL Decoder gets in between each of these steps and changes the direction of traffic in such a way that it goes through its analyzing modules. These operations are transparent and virtually imperceptible for the user.
Here is an approximate algorithm of how SSL Decoder works:
- receiving a request for access to a secure site from the client
- generating a server certificate for this site
- signing the certificate with the root certificate specified in the settings of the program
- sending the certificate to the client
- establishing a secure connection with the client
- establishing a secure connection with the external server
- receiving requests from the client and forwarding them to the external server
- receiving the result from the external server and forwarding it to the client
- closing secure connections
It is obvious from the described algorithm that SSL Decoder acts as an SSL Proxy that receives requests from users and returns results to them.
The algorithm contains several important issues that need to be explained:
- certificate generation
SSL Decoder acts as a full-featured certificate authority, such as, for example, VeriSign, Equifax or Thawte. But certificates it issues have two basic differences:
- they are free
- nobody trusts them
- signing the server certificate with the root certificate
For the server certificate issued by SSL Decode to become fully functional, it must be signed. It is signed with another certificate called the root certificate. Until you give the program some root certificate, it will not be able to work. Read more about certificates in one of the following sections.
You should know that there are sites it is impossible to work via SSL Decoder with. These sites require client certificates. Usually, client certificates are installed into certificate storages in users' browsers on their local computers and it is impossible to access their keys. Thus, SSL Decoder cannot get an object from the site on behalf of the client because the server requires that the client (SSL Decoder acts as a client in this case) confirms its trustworthiness with a personal certificate, but SSL Decoder cannot do it because it does not have the required certificate. As a result, the connection is closed.
Unfortunately, it is impossible to access these sites when SSL Decoder is running. You should add the URL of such a site to the white list.
So, SSL Decoder splits any secure connection into the following phases:
- accepting the client, analyzing the requested data, generating and sending the server certificate
- receiving a request to get some object from the secure site and forwarding this request to ISA Server (Forefront TMG)
- sending a request via the secure connection to the external web server
The first two phases are performed by the component that accepts client requests: data is decrypted and sent in the open form. The third phase is performed by the component that sends client requests to the Internet: requests received in the open form are encrypted and sent to the Internet.
These components are built into the program and do not depend on each other. And they can run on different ISA Servers (Forefront TMG) (makes sense for ISA Server Enterprise Edition).
The following work scenarios are available in the program:
- Scenario 1. Do nothing
The program is installed, but disabled. SSL requests are not processed. This scenario is used when you need to temporarily disable the application without removing it from the system.
- Scenario 2. Decrypt and Encrypt
It is the most frequently used work scenario. And it is the only possible one in case you use ISA Server (Forefront TMG) Standard Edition. Both components mentioned above will be active in case of this scenario. The first one will decrypt a request from the user, process it and forward it to ISA Server (Forefront TMG) in the open form. The second component will receive the request, encrypt it and send it to the Internet. As a result, the entire traffic will pass through ISA Server (Forefront TMG) in the open form and will be encrypted before it is sent outside.
- Scenario 3. Decrypt outgoing HTTPS requests
This scenario can be applied in case you use ISA Server Enterprise Edition. According to this scenario, requests outgoing from the user will be decrypted and forwarded to ISA Server (Forefront TMG) in the open form. This scenario may be good if you have an array and several ISA Servers (Forefront TMG) on your LAN. If all these ISA Servers (Forefront TMG) finally forward requests to the edge ISA Server (Forefront TMG), you can use a separate installation. That is, select scenario 3 on the server accepting clients and select scenario 4 on the edge server. What are scenarios 3 and 4 for? To increase performance. To avoid double or triple encryption/decryption, you can install SSL Decoder separately at the ends of the chain of ISA Servers (Forefront TMG) only. But even if you use arrays and several ISA Servers (Forefront TMG), it is always possible to install SSL Decoder only on one edge server and select scenario 2.
- Scenario 4. Encrypt previously decrypted requests
This scenario is the continuation of the previous one. SSL Decoder must use this scenario on the edge ISA Server (Forefront TMG) only. Attention! In case you select scenario 3 on one of your ISA Servers (Forefront TMG), but do not select scenario 4 on the edge server, SSL requests will not be processed or they will be processed with errors. As a result, users may see messages about problems connecting to the requested sites in their browsers.
To grasp a better understanding how each scenario works, you can use the following chart:
As we mentioned before, the installation of the program may (hypothetically) slow down processing SSL requests. It happens because the original SSL connection from the client (the stage of establishing the tunnel) is split into three phrases: from now on, and all requests received from the client browser via the encrypted connection require additional processing by ISA Server (Forefront TMG). It is more noticeable with old web servers using the HTTP/1.0 protocol.
- the number of old servers is constantly decreasing on the Internet
- the amount of SSL traffic is most often small as compared to the entire traffic
- nowadays computers are fast, powerful, have a lot of memory and actually have an superfluous performance rate
- after decryption all requested objects will be put into the ISA Server (Forefront TMG) cache and quickly retrieved from it in case they are requested again
a slowdown due to encryption/decryption will be imperceptible for the user and will be recompensed by the above pluses.
Certificates. Root certificate
Any SSL requests use certificates. What is it?
In plain words, certificates represent a secure replacement for the login/password pair. A digital certificate contains information about the person, the company or the website this certificate belongs to, its public key, information about the organization that issued it, the validity period and the list of operations the certificate can be used for. Private keys are not stored in the certificate usually. Since private keys are the most important part, they should be stored in a secure place.
Certificates are issued by certificate authorities. What is it?
There are two types of certificates: self-signed and issued by a certificate authority. If you compare a digital certificate to a business card, self-signed certificates are like self-made business cards, while certificates issued by a certificate authority are like business cards created for you by a trusted authentication center. With rare exceptions, most systems do not work with self-signed certificates.
A certificate authority is an organization that is issues certificates, checks their validity and revokes them if necessary.
SSL Decoder works as a real certificate authority. Each time an outbound SSL request is received, SSL Decoder analyzes its parameters and issues a certificate confirming the trustworthiness of the site and then sends it to the client. The issued certificate must convince the client (its browser) that the visited site and the received certificate match each other. Otherwise, the browser shows a lot of warnings and recommends that the user not visit the secure site. For example, this is what this warning looks like in Firefox:
And this is Internet Explorer:
There are two conditions must be met in order to convince the browser that the certificate is valid:
- the certificate must be signed by a trusted certificate authority
- the client browser must trust this certificate authority and, as a result, all certificates signed by this authority
The first condition is met quite easily: just create a new root certificate in the program using a special dialog box, or if your company is actually a competent and authorized certificate authority, let the program have the file containing the root certificate. In both cases, the most important moment is that this root certificate must have private keys. Otherwise it is impossible to sign issued certificates with it.
The second condition is more difficult to meet. To do it, you should export a certificate from the program (without private keys) and distribute it throughout your company. This certificate must be installed on each computer and in each client browser into the Trusted Certificate Authorities section.
This is what it looks like in FireFox:
And this is Internet Explorer:
If both conditions are met, users will see no warning messages while visiting secure sites if SSL Decoder is used.
See the appendix for additional information.
Generating a new root certificate
The dialog box for generating a new root certificate is opened with a click on the Settings button in the Root Certificate group. The process consists of several simple steps:
- Step 1. The certificate is not installed. Generating a new certificate.
- Step 2. The certificate has been created or loaded, verified, but not installed. Installing the certificate.
- Step 3. The certificate is installed. Viewing, backing up, deleting and exporting the certificate.
You can either generate a new certificate or load it from a file in this step. Certificates can be loaded in the most frequently used formats for storing certificates: PFX, CER, PEM.
Attention! The file the certificate is loaded from must contain private keys.
To create a new certificate, click the Generate New Root Certificate button. It will open the following dialog box:
You should specify the parameters of the new root certificate in the fields of this dialog box. It will be logical if you specify you company's attributes. A new root certificate will be created after you click the OK button.
You can view the certificate with a click on the View… button and install it with a click on the Install Root Certificate button in this step.
All operations involving creating and installing the certificate have been completed. SSL Decoder is completely ready to work. In this step, you can view the certificate, delete it in order to create or load another one or back it up.
Attention! Private keys will be saved when you back up the certificate.
Besides, you can use this step to export the certificate to a file for it to be later distributed on your company's client computers. Private keys will not be exported in this case. It is possible to export the certificate into the most frequently used formats for storing certificates: PFX, CER, PEM.
See above why it is necessary to distribute the certificate on client computers.
The following additional settings are available in the program:
- website white list
- additional service settings
The white list is used to specify the list of sites that must be excluded from processing. If you have any problems with accessing some secure site or some site makes use of client certificates, you can exclude this site from being processed by the program. SSL Decoder works with the white list with the help of objects standard for ISA Server (Forefront TMG), like Domain Name Set. It means that you only need to create a new Domain Name Set and add the site to exclude to it or add it to an existing Domain Name Set. After that you will have to tell the program that all sites from your Domain Name Set must not be processed. You can do it in the application parameters with a click on the Settings button in the White Lists area.
The Additional Settings dialog box looks like this:
Modify Web Proxy log files option
When SSL Decoder encrypts/decrypts data, it initiates all kinds of outbound requests. In fact, these requests are made FOR the client, i.e. SSL Decoder itself gets the content requested by the user who initiated the SSL connection and then gives it to him. If you analyze ISA Server (Forefront TMG) log files after these operations, you will see in them that:
- the user connected to ISA Server (Forefront TMG) and initiated a secure connection
- ISA Server (Forefront TMG) established a connection to the external secure web server whose content the user wanted to get.
- ISA Server (Forefront TMG) requested the necessary object from the secure web server
- ISA Server (Forefront TMG) got the object and sent it to the user
- the user closed the connection
- ISA Server (Forefront TMG) closed the connection
As you can probably see, all requests initiated by ISA Server (Forefront TMG) are actually requests initiated on request from this user. That is why it would be logical if they were shown in the log as if they were initiated by the user. It will allow you to get a more logical picture of the user's requests.
If the Modify Web Proxy log files option is enabled, SSL Decoder will modify Web Proxy log files in such a way that they look as if the service requests were initiated by the user that initiated the original SSL connection.
Enable connection errors logging option
If this option is enabled, SSL Decoder will save information about errors (if any occur) to a special debugging log file. This file will help the support service to understand what caused the error.
Configuring Microsoft ISA Server (Forefront TMG) to work with SSL Decoder together
SSL Decoder can work with Microsoft ISA Server 2004 and 2006 and Forefront TMG. Both Standard Edition and Enterprise Edition are supported.
As soon as SSL Decoder needs the Internet access for downloading secured objects, you have to enable access from Local Host to External for it. You can do this by creating a special Allow rule. Like this one, for example(Please note that you must to select "All Authenticated Users" on the rule's "Users" tab):
or like this one
Testing the application
How to make sure that the program is running and successfully performs its functions:
- view Web Proxy log files
When the program is enabled and running, you will see the complete URLs of objects requested by the user after you analyze log files (for example, with Internet Access Monitor for ISA Server). Besides, you will see the amount of inbound and outbound traffic for each requested file.
- configure Response Modifier
Try configuring Response Modifier to replace some words with others. After that visit some secure resource and make sure that substrings are replaced.
- view the certificate
Use the View the secure site certificate option in the browser while being on a secure resource. You should see the certificate created by SSL Decoder and signed by the roots certificate that you created or loaded to the program.
In case the program does not work, the entire SSL traffic will be processed as it was before. It means that after the client closes the connection, only one line will be visible in the log files, and you will not see what was requested and sent within this connection. You will not be able to check requested objects for viruses or modify their content as well.
The compatibility of SSL Decoder with other applications from ISA Server (Forefront TMG) Toolkit and with products from third parties.
All products in ISA Server (Forefront TMG) Toolkit are closely connected with each other and run as a single chain. The order according to which each web filter is accessed is maintained by ISA Server (Forefront TMG) and depends on the priority of each filter. To avoid conflicts between programs, you should follow the below rules:
- SSL Decoder must be always HIGHER than the Client User Name Resolver filter in the list of web filters
- SSL Decoder must be always HIGHER than the Advanced Web Routing Rules filter in the list of web filters
- You should realize that web filters from third parties and SSL Decoder may conflict with each other. That is why in case of any problems with getting access to a secure site, you should make sure that the problem does not lie in a conflict with some other software product. To do it, you can TEMPORARILY, for testing purposes, try disabling the alternative web filter. If it solves the problem, you should contact our technical support service with the detailed description of the problem.
It is up to every administrator to decide the level of danger the use of SSL traffic may present for the company. If the risk of losing important data, infecting computers or ignoring permitting/forbidding access rules by users is low, it does not make much sense to use the program.
However, if you think that this issue considerably reduces office security, if you want to analyze visited sites, if you want access rules to work no matter whether a secure or insecure connection is used, SSL Decoder is exactly what you need.