Users, whether they be your corporate users, or users who connect from the Internet to resources you host, put their trust in you. This is especially true when it comes to secure connections. When your users see that little lock in their browser window, they come to expect that the connections from their computers to your computer is secured by SSL. Don’t you, as a network admin interested in security, expect the same thing?
I know that I do.
Now, imagine that this trust is broken. The user who believes that his connection to your server does in fact not have a secure connection to your server. Instead, that user is actually connecting to your server through a reverse proxy device that terminates the connection before it reaches your Web server, and then forwards that connection in an unencrypted form to your Web server. In this scenario, the connection is trusted (secure) to the reverse proxy server, but then is untrusted between your reverse proxy server and your Web server.
Why would anyone put together such a solution? In fact, this is a very common setup for secure Web sites accessible over the Internet. This practice is often referred to as “SSL Offloading”. By terminating the secure SSL sessions at the reverse proxy server, they offload the SSL processor overhead from the Web server to the Web proxy, making more processor cycles available to the Web server for providing the information requested by the users.
While SSL offloading sounds nice (at least to the Web server administrator and the person who pays for the Web server hardware), doesn’t it violate the trust your users’ put in you? Doesn’t it violate the trust that your users have that their connections are secure from end to end?
It sure does. Your users trust that the connection is secure from end to end, period. When they see the little lock icon in the browser window, they assume an end to end encrypted session. There are no warnings in the the browser window saying “you have a secure connection to the server’s Web proxy server, but after that, you’re going to have to trust that your information is no longer secured by SSL and hope that the network between the Web proxy server and the Web server you thought you were securely connecting to is free from intruders”.
Of course, no one puts that kind of information on their Web pages. But what would happen if customer’s information is stolen while it is in transit on the unsecured connection between the reverse proxy and the destination Web server? How would you explain that to the court? Do you think the judge would accept your explanation that you didn’t want to scale up your processor or didn’t want to buy an SSL offload card?
For these reasons of trust and liability, I recommend that you never use SSL offloading. The only exception is if you decide to use some type of crossover cable between your reverse Web proxy and the destination Web server, or if you choose to use IPsec between the reverse proxy and Web server. But if you’re going to use IPsec, why not avoid the complexities of IPsec and just let the SSL connection go from end to end? Most sophisticated Web proxy servers will terminate the SSL connection and reinitiate it (like the ISA Firewall’s Web proxy Filter capabilities). So just use SSL all the way, from end to end.
HTH,
Tom
Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: [email protected]
MVP – Microsoft Firewalls (ISA)