Dear Gaël,
I think you can handle your need with the following.
On Son 13.12.2009 22:05, Gaël Reignier wrote:
Hi Willy and thanks for your reply!
I actually discovered that during the cross site authentication, we had
HTTP and HTTPS requests that run on 2 different sub domains. And the
HTTP and HTTPS request have to be handled by the exact same backend.
On top of that, we have pound doing SSL termination on our SLB, it does
some HTTP flag rewriting.
The thing is that in HAProxy you do HTTP on the layer 7 so we can use
the cookies and have persistent HTTP transaction with the backend.
But HTTPS is done on the layer 4 so no cookies for us and then the
connection are not persistent to backend servers.
In those conditions, we had authentication failures.
We tried several configuration with Pound listening on port 80 and 443
and redirecting everything locally on port 81 on haproxy. Then all the
requests were handled by the exact same backend but unfortunately the
request for HTTPS where handled by a different backend as there were no
cookies on those connections.
We tried doing port redirection with iptables with port 80 redirected
to port 81 (where haproxy was listening).
And basically at the end, we had to do our SLB with pound (but I think
HAProxy is much better and by far!!).
But if you have a solution with HAProxy, I would be delighted to apply
it and use it!
Maybe the appsesion feature can help you.
The appsession saves not only the cookies also the sessionid in the URL
e.g.: ....;jsessionid=.... ;
maybe you just have used the wrong tool ;-), have you tried to use
stunnel for ssl termination or nginx instead of apache, if you need a
real webserver not only a ssl<=>http 'translator'?
http://haproxy.1wt.eu/download/1.3/doc/architecture.txt
3. Simple HTTP/HTTPS load-balancing with cookie insertion
3.1. Alternate solution using Stunnel
maybe nginx as frontend
3.2
####
nginx port443
proxy_pass http://127.0.0.1:81/;
listen 127.0.0.1:81
...
####
I hope you get the idea.
BR
Aleks
Thanks a lot in advance!
Au revoir et a bientot!
Gael
On Thu, Dec 10, 2009 at 8:45 PM, Willy Tarreau <[email protected]> wrote:
Hi Gaël,
On Wed, Dec 09, 2009 at 04:47:17PM +0000, Gaël Reignier wrote:
> Hi everybody,
>
> I have installed and configured HAProxy with pound in order to have SSL
> termination at the SLB level and it worked OK until today and we
discovered
> a problem that does not make sense to me, I will try to explain it here:
>
> So we have a website that does cross domain authentication with SSL: From
> www.site.com you are authentication against my.site.com
>
> Number of server:
> When I have only 1 web server behind the SLB, everything is working
> perfectly fine.
> When I have 2 or more web servers behind the SLB, I am experiencing the
> problem.
>
>
> Cookies activation:
> Here is how I activated the cookies:
> cookie HAPROXYID insert indirect
> server gr-web04 10.10.5.14 weight 10 check port 80 fastinter 1000 cookie
> gr-web04
>
> When the cookies are turned off, I notice the problem from time to time:
> roughly once every 20 clicks
> When the cookies are turned on, the problem happens once every 2 clicks
(so
> in 50% of the cases).
>
>
> Explanation of what I am seeing:
>
> The first request are going to the first web (http://www.site.com) site
in
> clear (HTTP) then they are going to another part of the site (
> https://www.first.com) through SSL.
> When it works you are then redirected to http://my.site.com and you
carry
> on...
>
> As I understand the problem happens as the result of the script ran
during
> the SSL connection (I am sure the script works as when there is only 1
> webserver for http and https, it works perfectly fine).
> But I believe that when it is load balanced to another server in order to
do
> the SSL connection, then it is not happy...
> I have noticed as well that the communication on www.site.com are done
on
> server A whereas communication on my.site.com are done on server B when
it
> is successful...
>
> I have now spent a couple of days on the problem and I do not understand
why
> I am having is really random behaviour ... That does not make sense to me
at
> all.
>
> If you want more information about the problem please let me know and I
will
> be happy to give you all the information you need!
I can give you some hints because I've been facing comparable issues
recently. Basically, by default, a browser will only send a cookie to
a server if it has the exact same host name as the one it learned the
cookie from.
RFC 2109 allows a cookie to have domain attributes to extend the
validity of the cookie to other hosts. You could very well say that
your persistence cookie is valid for ".site.com", which means that
a browser which will receive it will present it on both "www.site.com"
and "my.site.com". But it will also present it on any "xxx.site.com"
host, which may or may not be desirable. Now the RFC is slightly more
precise. It says that a browser must not present the cookie for
"yyy.xxx.site.com" if it was set for ".site.com". But both MSIE and
FF don't apply this restriction which would probably break a number
of sites. The RFC also forces a domain to start with a dot (which
also prevents any IP address to be used). Both browsers don't care
about this. Furthermore, the RFC says that a browser should ignore
a cookie set for a domain different from the one that returns it.
That means that you can't expect a cookie for ".site.com" to be
set by "www.first.com". FF applies this restriction, but MSIE does
not care, which is sometimes very helpful. Last, the RFC does not
forbid the setting of multiple domains with a cookie. FF only
accepts a cookie if the last domain is OK. MSIE happily learns
all the domains at once (tested with up to 10).
So with all that in mind, you should try to write down all the
path between the moment a browser connects to the first page of
your site and the moment it reaches the final page, and check
where the set-cookie are performed, so that you can ensure that
this correctly works in your case. And try with FF more than
with MSIE, that last one caught me, making me think that my
first solution was OK :-/
Regards,
Willy
--
Gaël Reignier
Contacts :
mail : [email protected]
Twitter: gael.reignier
Skype: gael.reignier
Facebook
GSM UK: 0044 7 942 042 374
GSM FR: 0033 6 2306 8929
