Re: [ANNOUNCE] haproxy-1.8.13
Willy, Am 31.07.2018 um 20:32 schrieb Willy Tarreau: > That's where I disagree, it's exactly the same argument causing TLS to > appear on every web site even when not necessary, making people believe > they are safe while they are not. Right now you don't have this PGP > signature so you are careful about what you retrieve. And that's the > reason why you're talking about it by the way, because verifying all > this is painful on your side. But if I start to claim "look, no need > to double-check anymore, trust me, it's safe", you won't run this > extra safety check once in a while. But the process involved in placing > this signature may not be safer than the one involved in the checksum. > > With this said, I'll take a look at Bertrand's proposal, which I think > does satisfy my needs. To nitpick this still would require you to trust the binaries (e.g. tar) on the haproxy.org machine :-) Anyway: I am disgressing here and will patiently await whether or not there will be PGP signatures in the future. Best regards Tim Düsterhus
Re: [ANNOUNCE] haproxy-1.8.13
On Tue, Jul 31, 2018 at 07:42:41PM +0200, Tim Düsterhus wrote: > Am 30.07.2018 um 20:55 schrieb Willy Tarreau: > > I know and I've already thought about it. But I personally refuse to store > > my PGP key on any exposed machine. Right now in order to tag, I have to > > SSH into an isolated machine, run "git pull --tags", create-release, and > > "git push --tags". Then I upload the release. > > In addition to what Vincent and Bertrand suggest I'd like to note that a > dedicated "haproxy Release Signing Key", even if stored on an exposed > machine, would be strictly better than just checksums, which could be > modified by anyone with access to the haproxy.org server. That's where I disagree, it's exactly the same argument causing TLS to appear on every web site even when not necessary, making people believe they are safe while they are not. Right now you don't have this PGP signature so you are careful about what you retrieve. And that's the reason why you're talking about it by the way, because verifying all this is painful on your side. But if I start to claim "look, no need to double-check anymore, trust me, it's safe", you won't run this extra safety check once in a while. But the process involved in placing this signature may not be safer than the one involved in the checksum. With this said, I'll take a look at Bertrand's proposal, which I think does satisfy my needs. > Also I know nothing about the release process, but: Is the machine > signing the tags not used to upload the release Tarballs to haproxy.org? It depends who does it. Speaking for myself, since my PGP key is not on the machine, I release using create-release (changelog+commit+signed tag) on the machine where I have the PGP key, then I push to the public repo, then I connect to the haproxy.org machine to publish the release from the latest tag using the publish-release utility you recently patched, and perform a few extra actions there to automatically update the home page and the known bugs page. Then I run announce-release from any machine, which prepares a horrible automated text that will serve as a basis for the announce. > I think it's strange that the parts of the release process are > distributed onto several machines (one to create the tag, one to create > the Tarball). No it's not uncommon at all, especially with git since signed tags can be done anywhere, especially at places where you don't want to upload large tarballs when you in fact only need to upload a tag. Imagine if I had had to upload full linux kernels when doing stable releases, it would have taken many hours just to upload the tarballs! Cheers, Willy
Re: [ANNOUNCE] haproxy-1.8.13
Hi Bertrand, On Tue, Jul 31, 2018 at 06:26:11PM +0100, Bertrand Jacquin wrote: > I know old farts don't change, but for the two cents, newer version of > OpenSSH (>= 6.7) and GnuPG (>=2.1.1) allow you to forward GnuPG agent over > SSH with reduce capacity to reduce the attack surface you are mentioning. > More details are available on https://wiki.gnupg.org/AgentForwarding Thanks for the info, I can possibly have a look at this. It could be a reasonable option indeed, which limits the exposure of the agent in time. Cheers, Willy
Re: [ANNOUNCE] haproxy-1.8.13
Willy, Am 30.07.2018 um 20:55 schrieb Willy Tarreau: > I know and I've already thought about it. But I personally refuse to store > my PGP key on any exposed machine. Right now in order to tag, I have to > SSH into an isolated machine, run "git pull --tags", create-release, and > "git push --tags". Then I upload the release. In addition to what Vincent and Bertrand suggest I'd like to note that a dedicated "haproxy Release Signing Key", even if stored on an exposed machine, would be strictly better than just checksums, which could be modified by anyone with access to the haproxy.org server. This signing key could be signed by your personal PGP key and easily be revoked in case it ever gets compromised. Also I know nothing about the release process, but: Is the machine signing the tags not used to upload the release Tarballs to haproxy.org? I think it's strange that the parts of the release process are distributed onto several machines (one to create the tag, one to create the Tarball). Best regards Tim Düsterhus
Re: [ANNOUNCE] haproxy-1.8.13
On 31/07/2018 18:26, Bertrand Jacquin wrote: Hi Willy, On 30/07/2018 19:55, Willy Tarreau wrote: On Mon, Jul 30, 2018 at 07:41:33PM +0200, Tim Düsterhus wrote: Willy, Am 30.07.2018 um 18:05 schrieb Willy Tarreau: > A small update happened to the download directory, the sha256 of the > tar.gz files are now present in addition to the (quite old) md5 ones. > We may start to think about phasing md5 signatures out, for example > after 1.9 is released. I'd even like to see PGP signatures, like you already do for the git tags (but not the Tarballs). But this is a greater change than just updating the checksums :-) I know and I've already thought about it. But I personally refuse to store my PGP key on any exposed machine. Right now in order to tag, I have to SSH into an isolated machine, run "git pull --tags", create-release, and "git push --tags". Then I upload the release. What I don't like with PGP on an exposed machine is that it reduces the size of your 4096-bit key to the size of your passphrase (which most often contains much less than the ~700 characters it would need to be as large), and also increases your ability to get fooled into entering it. Some would call me paranoid, but I don't think I am, I'm just trying to keep a balanced level of security, knowing that the global one is not better than the weakest point. If I wanted to sign the images, it would require to find a different release method and would significantly complicate the procedure. I know old farts don't change, but for the two cents, newer version of OpenSSH (>= 6.7) and GnuPG (>=2.1.1) allow you to forward GnuPG agent over SSH with reduce capacity to reduce the attack surface you are mentioning. More details are available on https://wiki.gnupg.org/AgentForwarding Also, old farts press the send button too quickly. The benefit of forwarding the gpg agent is that you don't need to copy your private key to any remote machine, the gpg agent running on the machine forwarding it will perform all the crypto operations. With a ssh config alias, you could enable agent forwarding only when you want to create a release. Mixed with a smartcard, no computer at all would be able to access private material. Cheers -- Bertrand
Re: [ANNOUNCE] haproxy-1.8.13
Hi Willy, On 30/07/2018 19:55, Willy Tarreau wrote: On Mon, Jul 30, 2018 at 07:41:33PM +0200, Tim Düsterhus wrote: Willy, Am 30.07.2018 um 18:05 schrieb Willy Tarreau: > A small update happened to the download directory, the sha256 of the > tar.gz files are now present in addition to the (quite old) md5 ones. > We may start to think about phasing md5 signatures out, for example > after 1.9 is released. I'd even like to see PGP signatures, like you already do for the git tags (but not the Tarballs). But this is a greater change than just updating the checksums :-) I know and I've already thought about it. But I personally refuse to store my PGP key on any exposed machine. Right now in order to tag, I have to SSH into an isolated machine, run "git pull --tags", create-release, and "git push --tags". Then I upload the release. What I don't like with PGP on an exposed machine is that it reduces the size of your 4096-bit key to the size of your passphrase (which most often contains much less than the ~700 characters it would need to be as large), and also increases your ability to get fooled into entering it. Some would call me paranoid, but I don't think I am, I'm just trying to keep a balanced level of security, knowing that the global one is not better than the weakest point. If I wanted to sign the images, it would require to find a different release method and would significantly complicate the procedure. I know old farts don't change, but for the two cents, newer version of OpenSSH (>= 6.7) and GnuPG (>=2.1.1) allow you to forward GnuPG agent over SSH with reduce capacity to reduce the attack surface you are mentioning. More details are available on https://wiki.gnupg.org/AgentForwarding Cheers -- Bertrand
Re: SNI matching issue when hostname ends with trailing dot
Hello Warren, On Tue, 22 May 2018 at 15:48, Warren Rohner wrote: > The other day I inadvertently appended a trailing dot to the hostname > for one of our sites (e.g. https://www.example.com.), and when I did > this HAProxy returned the default cert to the browser rather than the > expected cert for that particular site. I'm not certain, but could > this be a possible bug in the HAProxy code that matches servername > provided by browser's TLS SNI extension against all loaded certificates? The browsers are supposed to strip the trailing dots from SNI, as per: https://tools.ietf.org/html/rfc6066#section-3 > The hostname is represented as a byte string using ASCII encoding > without a trailing dot. I know they currently don't, but that doesn't mean there is a bug in haproxy. curl does it correctly: https://github.com/curl/curl/commit/5de8d84098db1bd24e7fffefbe14e81f2a05995a Mozilla has a bug report about this here: https://bugzilla.mozilla.org/show_bug.cgi?id=1008120 There is also a discussion about the disparity between SNI and the http host header on the HTTP WG: https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0430.html However, none of this indicates that a *server* should drop the trailing dot from the incoming SNI and I agree. Looks like browser vendors are not very keen on fixing those edge cases, as can been seen from the bug reports, however I do not agree that we should be dropping the trailing dot in haproxy. If you need a workaround in haproxy, I suggest you configure this alternative SNI->cert mapping using crt-list: https://cbonte.github.io/haproxy-dconv/1.8/configuration.html#5.1-crt-list cheers, lukas
Re: Possibility to modify PROXY protocol header
I think if you use the `http-request set-src` directive it'll populate the PROXY headers in addition to the internal logging On Fri, Jul 27, 2018 at 7:05 AM bjun...@gmail.com wrote: > Hi, > > is there any possibilty to modify the client ip in the PROXY Protocol > header before it is send to a backend server? > > My use case is a local integration/functional testing suite (multiple > local docker containers for testing the whole stack - haproxy, cache layer, > webserver, etc.). > > I would like to test functionalities which are dependent of/need specific > IP ranges or IP addresses. > > > Best Regards / Mit freundlichen Grüßen > > Bjoern > -- James Brown Engineer
IPBurger VPN Services Linkback Programme
Hi! I'm Donald, the co-owner of IPBurger VPN services ( https://secure.ipburger.com/); We're a small but growing VPN company (Dedicated and Shared IP space) and we would be very grateful if you could include our company among similar services on your website. URL Example: http://www.haproxy.org/#tact As you are linking back to Private Internet Access in external links. We located your website after doing research on our competitor. *We offer a 30% recurring affiliate commission:* Step 1: Register for a client account here: (https://secure.ipburger.com/register.php) Step 2: Activate your Affiliate account: (https://secure.ipburger.com/a ffiliates.php) We can provide any resources you need whether that's page content, banners, test accounts or anything else you need if we can be placed on your website. You can reach me personally at don...@ipburger.com Feel free to reach out to me if you need anything. Thank you for your time, Donald
IPBurger VPN Services | Sponsorship & Affiliate Proposal
Hi! I'm Donald, the co-owner of IPBurger VPN services ( https://secure.ipburger.com/); We're a small but growing VPN company (Dedicated and Shared IP space) and we would be very grateful if you could include our company among similar services on your website. URL Example: http://www.haproxy.org/#tact Like you have linked to *Private Internet Access* As you are linking back to Private Internet Access. We located your website after doing research on our competitor. *We offer a 30% recurring affiliate commission:* Step 1: Register for a client account here: (https://secure.ipburger.com/register.php) Step 2: Activate your Affiliate account: (https://secure.ipburger.com/a ffiliates.php) We can provide any resources you need whether that's page content, banners, test accounts or anything else you need if we can be placed on your website. You can reach me personally at don...@ipburger.com Feel free to reach out to me if you need anything. Thank you for your time, Donald
