5

I have a Forefront TMG 2010 acting as a reverse proxy:

  • I can force HTTP*S* between internet clients and TMG.
  • I can force HTTP*S* between TMG and my web servers.

From a security point of view, it is a best practice (correct me if I'm wrong) to force HTTPS between internet clients and TMG. This would allow the reverse proxy to decrypt the traffic and analyse it for attacks. Is this correct?

But what about the traffic in between TMG and the web servers? Would you force it to be HTTPS? If yes, what are the security benefits of doing so?

|improve this question|||||
6

The standard answers is, use secure connections from the frontend to the backend servers as well.

In the following situation it may be okay and common to use unencrypted connections:

  1. The network infrastructure between frontend and backend is considered secure. For example a dedicated hardware network which ensures that no unauthorized sniffing or modification of traffic is possible. The switch should be setup in a way that prevents ARP cache poisoning and ARP cache flooding because servers might fall victim to an attack and turn hostile.

  2. And the traffic is so high that decryption poses a significant load on the backend servers.

|improve this answer|||||
  • +1 for recommendation to use SSL wherever you can. – Steve Dispensa Sep 7 '11 at 13:31
0

SSL comes at a big performance cost - particularly for HTTP. OTOH its the most pracitcal way to protect against MITM and eavesdropping - when there are impacts on functionality/usability it's only 'best practice' to add protection where there is something which needs protection.

If there is a risk of eavesdropping/MITM between the proxy and the webservers then it makes sense to secure the connection - however that is rarely the case (except where the proxies are part of a CDN).

"and analyse it for attacks" - terminating the SSL on the proxy means that you rely on the functionality available from the proxy for any analysis, depending on how this is implemented you might, for example have no visibility of client certificates at the webserver. Note that for SSL-SSL, if the proxy is truly a HTTP proxy then it will decode the SSL and re-encode it again - so you have no greater visibility of the client-proxy SSL behaviour than when not using SSL between the proxy and webserver.

|improve this answer|||||
  • 1
    I disagree - there is a performance cost, but it is minimal.. – Steve Dispensa Sep 7 '11 at 13:32
  • 1
    I disagree too - when we looked at stats on a global bank across many hundreds of web servers, the SSL overhead was not one of the 5 key performance factors. That said, where possible, SSL was offloaded to boxes immediately before the web farms. – Rory Alsop♦ Sep 7 '11 at 15:02
  • Early offloading does not solve the problem of an additional (avg) 2.5 RTTs per request - which is the performance problem with SSL (now that the MSIE keepalive problem has dropped off the map). If your site performs so badly that this is negligible then you've got other things to worry about. – symcbean Sep 9 '11 at 11:59
0

The main reason to run SSL between the TMG and the end users is the same one you would run any VPN - you want privacy and authentication when talking to your clients. You don't for example, want any idiot with a backtrack CD to be able to skim your Sharepoint or OWA as it's being accessed. Worse, not all enterprise apps are even smart enough to use strong password-management or cookie-management techniques, and you don't want that information to leak.

Just because it's a web app doesn't mean it doesn't need a VPN, and HTTPS between the TMG and client checks the box.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.