SSL Offload breaks Authentication

[ryan.jensen]

Hello,

I'm trying to get SSL Offloading to work with an new web-app we're bringing online.

It's meant to run over http between client and server. If i configure STM Virtual server as port 80, it works fine.

Main page displays, user can enter credentials to login or hit the "Use Windows Credentials" button.

I'm trying to get this to work properly with SSL Offloading.

When i enable SSL Offloading, I have to use an HTTP response rule to re-write the returned content to call all https URLs. I use this rule for that:

#$url = http.getResponseHeader( "Content-Type" ); 

#if( !string.startsWith( $url, "text/html" ) ) break;

$response = http.getResponseBody(); 

$response = string.replaceAll( $response,  

  "http://server.domain.org/", "https://server.domain.org/" ); 

http.setResponseBody( $response );

Yes, I have the sanity check commented out. The main login page calls some .ashx files that dont have the content type in them so they aren't re-written. Even more stuff breaks then.

The problem I'm seeing is that even though I get the login page to load over SSL now, there are no mixed-content security issues or cert issues, I cannot login. My credentials no longer work to access the app. I cannot manually enter credentials nor does the "Use Windows Credentials" work. Of note, when I use windows credentials via HTTPS, i see my machine doing a kerberose authentication to AD. When over HTTP, I do not see this same transaction. It would appear i'm athenticating to AD properly, because I can do it repeatedly and my AD account will not lock out.

Has anyone dealt with anything similar and gotten it to work? Thanks in advance.

[silver78_1]

Hi Ryan,

sometimes happens (ex.: SharePoint) that webApp send compressed responses (ex.: javascript) that your ResponseRule can't process.

Try to add a RequestRule with:

     http.removeHeader( "Accept-Encoding" )

This prevent node giving compressed responses and permit to your ResponseRule to work on it.

You can also try to use "string.replaceAllI" instead of "string.replaceAll" in case of some link isn't write at all in lowercase.

Check also response and request header, again sometimes you can found some header pointing to HTTP not to HTTPS.

Good luck
Stefano

[ryan.jensen]

Hi Stefano,

I did as you suggested. I created a request rule with just the suggested command.

I also modified string.replaceAll to string.replaceAllI.

I'm getting the same results. Authentication still fails.

I've looked at my source of the page and every URL listed in the page is https://, not http://.

How do I check the response / request headers? Unfortunately, I'm not a web guy, so this is not my strong-point.

Would you have any other ideas?

Thanks!

[bjarke.emborg.kragelund]

Hi Ryan,

How is your VS configured protocol wise?

I ( usually ) do not need to rewrite anything when offloading SSL with the STM.

Our VS's, when used as http -> https + offloading SSL on the STM in front of a vanilla http pool is something like :

Internal Protocol : HTTP

Port : 443

SSL Decryption

ssl_decrypt : yes

... and then choose an appropiate matching certificate.

No other rules needed. Or what could I be missing?

Our SharePoint 2010 / 2013 however needs a little magic via a TrafficScript response rule :

$host=http.getHostHeader();

$mime = http.getResponseHeader( "Content-Type" );

if (string.contains($mime, "html")||string.contains($mime, "xml")) {

  $body=http.getResponseBody();

  $source="http://".$host;

  $destination="https://".$host;

  $newbody=string.replaceAll($body,$source,$destination);

  $source="http:\\u002f\\u002f".$host;

  $destination="https:\\u002f\\u002f".$host;

  $newbody=string.replaceAll($newbody,$source,$destination);

  if ($newbody != $body ) {

    http.setResponseBody($newbody);

  }

}

Otherwise nothing other than vanilla settings.

Best regards

Bjarke

[ryan.jensen]

Hi Bjarke,

I didn't think it'd be such an undertaking either....

The VS is setup just like yours. It's HTTP on port 443, I enabled SSL decryption and pointed to my wildcard cert for the site.

In theory it should be an easy setup, but of course, with my luck it's not working.

I've had similar woes with Sharepoint, but maybe I'll try your traffic script example and see if it does anything for me.

[silver78_1]

Hi Ryan,

I'm sorry for late response.

To check request and response headers you can use Chrome/IE typing F12 before to load your page.

This will open a new bar at the bottom of the browser window and inside the "Network" tab it's possible to look inside every item of your page downloaded by the browser.

If you click on one of these items (ex.: yourscript.js) you can see detailed infos about the transaction related about it, included Request and Response headers.

Bye

Stefano