Re: Recommended SSL ciphers and settings
rspadd Strict-Transport-Security:\ max-age=31536000;\ includeSubDomains if ssl-proxy Do I need to add it to the frontend or backend? Will it break raw TLS (not HTTPS)? Thanks On Tue, Sep 9, 2014 at 1:25 PM, Thomas Heil h...@terminal-consulting.de wrote: Hi, On 09.09.2014 11:43, pablo platt wrote: I've tried both options and I'm still not getting A+. Unfortunately, I can't ask the user what the error is. If I'll run into this again, I'll try to get this info. To reach A+ you need rspadd Strict-Transport-Security:\ max-age=31536000;\ includeSubDomains if ssl-proxy ssl-proxy means here the connection is ssl. and a cipher list like -- EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384: EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4 -- Together it should work. As you can see we have no longer RC4 ciphers, cheers thomas Thanks On Mon, Sep 8, 2014 at 9:46 AM, Jarno Huuskonen jarno.huusko...@uef.fi wrote: Hi, On Sun, Sep 07, pablo platt wrote: Hi, I'm using haproxy to terminate SSL and it works for most of my users. I have alphassl wildcard certificate. I'm using SSL to improve WebSockets and RTMP connections of port 443. I don't have sensitive data or e-commerce. I have one user that see a warning in Chrome and can't use my website. Do you know what warning chrome gives to that user ? Is it possible that this the warning is because an antivirus is not happy with the default ciphers or other ssl settings? When running a test https://sslcheck.globalsign.com/en_US I'm getting: Sessions may be vulnerable to BEAST attack Server has not enabled HTTP Strict-Transport-Security Server has SSL v3 enabled Server is using RC4-based ciphersuites which have known vulnerabilities Server configuration does not meet FIPS guidelines Server does not have OCSP stapling configured Server has not yet upgraded to a Extended Validation certificate Server does not have SPDY enabled I found one suggestion: bind 10.0.0.9:443 name https ssl crt /path/to/domain.pem ciphers RC4:HIGH:!aNULL:!MD5 http://blog.haproxy.com/2013/01/21/mitigating-the-ssl-beast-attack-using-the-aloha-load-balancer-haproxy/ And another: bind 0.0.0.0:443 ssl crt /etc/cert.pem nosslv3 prefer-server-ciphers ciphers RC4-SHA:AES128-SHA:AES256-SHA Both gives me other warnings. What other warnings ? (Does haproxy give you warnings/errors or client browsers) ? Perhaps you could try ciphersuite from: https://wiki.mozilla.org/Security/Server_Side_TLS for example in global: ssl-default-bind-ciphers ... or on bind: bind 0.0.0.0:443 ssl crt /path/to/crt ciphers ... To enable ocsp stapling see haproxy config: http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#5.1-crt http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#9.2-set%20ssl%20ocsp-response -Jarno -- Jarno Huuskonen -- Thomas Heil - Email: h...@terminal-consulting.de Tel: 0176 / 44555622 --
Recommended SSL ciphers and settings
Hi, I'm using haproxy to terminate SSL and it works for most of my users. I have alphassl wildcard certificate. I'm using SSL to improve WebSockets and RTMP connections of port 443. I don't have sensitive data or e-commerce. I have one user that see a warning in Chrome and can't use my website. Is it possible that this the warning is because an antivirus is not happy with the default ciphers or other ssl settings? When running a test https://sslcheck.globalsign.com/en_US I'm getting: Sessions may be vulnerable to BEAST attack Server has not enabled HTTP Strict-Transport-Security Server has SSL v3 enabled Server is using RC4-based ciphersuites which have known vulnerabilities Server configuration does not meet FIPS guidelines Server does not have OCSP stapling configured Server has not yet upgraded to a Extended Validation certificate Server does not have SPDY enabled I found one suggestion: bind 10.0.0.9:443 name https ssl crt /path/to/domain.pem ciphers RC4:HIGH:!aNULL:!MD5 http://blog.haproxy.com/2013/01/21/mitigating-the-ssl-beast-attack-using-the-aloha-load-balancer-haproxy/ And another: bind 0.0.0.0:443 ssl crt /etc/cert.pem nosslv3 prefer-server-ciphers ciphers RC4-SHA:AES128-SHA:AES256-SHA Both gives me other warnings. What are the commended ciphers and settings to use when terminating SSL with haproxy? Could there be another reason Chrome complains about SSL? Thanks
Re: debian repository http://haproxy.debian.net/
Something like this for haproxy will bring confident and prevent confusion and questions. http://nginx.org/en/linux_packages.html On Fri, May 23, 2014 at 8:08 PM, Willy Tarreau w...@1wt.eu wrote: On Fri, May 23, 2014 at 05:10:49PM +0200, Ghislain wrote: Le 23/05/2014 15:23, Baptiste a écrit : It is not provided by us (HAProxy.com) if this is what you mean. Baptiste yes that's what i meant. Thanks for both answer and thanks for the product, and the packages ! In any case from my high throne in the sky looking under at other petty humans i will consider worthy of my trust the debian team, amen ;p BTW, I tend to consider part of the haproxy team all people who are deeply involved in the project. The long-time distro maintainers certainly qualify as part of the team, so you needn't worry. Willy
Re: Ubuntu 14.04 package
Thank you, this is extremely helpful. On Thu, Apr 17, 2014 at 9:59 AM, Vincent Bernat ber...@luffy.cx wrote: ❦ 12 avril 2014 12:49 CEST, pablo platt pablo.pl...@gmail.com : Is there a 1.5~dev22 deb package for Ubuntu 14.04 (trusty)? I've found the following ppa but it only has package for Ubuntu 13.10 and below. https://launchpad.net/~vbernat/+archive/haproxy-1.5 I will update the repository this week-end to get a package for 14.04. -- panic(IRQ, you lose...); 2.2.16 /usr/src/linux/arch/mips/sgi/kernel/indy_int.c
Re: Ubuntu 14.04 package
I've just installed it with the new ubuntu trusty release. Great timing. Thank you for providing this ppa. On Thu, Apr 17, 2014 at 12:05 PM, Vincent Bernat ber...@luffy.cx wrote: ❦ 17 avril 2014 08:59 CEST, Vincent Bernat ber...@luffy.cx : Is there a 1.5~dev22 deb package for Ubuntu 14.04 (trusty)? I've found the following ppa but it only has package for Ubuntu 13.10 and below. https://launchpad.net/~vbernat/+archive/haproxy-1.5 I will update the repository this week-end to get a package for 14.04. I have just uploaded a version for Trusty. Instructions here: http://haproxy.debian.net/ -- panic(huh?\n); 2.2.16 /usr/src/linux/arch/i386/kernel/smp.c
Re: Recommended strategy for running 1.5 in production
An official Ubuntu dev repo will also make testing easier. It's much easier to use a apt-get than building from source and figuring out command line options. On Wed, Apr 16, 2014 at 7:05 PM, Philipp e1c1bac6253dc54a1e89ddc046585...@posteo.net wrote: Am 16.04.2014 17:40 schrieb Willy Tarreau: I think you summarized very well how to carefully use a development version in prod. That requires a bit of care, but with that you can get both nice features and quick fixes. Indeed :) After 1.5 is released, I'd like to switch to a faster and more regular release cycle with less constraints on the features. And with above said: I, personally, give a rats a** if a version is called alpha, rc123, -dev or whatever fancy version string it has. Test the thing and find out the hairy bits after it hits production :-) I was sooo often burned by oh, finally release and then it was worse then the RC before the actual release whatsoever. My kudos to Willy and the other developers of haproxy, awesome work overall AND in the nitbits :-).
Re: Recommended strategy for running 1.5 in production
The Ubuntu PPA is great but it is not 'official' and I couldn't find Ubuntu 14.04 package. https://launchpad.net/~vbernat/+archive/haproxy-1.5https://launchpad.net/%7Evbernat/+archive/haproxy-1.5 Ubuntu 14.04 LTS will be out tomorrow which means that haproxy-1.5 will be included only in the next LTS release 2 years from now. That's why an official Ubuntu repo will be very useful. Nginx and MongoDB for example has one. Is there a script that we can use to build a deb package? On Wed, Apr 16, 2014 at 9:55 PM, Willy Tarreau w...@1wt.eu wrote: Hi Apollon, On Wed, Apr 16, 2014 at 09:22:56PM +0300, Apollon Oikonomopoulos wrote: (Cc'ing the Debian maintainers as well) Hi all, On 19:28 Wed 16 Apr , Willy Tarreau wrote: On Wed, Apr 16, 2014 at 07:14:31PM +0300, pablo platt wrote: An official Ubuntu dev repo will also make testing easier. It's much easier to use a apt-get than building from source and figuring out command line options. Actually Vincent Bernat maintains a PPA with rebuilds of our Debian packages from experimental, which should be handy for Ubuntu users: https://launchpad.net/~vbernat/+archive/haproxy-1.5 I think we're getting close to a release so we should not harrass distro maintainers with that *now* (but we could have done years ago). That reminds me that I tend not to always realize how much time slips between versions, and to forget that sometimes a previous version has some bugs. What I'd expect from our users is to sometimes complain loudly and insist for having a new dev release when the latest snapshot has become more reliable than the last dev release if that makes their lifes easier. A new version doesn't cost much (1 hour to read the changelog, write a human-friendly summary in an announce e-mail and update the site). With my Debian hat on, I'd like to complain a bit about 1.5. Of course we appreciate your dedication to making HAProxy rock-solid and feature-complete and at this point as a user 1.5 has been pretty stable for me (and the new features are definitely worth the wait). However, as Debian maintainers we probably will not replace 1.4 with 1.5 in our main track (unstable - testing - wheezy-backports) until 1.5-final is out; we would like to make sure that we will end up with a proper 1.5 release in Debian Jessie (and not with a development snapshot at any rate) that both, upstream and ourselves will be willing to support. Unfortunately, this means that 1.5 currently gets less user exposure (at least via Debian and Ubuntu), potentially slowing down the stabilization process. So please, leave some features aside for 1.6 ;-) I know and the goal clearly is not to add new features to 1.5, but to fix what still remains to be fixed before the release otherwise we'd have to risk breaking some supposed stable setups later when backporting fixes : - fix the HTTP body parser to get rid of the mess it is when mixing redispatch with check_post, not to mention compression. - fix the compression to re-enable compression of chunked-encoded responses - adapt the check agent to the final API we agreed on the list a few weeks ago - fix the bind-process lameness. I'm still working on point #1 and making progress (I was even writing some architecture doc on it to engrave the changes so that we avoid breaking that soon again). #2 should follow shortly after that. #3 is apparently easy (I had a beginning of patch 2 months ago to start on it) but we noticed that the check agent touches many intimate parts of the checks and I expect a few surprizes again. However, I don't care much about minor bugs for the final release provided that the architecture is ready to accept fixes without putting users at risk. For #4, I think we can keep the users in a safe working area to prepare them for upgrades by simply emitting a few warnings in the configs leading to a corner case. I really think we're on the right track, we must just not stop efforts. And the fact that we get lots of bug reports is a good sign as well! Cheers, Willy
Re: Recommended strategy for running 1.5 in production
So I only need to setup a VM, download a file from a personal PPA, add the source code and learn how to build a deb package... And every user need to do the same... Easy :) On Wed, Apr 16, 2014 at 11:12 PM, Ramin K ramin-l...@badapple.net wrote: It's easy to build your own packages with the files from the PPA which is what we do. BTW, thanks Vincent for doing the groundwork. Simplest method might be: - Decide which archs you need to target. Follow a how-to for setting up a environment to build deb packages. I recommend dedicating a VM for each arch though we only build for x86_64. - Use the debian.tar.gz file from the PPA to populate the ./debian/ dir - make a orig.tar.gz from dev22 or preferred revision - probably take you 2-3 tries to get everything in the right place - make the deb packages - copy deb packages to your internal repo. Ramin On 4/16/2014 12:07 PM, pablo platt wrote: The Ubuntu PPA is great but it is not 'official' and I couldn't find Ubuntu 14.04 package. https://launchpad.net/~vbernat/+archive/haproxy-1.5 https://launchpad.net/%7Evbernat/+archive/haproxy-1.5 Ubuntu 14.04 LTS will be out tomorrow which means that haproxy-1.5 will be included only in the next LTS release 2 years from now. That's why an official Ubuntu repo will be very useful. Nginx and MongoDB for example has one. Is there a script that we can use to build a deb package? On Wed, Apr 16, 2014 at 9:55 PM, Willy Tarreau w...@1wt.eu mailto:w...@1wt.eu wrote: Hi Apollon, On Wed, Apr 16, 2014 at 09:22:56PM +0300, Apollon Oikonomopoulos wrote: (Cc'ing the Debian maintainers as well) Hi all, On 19:28 Wed 16 Apr , Willy Tarreau wrote: On Wed, Apr 16, 2014 at 07:14:31PM +0300, pablo platt wrote: An official Ubuntu dev repo will also make testing easier. It's much easier to use a apt-get than building from source and figuring out command line options. Actually Vincent Bernat maintains a PPA with rebuilds of our Debian packages from experimental, which should be handy for Ubuntu users: https://launchpad.net/~vbernat/+archive/haproxy-1.5 I think we're getting close to a release so we should not harrass distro maintainers with that *now* (but we could have done years ago). That reminds me that I tend not to always realize how much time slips between versions, and to forget that sometimes a previous version has some bugs. What I'd expect from our users is to sometimes complain loudly and insist for having a new dev release when the latest snapshot has become more reliable than the last dev release if that makes their lifes easier. A new version doesn't cost much (1 hour to read the changelog, write a human-friendly summary in an announce e-mail and update the site). With my Debian hat on, I'd like to complain a bit about 1.5. Of course we appreciate your dedication to making HAProxy rock-solid and feature-complete and at this point as a user 1.5 has been pretty stable for me (and the new features are definitely worth the wait). However, as Debian maintainers we probably will not replace 1.4 with 1.5 in our main track (unstable - testing - wheezy-backports) until 1.5-final is out; we would like to make sure that we will end up with a proper 1.5 release in Debian Jessie (and not with a development snapshot at any rate) that both, upstream and ourselves will be willing to support. Unfortunately, this means that 1.5 currently gets less user exposure (at least via Debian and Ubuntu), potentially slowing down the stabilization process. So please, leave some features aside for 1.6 ;-) I know and the goal clearly is not to add new features to 1.5, but to fix what still remains to be fixed before the release otherwise we'd have to risk breaking some supposed stable setups later when backporting fixes : - fix the HTTP body parser to get rid of the mess it is when mixing redispatch with check_post, not to mention compression. - fix the compression to re-enable compression of chunked-encoded responses - adapt the check agent to the final API we agreed on the list a few weeks ago - fix the bind-process lameness. I'm still working on point #1 and making progress (I was even writing some architecture doc on it to engrave the changes so that we avoid breaking that soon again). #2 should follow shortly after that. #3 is apparently easy (I had a beginning of patch 2 months ago to start on it) but we noticed that the check agent touches many intimate parts of the checks and I
Ubuntu 14.04 package
Hi, Is there a 1.5~dev22 deb package for Ubuntu 14.04 (trusty)? I've found the following ppa but it only has package for Ubuntu 13.10 and below. https://launchpad.net/~vbernat/+archive/haproxy-1.5 Is there a script to build my own deb package for the dev version? It will be great if we could have an official Ubuntu repo for the dev version we can trust. It will make it easier to test the dev version and give feedback. Thanks
DTLS termination
Hi, Can version 1.5 terminate DTLS connections like it does for SSL? Thanks
Re: DTLS termination
Any other proxy that can terminate DTLS? Thanks On Wed, Nov 27, 2013 at 5:40 PM, Lukas Tribus luky...@hotmail.com wrote: Hi! Can version 1.5 terminate DTLS connections like it does for SSL? No; haproxy only works with TCP (HTTP or raw TCP). DTLS is for datagram protocols like UDP, which haproxy doesn't support anyway (even without encryption). Regards, Lukas
Re: Websockets and RTMP
The following config doesn't direct secure websocket connections to the backend. What am I doing wrong? global log 127.0.0.1 local0 log 127.0.0.1 local1 notice #log loghostlocal0 info maxconn 4096 #chroot /usr/share/haproxy user haproxy group haproxy daemon #debug #quiet defaults log global modehttp option httplog option dontlognull retries 3 option redispatch maxconn 2000 contimeout 5000 clitimeout 5 srvtimeout 5 frontend port443 bind :443 mode tcp clitimeout 65000 tcp-request inspect-delay 5s acl traffic_is_ssl req_ssl_ver gt 0 acl enough_non_ssl_bytes req_len ge 22 tcp-request content accept if traffic_is_ssl # accept SSL tcp-request content accept if enough_non_ssl_bytes # accept non-SSL use_backend ssl_backend if traffic_is_ssl default_backend rtmp_backend backend ssl_backend srvtimeout 65000 server nginx_server 127.0.0.1:4443 backend rtmp_backend srvtimeout 65000 server rtmp_server 127.0.0.1:1935 I also tried much simpler config but I still can't connect: frontend port443 bind :443 mode tcp default_backend ssl_backend backend ssl_backend srvtimeout 65000 server nginx_server 127.0.0.1:4443 On Tue, May 14, 2013 at 2:16 PM, pablo platt pablo.pl...@gmail.com wrote: Is my config reasonable? On Sun, May 12, 2013 at 6:14 PM, Jonathan Matthews cont...@jpluscplusm.com wrote: On 12 May 2013 10:03, pablo platt pablo.pl...@gmail.com wrote: Can you please explain how to use ssl_fc? I couldn't find it in the configuration docs. Please see below the global and defaults sections which I get when installing the haproxy-1.4.18 deb package on ubuntu 12.04 ssl_fc is only in HAProxy 1.5. Jonathan -- Jonathan Matthews // Oxford, London, UK http://www.jpluscplusm.com/contact.html
Re: Websockets and RTMP
Is my config reasonable? On Sun, May 12, 2013 at 6:14 PM, Jonathan Matthews cont...@jpluscplusm.comwrote: On 12 May 2013 10:03, pablo platt pablo.pl...@gmail.com wrote: Can you please explain how to use ssl_fc? I couldn't find it in the configuration docs. Please see below the global and defaults sections which I get when installing the haproxy-1.4.18 deb package on ubuntu 12.04 ssl_fc is only in HAProxy 1.5. Jonathan -- Jonathan Matthews // Oxford, London, UK http://www.jpluscplusm.com/contact.html
Re: Websockets and RTMP
Can you please explain how to use ssl_fc? I couldn't find it in the configuration docs. Please see below the global and defaults sections which I get when installing the haproxy-1.4.18 deb package on ubuntu 12.04 The frontend and backend parts are what I thought of using after reading the answer here http://www.mentby.com/Group/haproxy/route-http-connections-to-tcp-backend-instead-of-dropping-in-http-mode.html Do I need to add or remove any of the settings? Thanks global log 127.0.0.1local0 log 127.0.0.1local1 notice #log loghostlocal0 info maxconn 4096 #chroot /usr/share/haproxy user haproxy group haproxy daemon #debug #quiet defaults logglobal modehttp optionhttplog optiondontlognull retries3 option redispatch maxconn2000 contimeout5000 clitimeout5 srvtimeout5 frontend port443 bind :443 mode tcp tcp-request inspect-delay 5s acl traffic_is_ssl req_ssl_ver -gt 0 tcp-request content accept use_backend media_backend if traffic_is_ssl default_backend websocket_backend backend media_backend server media_server 127.0.0.1:1935 backend websocket_backend server websocket-server 127.0.0.1:4443 On Sat, May 11, 2013 at 10:41 PM, Baptiste bed...@gmail.com wrote: Hi Pablo, My answers inline. On Sat, May 11, 2013 at 6:20 PM, pablo platt pablo.pl...@gmail.com wrote: Hi, I need to proxy secure websockets and RTMP (normal tcp) on the same port. In the future I'll need normal HTTP requests and static files. haproxy will pass ssl requests to backend1 and RTMP requests to backend2. Processes will be open for a long time (minutes - hours). The backends are on the same machine and will be responsible for timeouts and pings. Do I need to change anythinging in the default configuration like contimeout, clitimeout and srvtimeout? I'm using the ubuntu 12.04 package. Please paste your configuration. We don't know the default configuration from each packager and OS ;) Is this the correct way to check for ssl requests? acl traffic_is_ssl req_ssl_ver -gt 0 I would better use ssl_fc. Using content inspection (tcp-request inspect) rules, you can do the content switching based on ssl_fc and so split SSL and RTMP traffic to 2 different farms. (I guess this is the purpose you're trying to achieve). When nginx will get ssl requests from haproxy it'll see haproxy's IP. Can I terminate ssl requests in nginx even when the client IP was changed? IP change has no impact on SSL. Thanks Baptiste
Websockets and RTMP
Hi, I need to proxy secure websockets and RTMP (normal tcp) on the same port. In the future I'll need normal HTTP requests and static files. haproxy will pass ssl requests to backend1 and RTMP requests to backend2. Processes will be open for a long time (minutes - hours). The backends are on the same machine and will be responsible for timeouts and pings. Do I need to change anythinging in the default configuration like contimeout, clitimeout and srvtimeout? I'm using the ubuntu 12.04 package. Is this the correct way to check for ssl requests? acl traffic_is_ssl req_ssl_ver -gt 0 When nginx will get ssl requests from haproxy it'll see haproxy's IP. Can I terminate ssl requests in nginx even when the client IP was changed? Thanks
