Securing client requests is becoming more and more of a concern in most organizations. Management and users are paranoid in large organizations that other users of privileged status (IT staff) can read their web client requests. Some users within the organization might be using internet banking or viewing unprotected sensitive information. If you are in such an environment you can use SSL to secure your users connections to those servers and will comfort your users once you explain to them how the technology works and prove to them that there is no way any one can read their request you will find them to be much happier with the whole situation because they have been educated.
Questions asked by users that may trigger you to look into using your ISA to allow SSL through it either using bridging or tunneling mode.
- Can we use internet banking?
- Can we access secure websites?
- How can we tell if we are accessing secure websites?
- When are our connections encrypted?
- How can we be sure that when sing the internet banking that no-one is getting our information on the network?
- Is all internet traffic encrypted if not why not?
Answers to the users questions.
- Internet banking is accessible if SSL has been allowed through ISA.
- Yes you can if SSL has been enabled.
- There is normally a locked lock at the bottom right hand side of your web browser when the website is secure. In the URL HTTPS can also be displayed and this also means that the site is secure.
4. When you are accessing a secure website.
5. The information sent to your internet banking website is typically encrypted, and depending on the bank and the countries legislation I can be either 40 bit encryption or 128 bit encryption. If someone wee to sniff that information from the network the information would not be any good to them as they typically do not have the ability to decrypt it.
6. No, encryption and decryption place overhead on server resources and also on the client machine, there is no use to encrypt data or requests that have no value to anyone and therefore most request are not encrypted. Typically requests are encrypted when you are dealing with sensitive information like banking details, credit card numbers, government documents, online registration forms that require personal details and or privileged information and any information that you will submit over the internet that you feel should not be given to any other person.
What distinguishes SSL bridging from tunneling?
SSL tunneling is when an Internal LAN client browser requests a web object using HTTPS on port8080 through the ISA Server computer. An example of this is when you are using internet banking. The internet connection to the target banking website is tunneled to by you through ISA. The key word here is through. The ISA client communicates with the target web server directly after the initial connection has been established by ISA, by means of communication within the SSL tunnel that has been created after SSL negotiation has taken place.
The figure above displays how SSL tunneling works.
- An ISA client request a web object from a web site
- ISA forwards the request onto the web server
- ISA connects to the web server on the SSL port 443 or 563 depending on the configuration.
- ISA informs the client that the connection has been established and hands the connection over to the client.
A. The client communicate with t he web server directly without any intervention from ISA through the SSL tunnel that has been established.
SSL bridging is the termination or initiation of an SSL connection by ISA. An example of this is when an ISA client requests an HTTP object. ISA acts on the clients behalf and encrypts the request then forwards it to the target Web server. The encrypted object to ISA and the object gets decrypted by ISA and then sent to the client that requested the HTTP object.
SSL bridging enables ISA to encrypt or decrypt client requests when passing the request to a target Web server.
ISA will intercept the client request as it gets sent to the web server. ISA will then act on behalf or proxy the request to the web server and return to the request result (normally a webpage or file) to the client. In this way the client does not deal with the web server directly, increasing security.
Figure 1 a: For example, in a reverse publishing scenario, ISA Server can service a client SSL request by terminating the SSL connection from a client and reopening a new connection with a Web server. This is also called SSL bridging.
A possible reverse publishing scenario
- A connection is made by the client requesting the web object to ISA server
- ISA server sends the server side certificate in order t authenticate itself proving that the server is who it says it is
- The user encrypts the request and forwards the request to ISA server.
- ISA server decrypts the request and checks its own cache if the object is not to be found it re-encrypts the request and connects to the target website requesting the object from the web site
- the web site responds and the encrypted object is passed to ISA
- ISA sends the already encrypted object to the client so that it can be decrypted and viewed.
Different scenarios can arise and typically ISA encrypts the request on behalf of the client as and this further distinguishes the reverse publishing scenario from standard ISA SSL bridging.
In the tutorial titled Using ISA to force SSL connections to published websites I show you that you can easily configure your website to ask for a SSL connection.
How ISA deals with SSL requests.
ISA deals with an outbound request by processing any request hat is directed to ISA that points to either port 443 or has an Https affiliation. IF a routing rule exists to bridge the request then ISA processes the request according to the routing rule. If there is no routing rule then the request is processed as you have specified in the ISA rules and policies. You can change which port listens for SSL requests, Look at the diagram below.
The typical port settings are displayed above I would advise to keep the port set to 443 as this is the default setting and simplifies matters when troubleshooting.
Inbound SSL requests is when an external client requests a web object that resides on a published web server on your network. The external connects to your ISA’s external NIC on port 443 and a server side certificate is sent to the client the ISA server retrieves the web object and forwards the encrypted object to the external requesting client. Various configurations can occur and this will determine how the client communicates with the web server.
Summary: Many organizations have looked into SSL and backed off for lack of resources or not understanding the technology. Some implement the technology n have it working but can not tell when the technology is functional or inactive. In this tutorial I hope to clear up some of the issues you may have with both SSL bridging and SSL tunneling.