Hi guys,
On Mon, Dec 14, 2009 at 01:21:12PM +0100, Aleksandar Lazic wrote:
> 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.
I second Aleks on this. If you're having domain name incoherencies,
those can only be fixed at the domain names themselves, though
appsession might be one workaround if your application server is
able to emit URL cookies.
Let me give you an example :
http site: www.site.com
https site: www.secure.site.com
Client goes to http://www.site.com/ and receives a cookie. The cookie
does not specify any domain so it's only valid for this exact host.
When the client goes to https://www.secure.site.com/ it will not
present the cookie.
One workaround you'd think about would be to assign a domain to your
set-cookie. For instance, ".site.com". But one host would be "www",
which is OK, but the other one would be "www.secure" which the RFC
explicitly states as not matching ".site.com" because it contains a
dot. Fortunately, MSIE and Firefox don't care about this restriction
and will happily send the cookie. But for how long ? Mystery. Once
someone finds a way to exploit this and turn it into a security issue,
the hole will be closed and it won't work anymore. And I don't even
know if all browsers currently support this !
The only portable solution would be to run either the same host name
(ideal) or at least a different one but with the same number of
components as the original one so that both only differ by exactly
one word. Then you can use the common part in your set-cookie. You
must do this both in your application and in haproxy though.
In haproxy, this is done by appending the "domain" statement on the
cookie line. Example :
cookie SERVERID insert indirect domain .site.com
Also, you said you were using apache for the HTTPS -> HTTP conversion.
You should be careful, because apache in proxy mode by default rewrites
the Host header and replaces it with the host part you have in the
ProxyPass rule. In recent versions you can disable this misdesign by
adding a ProxyPreserveHost directive. It is very possible that your
application itself does not work when it receives a wrong Host header.
It is also possible that your application already sets the domain on
the cookie but sets it based on the Host header it receives, which
would explain why a browser would not learn it.
I'm hoping this clarifies some things a little bit. If not, please
post a more concrete example of the issue you're encountering (if
possible some log extracts in which you'd simply replace some IP
addresses).
Regards,
Willy
