Merge "BUG/MEDIUM: server: Also copy "check-sni" for server templates."

Bug #1846714 reported by Malte Schmidt
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
haproxy (Ubuntu)
Fix Released
Undecided
Unassigned
Bionic
Incomplete
Undecided
Unassigned
Disco
Won't Fix
Undecided
Unassigned

Bug Description

The current HAProxy 1.8.8 supplied with Ubuntu Bionic and Disco contains a bug when using the server-template functionality for generating upstreams in combination with the check-sni setting.

The bug was fixed in upstream 1.8.17: https://git.haproxy.org/?p=haproxy-1.8.git;a=commit;h=5b9c962725e8352189911f2bdac7e3fa14f73846

Could you please take the appropriate action?

Revision history for this message
Robie Basak (racb) wrote :

Upstream 2.0 branch commit: https://git.haproxy.org/?p=haproxy-2.0.git;a=commit;h=21944019cabcb46ceb95b7fd925528b9dace4e35

Looks like this was fixed before the release of the 2.0 series, so this is Fix Released for the development release.

Changed in haproxy (Ubuntu):
status: New → Fix Released
Changed in haproxy (Ubuntu Bionic):
status: New → Triaged
Changed in haproxy (Ubuntu Disco):
status: New → Triaged
Revision history for this message
Robie Basak (racb) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better.

Is there an upstream bug link for this issue please?

If any upstream bug does not provide this information already, please could you provide exact steps to reproduce the problem and an explanation of how it impacts haproxy users? We need this information to be able to decide if it is appropriate to patch the Ubuntu stable releases, and to be able to QA any such fix prior to landing it.

Once done, please change the bug status back to New. Thanks!

Triage notes: probably server-next, but we need SRU information before this can be actionable so it doesn't qualify yet.

Revision history for this message
Malte Schmidt (maltris) wrote :

Set up HAProxy with the attached configuration. The server-template directive will generate 3 upstreams based on the DNS-answers for letsencrypt.status.io. This is basic HAProxy DNS-service-discovery.

If you now check back with the stats socket or the webinterface, you will notice that while the first upstream will be L7OK, all the following upstreams are going to be L6RSP, doe to the fact that the check-sni setting does not get replicated for any of the generated upstreams than the first.

The patch fixes this so the check-sni argument gets applied to all generated upstreams. With a patched version of HAProxy all the 3 upstreams will be L7OK.

Changed in haproxy (Ubuntu Bionic):
status: Triaged → New
Changed in haproxy (Ubuntu Disco):
status: Triaged → New
Revision history for this message
Paride Legovini (paride) wrote :

Hello Malte,

I tried to reproduce the behavior you describe using the haproxy.cfg you provided, but without success. I have some questions that may help us getting in sync with what are observing.

1. Your haproxy.cfg doesn't work in Bionic and Eoan because haproxy complains that the following two lines:

    nameserver dns1 8.8.8.8
    nameserver dns2 8.8.4.4

do not specify an UDP port. Changing them to:

    nameserver dns1 8.8.8.8:53
    nameserver dns2 8.8.4.4:53

make it work, but I don't see how it could have worked for you. Can you confirm you tested the conf file with the haproxy package shipped with Ubuntu?

2. Even with the fix above, with Bionic I still get L6RSP errors in all the three upstreams, while you wrote that the first one should work and be listed as L7OK. The error is: "SSL handshake failure (Bad file descriptor)" for all of them. Can you confirm it the first one should work with your conf file and Bionic's haproxy?

If I change the server-template line to:

  server-template letsencrypt.status.io 3 letsencrypt.status.io:80 check resolvers res_statusio

I get L7OK from all the 3 upstreams. If I do:

  curl --cacert /etc/ssl/certs/ca-certificates.crt https://letsencrypt.status.io:444

I get the expected response, so my networking should be working fine.

3. In your haproxy.conf you set:

  option httpchk GET / HTTP/1.1\r\nHost:\ letsencrypt.status.io
  http-request set-header Host letsencrypt.status.io

It seems you are setting the Host header twice here. I doubt it's related with the check-sni issue, but worth checking and maybe dropping the first one

4. I tried the same configuration on Eoan, where the check-sni patch should be included, however I get SOCKERR errors for all the three upstreams. In the journal I see several errors like:

   OpenSSL error[0x14094410] ssl3_read_bytes: sslv3 alert handshake failure

which I didn't see on Bionic. Is it actually working for you on Eoan?

Please remember to set the report status back to New after providing additional information. Thanks!

Revision history for this message
Paride Legovini (paride) wrote :

FTR: I couldn't find an upstream bug for this.

Changed in haproxy (Ubuntu Bionic):
status: New → Incomplete
Changed in haproxy (Ubuntu Disco):
status: New → Incomplete
Steve Langasek (vorlon)
Changed in haproxy (Ubuntu Disco):
status: Incomplete → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.