westpac bank alert
Your Westpac online has been temporary suspended. To confirm your Westpac Internet banking account status please "LOGIN"
Re: HA-Proxy version 1.5-dev21-51437d2 2013/12/29 sticky ssl sessons are not working in my environment
Hi, Have been wondering about if/how i could persist ssl sessions between servers myself if i ever need it. And found the concept of a SSL-session-id rather promising, then after looking into how to use it and its reliability i found some articles saying it might not be wise.. https://www.f5.com/pdf/white-papers/cookies-sessions-persistence-wp.pdf "SSL persistence was suddenly rendered inoperable" (in IE5) http://docwiki.cisco.com/wiki/Secure_Sockets_Layer_Persistence_Configuration_Example "SSL stickiness is generally deemed unreliable." "SSL stickiness is not recommended due to the numerous limitations that can break client persistence" Also one might need to enforce on the backend webservers that SSLv2 is NOT used. ("SSLv2 places the session ID within the encrypted data" according to the Cisco doc) So now the question arises, are current browsers (including on mobile devices) all sending the same SSL-session-ID properly during a hour of 'shopping'? Or are these described issues not currently applicable anymore with recent software/devices? I'm a bit doubtful if using ssl-session-id is actually a good way to enforce persistence. Or should one try to avoid it with ssl-offloading even though that puts more processing on a single haproxy instance thats more difficult to scale up.. And puts all certificates in a 'central' place which has some other security considerations.. I'm afraid i there are more questions than answers in my mail, but at least its some stuff to think about.. For myself its currently not a problem. In my small test with 1.5dev21 ssl-persistence seemed to work ok. Though only 1 client pc, with 2 browsers running and hitting F5 a lot, so hardly representative for a real environment... Still thought what i found might be useful for others. Greets PiBa-NL Lukas Tribus schreef op 3-1-2014 22:41: Hi, Hello , Many thanks for your replay. This thing is more stranger i downloaded and compiled serverl versions of HAproxy 1.5.x.x and the result was alwase the same I experimented with following versions At first i testing with http://haproxy.1wt.eu/download/1.5/src/devel/haproxy-1.5-dev21.tar.gz After i tested with these http://haproxy.1wt.eu/download/1.5/src/devel/haproxy-1.5-dev20.tar.gz http://haproxy.1wt.eu/download/1.5/src/devel/haproxy-1.5-dev18.tar.gz http://haproxy.1wt.eu/download/1.5/src/devel/haproxy-1.5-dev17.tar.gz latest downloded was haproxy-ss-LATEST.tar.gz from http://haproxy.1wt.eu/download/1.5/src/snapshot/ All the time the result was same Well, your make line looks very specific, whats the reason you use those CFLAGS manually and don't use on the other hand a specific TARGET? I suggest you give this a try: make clean; make TARGET=linux2628 CPU=native USE_PCRE=1 USE_OPENSSL=1 \ USE_ZLIB=1 With the custom make TARGET, you are not using epoll, falling back to the slower poll(). This shouldn't make any difference regarding the ssl affinity though. Regarding that, your configuration looks ok, and you have tested a different releases, which make me think the issue may not be in haproxy. How do you know HAProxy doesn't maintains the correct affinity? Are you tcpdumping the frontent traffic? Are you sure your backend servers have an session cache enabled and working? Regards, Lukas
RE: http-keep-alive broken?
Hi, > The problem I'm having (also tested with ss-20140101 yesterday) happens > with http-keep-alive enabled and also when just running in tunnel mode. > But, when http-keep-alive is enabled I get the problem with ~98% of the > requests and in tunnel mode I get it with ~10% of the requests. > Authentication seems to succeed but the connection just 'hangs'. > Sometimes refreshing 10 times fixes it. Ah, thats interesting. Then the issue is probably not directly related to keep-alive, it probably just triggered with a much higher likelihood. > I have downgraded to dev19 this morning and it seems that the problem > went away in tunnel mode. (http-keep-alive is of course not available) > > While I am not sure yet, it could be something broke during dev19-dev21. > This may sound a bit silly but connections to our IIS servers 'feel > faster and more responsive' when using dev19. > > I will build a small test environment to see if I can reproduce it and > capture some traffic. Right now it's just a hunch. All right. If you can reproduce it and perhaps even "git bisect" it, that would help a lot (but probably in tunnel mode, since keep-alive mode is not available in older releases indeed). You said that one of your backends is exchange 2012. What release are the other ntlm-auth backends exactly and is the issue the same on all of them? Regards, Lukas
RE: HA-Proxy version 1.5-dev21-51437d2 2013/12/29 sticky ssl sessons are not working in my environment
Hi, > Hello , > > Many thanks for your replay. This thing is more stranger i downloaded and > compiled serverl versions of HAproxy 1.5.x.x and the result was alwase the > same > > I experimented with following versions > > At first i testing with > http://haproxy.1wt.eu/download/1.5/src/devel/haproxy-1.5-dev21.tar.gz > > After i tested with these > http://haproxy.1wt.eu/download/1.5/src/devel/haproxy-1.5-dev20.tar.gz > http://haproxy.1wt.eu/download/1.5/src/devel/haproxy-1.5-dev18.tar.gz > http://haproxy.1wt.eu/download/1.5/src/devel/haproxy-1.5-dev17.tar.gz > > latest downloded was haproxy-ss-LATEST.tar.gz from > http://haproxy.1wt.eu/download/1.5/src/snapshot/ > > All the time the result was same Well, your make line looks very specific, whats the reason you use those CFLAGS manually and don't use on the other hand a specific TARGET? I suggest you give this a try: make clean; make TARGET=linux2628 CPU=native USE_PCRE=1 USE_OPENSSL=1 \ USE_ZLIB=1 With the custom make TARGET, you are not using epoll, falling back to the slower poll(). This shouldn't make any difference regarding the ssl affinity though. Regarding that, your configuration looks ok, and you have tested a different releases, which make me think the issue may not be in haproxy. How do you know HAProxy doesn't maintains the correct affinity? Are you tcpdumping the frontent traffic? Are you sure your backend servers have an session cache enabled and working? Regards, Lukas
RE: Does haproxy could be a forward proxy?
Hi, > Hi, this question is silly, but I use haproxy even on my laptop to > split traffic, for example, there's a ACL to let some special domains > go via remote proxy, and the default goes local proxy, I wonder is it > possible to replace local proxy with haproxy, so I could have: " > server default local:1080 " directly without creating a proxy by > another tool. option http_proxy [1] is probably what you are looking for, but be advised that it doesn't lookup any hostnames automatically, and its not something haproxy was really made for, so YMMV. Regards, Lukas [1] http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#4-option%20http_proxy
Call For Papers. Kindly impart in your University/Organization/College/Colleagues/Academia/Circle
INTERNATIONAL JOURNAL OF TRENDS IN ECONOMICS MANAGEMENT & TECHNOLOGY IJTEMT invites you to submit your research paper for publishing in Volume III, Issue I (JANUARY 2014). CALL FOR PAPERS VOLUME III, ISSUE I www.ijtemt.org INDEXED IN: Google Scholar, .docstoc, slideshare, Scribd, J-Gate, Academia.edu, Directory of Open Journals, Bielefeld Academic Search Engine, ulrichsweb.com(TM) -- The Global Source for Periodicals About IJTEMTwww.ijtemt.org International Journal of Trends in Economics Management and Technology (IJTEMT) in an International Academic Journal e-published bimonthly in India and open to the world. In this present interdisciplinary era, here at IJTEMT, a group of intellectual came together to find a common platform for three major components of any economy i.e., Economics, Management and Technology. Here we provide a forum to bridge the gap between the brushed-up professional in their respective fields and the new researcher which will results in better understanding and fruitful outcomes.The focus of this journal is to publish paper on economics management and technology. Submitted papers are reviewed by a full double â blind manner by the technical committee of the journal. The audience for the journal is professionals from related fields, academicians and new students & research scholars.All submitted articles should report original, previously unpublished research results, experimental or theoretical, and will be peer-reviewed. Articles submitted to the journal should meet these criteria and must not be under consideration for publication elsewhere. Manuscripts should follow the style of the journal and are subject to both review and editing. Why Select IJTEMT Journal www.ijtemt.org IJTEMT Provides E-Certificates to Author's if Needed.IJTEMT is Globally Approved International Journal having Strong Editorial Board.This is Online Open Journal .Author's can Download Paper from Library of Journal at any Time from Anywhere.IJTEMT is a Association of Eminent Scientist, Researchers and Experienced Members of More than 20 Countries.IJTEMT Publishes High Quality Papers which are Peer Reviewed by International/National Reviewers. Author's Query can be solved within 18 Hours. Subject Category: ECONOMICS, MANAGEMENT & TECHNOLOGY. Important Dates: Paper Submission: 5th JANUARY 2014www.ijtemt.org Review Results (Acceptance/Rejection) Notification: Within two weeks after submitting manuscript. Guidelines for submission and Review Process:www.ijtemt.org IJTEMT welcomes author submission of papers concerning any branch of the economics, management and technology and their applications in business, industry and other subjects relevant. The review process goes through following phases which can take time from ten days to two months:a. Each manuscript will be initially evaluated by the editorial board / editor, who may make use of appropriate software to examine the originality of the contents of the manuscript.b. The manuscripts passed through screening at above noted level will be forwarded to two referees for blind peer review, each of whom will make a recommendation to publish the article in its present form/edit/reject. During this period referees shall treat the contents of papers under review as privileged information.c. The reviewers' recommendations determine whether a paper will be accepted / accepted subject to change / subject to resubmission with significant changes / rejected.d. For papers which require changes, the same reviewers will be used to ensure that the quality of the revised paper is acceptable.e. All papers are refereed, and the Editor-in-Chief reserves the right to refuse any typescript, whether on invitation or otherwise, and to make suggestions and/or modifications before publication. Submission of Paper will takes place in two phases:www.ijtemt.orga. Initial Paper Submission: Prospective author (s) is/are encouraged to submit their manuscript including charts, tables, figures and appendixes in .pdf and .doc (both) format to e-mail: sub...@ijtemt.org. All submitted articles should report original, previously unpublished research results, experimental or theoretical. Articles submitted to the IJIMT should meet these criteria and must not be under consideration for publication elsewhere.b. Camera Ready Paper Submission:On the acceptance of the paper after completion of the review process the author (s) is/are has to submit camera ready full text paper in .doc and .pdf (both) format to e-mail: submitfi...@ijtemt.org along with the corresponding signed copy of copyright transfer form and scanned copy of payment slip. Publication fees www.ijtemt.org Each accepted paper will be charged, for publication and paper handling, 60 USD per paper (for a maximum of 8 pages, above which 1 USD will be charged for every additional page) which is to be paid as per the instructions mentioned in the letter of acceptance of the manuscrip
Re: http-keep-alive broken?
Hi Sander, In my configuration, I enabled "option http-keep-alive" in the default section, that way, it is applied to all next frontend and backend. Then you can disable it locally by prefixing the same option by no. And it works :) I've attached to this mail, the log session showing myself browsing exchange 2010 webmail with http-keep-alive mode. I've also tested with an outlook 2007 client (RPC over HTTP mode). Interestingly, this one does the NTLM negotiation, run the request then shut the connection... and do this all the time Each time, of course, it asks the server to negotiate a new SSL key But it works since in the log I can see all the requests coming from a single client side TCP connection :) In your case, your frontend is in tunnel mode. I don't know the impact when the frontend is in tunnel mode and the backend in http-keep-alive. Please enable keep alive directly in your default section and report us the result. Baptiste On Fri, Jan 3, 2014 at 10:39 AM, Sander Klein wrote: > Hi Baptiste, Lukas, > > @Lukas: Sorry I misread your tunnel-mode for tcp-mode. Tunnel-mode works > (almost) fine as you can read below. > > I have been investigating my problem a bit more, and then I remembered that > I also updated haproxy a week before we started using our new Windows 2012 > servers. > > The problem I'm having (also tested with ss-20140101 yesterday) happens with > http-keep-alive enabled and also when just running in tunnel mode. But, when > http-keep-alive is enabled I get the problem with ~98% of the requests and > in tunnel mode I get it with ~10% of the requests. Authentication seems to > succeed but the connection just 'hangs'. Sometimes refreshing 10 times fixes > it. > > I have downgraded to dev19 this morning and it seems that the problem went > away in tunnel mode. (http-keep-alive is of course not available) > > While I am not sure yet, it could be something broke during dev19-dev21. > This may sound a bit silly but connections to our IIS servers 'feel faster > and more responsive' when using dev19. > > I will build a small test environment to see if I can reproduce it and > capture some traffic. Right now it's just a hunch. > > My config is below. When I use http-keep-alive I just uncomment the 'option > http-keep-alive' and comment the 'no option http-server-close'. > > ### > # Global Settings > ### > global > log 127.0.0.1 local0 > > daemon > userhaproxy > group haproxy > maxconn 32768 > spread-checks 3 > stats socket/var/run/haproxy.stat mode 666 level admin > > ### > # Defaults > ### > defaults > log global > > mode http > > option abortonclose > > timeout check 2s > timeout client 10s > timeout connect 10s > timeout http-keep-alive 30s > timeout http-request30s > timeout queue 15s > timeout server 10s > timeout tarpit 120s > > ### > # Define the admin section > ### > listen admin > bind X.X.X.1:8080 > bind 2001:x:x:x::1:8080 > stats enable > stats uri /haproxy?stats > stats auth admin:somepass > stats admin if TRUE > stats refresh 5s > > ### > # Frontend for services > ### > frontend default-fe > bind X.X.X.37:80 > bind 2001:X:X:X:6:80 > bind X.X.X.37:443 ssl crt /etc/haproxy/ssl/cert.pem crt > /etc/haproxy/ssl/othercert.pem ciphers RC4:HIGH:!aNULL:!MD5 > bind 2001:X:X:X::6:443 ssl crt /etc/haproxy/ssl/cert.pem crt > /etc/haproxy/ssl/othercert.pem ciphers RC4:HIGH:!aNULL:!MD5 > > option httplog > option forwardfor > > > # Add X-Forwarded-* headers > http-request set-header X-Forwarded-Proto https if { ssl_fc } > http-request set-header X-Forwarded-Ssl on if { ssl_fc } > http-request set-header X-Forwarded-Proto http if ! { ssl_fc } > http-request set-header X-Forwarded-Ssl off if ! { ssl_fc } > > # Define hosts which need to redirect to HTTPS > acl need_ssl hdr(Host) -i blah > acl need_ssl hdr(Host) -i host1 > acl need_ssl hdr(host) -i host2 > acl need_ssl hdr(host) -i host3 > > > redirect scheme https if need_ssl ! { ssl_fc } > > # Define backends and redirect correct hostnames > use_backend mgmt if { hdr(Host) -i blah } > use_backend mgmt if { hdr(Host) -i somehost } > use_backend mgmt if { hdr(Host) -i anotherhost } > > use_backend app1 if { hdr(Host) -i host1 } > > use_backend app2 if { hdr(Host) -i host2 } > use_backend app3 if { hdr(Host) -i host3 } > > http-request redirect location http://some.site if { hdr(Host) -i > something } > > ### > # backend_mgmt > ### > backend mgmt > fullconn 20 > > option http-server-close >
Re: http-keep-alive broken?
Hi Baptiste, Lukas, @Lukas: Sorry I misread your tunnel-mode for tcp-mode. Tunnel-mode works (almost) fine as you can read below. I have been investigating my problem a bit more, and then I remembered that I also updated haproxy a week before we started using our new Windows 2012 servers. The problem I'm having (also tested with ss-20140101 yesterday) happens with http-keep-alive enabled and also when just running in tunnel mode. But, when http-keep-alive is enabled I get the problem with ~98% of the requests and in tunnel mode I get it with ~10% of the requests. Authentication seems to succeed but the connection just 'hangs'. Sometimes refreshing 10 times fixes it. I have downgraded to dev19 this morning and it seems that the problem went away in tunnel mode. (http-keep-alive is of course not available) While I am not sure yet, it could be something broke during dev19-dev21. This may sound a bit silly but connections to our IIS servers 'feel faster and more responsive' when using dev19. I will build a small test environment to see if I can reproduce it and capture some traffic. Right now it's just a hunch. My config is below. When I use http-keep-alive I just uncomment the 'option http-keep-alive' and comment the 'no option http-server-close'. ### # Global Settings ### global log 127.0.0.1 local0 daemon userhaproxy group haproxy maxconn 32768 spread-checks 3 stats socket/var/run/haproxy.stat mode 666 level admin ### # Defaults ### defaults log global mode http option abortonclose timeout check 2s timeout client 10s timeout connect 10s timeout http-keep-alive 30s timeout http-request30s timeout queue 15s timeout server 10s timeout tarpit 120s ### # Define the admin section ### listen admin bind X.X.X.1:8080 bind 2001:x:x:x::1:8080 stats enable stats uri /haproxy?stats stats auth admin:somepass stats admin if TRUE stats refresh 5s ### # Frontend for services ### frontend default-fe bind X.X.X.37:80 bind 2001:X:X:X:6:80 bind X.X.X.37:443 ssl crt /etc/haproxy/ssl/cert.pem crt /etc/haproxy/ssl/othercert.pem ciphers RC4:HIGH:!aNULL:!MD5 bind 2001:X:X:X::6:443 ssl crt /etc/haproxy/ssl/cert.pem crt /etc/haproxy/ssl/othercert.pem ciphers RC4:HIGH:!aNULL:!MD5 option httplog option forwardfor # Add X-Forwarded-* headers http-request set-header X-Forwarded-Proto https if { ssl_fc } http-request set-header X-Forwarded-Ssl on if { ssl_fc } http-request set-header X-Forwarded-Proto http if ! { ssl_fc } http-request set-header X-Forwarded-Ssl off if ! { ssl_fc } # Define hosts which need to redirect to HTTPS acl need_ssl hdr(Host) -i blah acl need_ssl hdr(Host) -i host1 acl need_ssl hdr(host) -i host2 acl need_ssl hdr(host) -i host3 redirect scheme https if need_ssl ! { ssl_fc } # Define backends and redirect correct hostnames use_backend mgmt if { hdr(Host) -i blah } use_backend mgmt if { hdr(Host) -i somehost } use_backend mgmt if { hdr(Host) -i anotherhost } use_backend app1 if { hdr(Host) -i host1 } use_backend app2 if { hdr(Host) -i host2 } use_backend app3 if { hdr(Host) -i host3 } http-request redirect location http://some.site if { hdr(Host) -i something } ### # backend_mgmt ### backend mgmt fullconn 20 option http-server-close option httpchk GET / HTTP/1.0 server mgmt-01 192.168.1.7:80 cookie mgmt-01 check inter 2000 ### # backend app1 ### backend app1 fullconn 5 no option http-server-close # ONLY USE IF NTLM IS NEEDED! # option http-keep-alive option httpchk GET /url HTTP/1.0 server app1 192.168.1.30:80 cookie app1 check inter 2000 ### # backend app2 ### backend app2 fullconn 512 no option http-server-close # ONLY USE IF NTLM IS NEEDED! # option http-keep-alive option httpchk GET / HTTP/1.0 server app2 192.168.1.46:443 cookie app2 ssl check inter 2000 ### # backend app3 ### backend app3 fullconn 512 no option http-server-close # ONLY USE IF NTLM IS NEEDED! # option http-keep-alive option httpchk GET / HTTP/1.0 server app3 192.168.1.44:443 cookie app3 ssl check inter 2000