Vraag over loadbalancer

[darklydreaming]

Wij hebben bij onze hosting provider een loadbalancer draaien (Brocade ADX geloof ik).
SSL termination wordt gedaan op de loadbalancer.
Over port 81 gaat het verkeer vervolgens naar de webserver.

Echter, als ik naar de URL ga, dan wordt er een / achter gezet en wordt het http://

In IIS logs kan ik alleen het volgende terugvinden:
2013-02-26 13:58:26 192.168.200.23 GET /systemmanager - 81 - 195.35.217.98 Mozilla/5.0+(Windows+NT+6.2;+WOW64)+AppleWebKit/537.22+(KHTML,+like+Gecko)+Chrome/25.0.1364.97+Safari/537.22 301 0 0 483

Voor zover mijn kennis gaat heeft onze software hier niets mee te maken. Het lijkt erop alsof IIS er een / achter zet en naar http:// omzet. Maar waarom zet de loadbalancer deze dan niet weer om naar https://

Iemand een idee waarom dit optreedt en hoe dit op te lossen is?

[ Voor 11% gewijzigd door darklydreaming op 26-02-2013 19:43 ]

[Rolfie]

Mijn eerste reactie is dat het in de config van de load balancer zit, voornamelijk in de redirect van https naar http.
Maar je config in IIS ook eens goed nalopen, als ik je IIS logfile bekijken, zien we de 301 staan. Of wel IIS doet een redirect. Waarom, kan ik de applicatie zitten, of in IIS zelf.

[CyBeR]

Je server stuurt een redirect naar een url met / erachter en weet niet dat dat een https:// url moet zijn. Dit is een configuratieissue ofwel in je server software (apache, iis) ofwel in je applicatie. (Gegeven dat 't een redirect is naar dezelfde url met een / erachter gok ik dat eerste.)

[_-= Erikje =-_]

Rabobank microsites ?

[Rolfie]

CyBeR schreef op dinsdag 26 februari 2013 @ 17:22:
Je server stuurt een redirect naar een url met / erachter en weet niet dat dat een https:// url moet zijn. Dit is een configuratieissue ofwel in je server software (apache, iis) ofwel in je applicatie. (Gegeven dat 't een redirect is naar dezelfde url met een / erachter gok ik dat eerste.)

Zou met SSL offloading te maken kunnen hebben. Dit moet je vaak speciaal configueren op een server indien gebruikt is/wordt.

zou een goede verklaring kunnen zijn van het issue.

[_-= Erikje =-_]

Ik weet dat er loadbalancers zijn die dit soort redirs zelf afvangen en rewriten naar https (Cisco ACE)

[ACM]

Bij SSL-termination zal er tussen je loadbalancer en je webserver gewoon HTTP-verkeer plaatsvinden. Hoe moet je webserver danwel webapplicatie-software dan weten dat ie net moet doen of het https was?

Bij dit soort vrij complexe opstellingen zal je daar goed naar moeten kijken. Wijzelf gaan het met Tweakers opzetten door vanuit de loadbalancer een header te vullen en dan als die gevuld is de request als HTTPS behandelen (net als we nu al in PHP naar $_SERVER['HTTPS'] == 'On' moeten kijken).

Het kan hier dus zijn dat je eigen webapplicatie iets moet doen, dat je webserver iets moet doen en/of dat je loadbalancer iets moet doen. Het is niet ongebruikelijk dat je loadbalancer de uitgaande response nog kan modificeren alvorens het door te sturen. Die zou je dan uiteraard alle tekst/url's met http://jouwdomein kunnen laten omzetten naar https://jouwdomein. 't Wordt dan wel wat tricky als bepaalde urls juist niet naar https zouden moeten lopen...

[vliegjong]

Neem aan dat er een Two Way URL rewrite plaatsvindt toch? Dus de clients komt aan met een Connect op ssl://mijndomein.nl, zet de SSL sessie op met de ADC. Vervolgens in het SSL tunneltje doet hij een HTTP GET naar / op Host: https://www.google.nl.
Je ADC rewrite dit naar GET / Host http://www.google.nl en stuur dit naar de backend server. Server geeft een 200 OK met wat Data in zijn response. De webserver zal 9 van de 10 keer idd HTTP urls gooien omdat de server uitgevraagt wordt op zijn http server (lees het SSL offloading, Rewrite verhaal).
De reactie van de server met daarin HTTP:// herschrijf je terug naar HTTPS:// (Lees de Two Way URL Rewrite).
Verder kan je idd gebruik maken van een additionele request header vanuit de ADC met bijvoorbeeld FrontEndHTTPS=on (voor OWA) om de backend webserver te laten weten dat je offloading doet en dat de webapp (PHP, .NET) HTTPS:// URI's maakt voor een HTTP Request.

[Kabouterplop01]

Kun je zien in view source of met firebug wat het ip adres is waar je antwoord van krijgt?

In eerste instantie lijkt het een redirect fout, of de loadbalancer is ingesteld als Direct server return. Dit houdt in dat het teruggaande verkeer niet door de loadbalancer gaat, maar rechtstreeks van de server terug. (vandaar dat het http is)
het teruggaande verkeer moet uiteraard terug door de loadbalancer in dit geval.

[CyBeR]

nm.

[ Voor 98% gewijzigd door CyBeR op 05-03-2013 17:19 ]

[vliegjong]

Zou idd ook nog direct server return kunnen zijn. Dan mag alleen die lb geen proxy spelen anders ben je out of state maar het kan idd ook nog. Echter als je ssl ofload doet ben je imho een l7 proxy aan het spelen...

[darklydreaming]

Bedankt voor alle reacties!

Onze hostingprovider kan ons helaas niet verder helpen. Zij kunnen alleen op de loadbalancer instellen dat alles naar https:// wordt omgezet, maar sommige URL"s willen we niet omgezet hebben naar https://

We hebben nu een eigen Courtesy Redirect module geschreven die alles goed verwerkt.

[CyBeR]

Let bij dat soort redirectgeintjes wel op dat er geen data naar geredirecte (non-ssl dus) urls gestuurd wordt.

[Olaf van der Spek]

ACM schreef op woensdag 27 februari 2013 @ 08:04:
Bij SSL-termination zal er tussen je loadbalancer en je webserver gewoon HTTP-verkeer plaatsvinden. Hoe moet je webserver danwel webapplicatie-software dan weten dat ie net moet doen of het https was?

Niet. Met relative redirects hoeft ie het toch ook niet te weten?