Bug #13332: HAProxy Broken after v22.05 and HAProxy v0.61_3 - pfSense Packages - pfSense bugtracker

Actions

Copy link

Bug #13332

closed

HAProxy Broken after v22.05 and HAProxy v0.61_3

Added by Rick Strangman over 2 years ago. Updated over 2 years ago.

Status:

Rejected

Priority:

Normal

Assignee:

Category:

haproxy

Target version:

Start date:

Due date:

% Done:

Estimated time:

Plus Target Version:

Affected Version:

Affected Plus Version:

22.05

Affected Architecture:

All

Description

If you are using HAProxy deprecated rspidel directive on your frontends or the option option httpchk on backends, HAProxy will fail to start after an upgrade to v22.05 and v0.61_3. Deprecated feature usages in HAProxy should stop the upgrade from happening instead of crashing and refusing to load. The 2 options being used in HAProxy were # Remove headers that expose security-sensitive information.
rspidel ^Server:.*$
rspidel ^X-Powered-By:.*$
rspidel ^X-AspNet-Version:.*$
and
option httpchk OPTIONS / HTTP/1.1\r\nHost:\ www.xxx.com
server hostedweb443 192.168.xx.xx:443 id 116 ssl check inter 5000 maxconn 1000 verify none

Actions

Copy link

Updated by Johannes Goldynia over 2 years ago

Hello,
updating the pass-trough rules to

http-response del-header X-AspNet-Version
http-response del-header Server
http-response del-header X-Powered-By

might work for you.

I agree that a hint before the upgrade would have been fine.

Another bug has been found: the generated code by HaProxy-GUI

"rspirep ^(Set-Cookie:((?!;\ secure).)*)$ \1;\ secure if { ssl_fc }"

used by the checkbox /backend settings ... HSTS / Cookie protection is obsolete.
So I fix it - temporary - by disabling the checkbox but adding the following "Backend pass thru":

http-response replace-header Set-Cookie "^((?:(?!; [Ss]ecure\b).)*)\$" "\1; secure" if { ssl_fc }

Still waiting for a fix.
Cheers

Actions

Copy link

Updated by Jim Pingle over 2 years ago

Status changed from New to Rejected

There is no way the package can possibly track and warn about custom configuration directives. By definition it does not know about those or validate them. It's up to the user to maintain them.

Additionally there is no way your existing copy of the package could know what is or isn't supported by a future version that isn't installed yet.

Actions

Copy link