]> git.ipfire.org Git - thirdparty/haproxy.git/commitdiff
MEDIUM: http-ana: Refuse invalid 101-switching-protocols responses
authorChristopher Faulet <cfaulet@haproxy.com>
Fri, 8 Jan 2021 15:02:05 +0000 (16:02 +0100)
committerChristopher Faulet <cfaulet@haproxy.com>
Thu, 28 Jan 2021 15:27:48 +0000 (16:27 +0100)
A 101-switching-protocols response must contain a Connection header with the
Upgrade option. And this response must only be received from a server if the
client explicitly requested a protocol upgrade. Thus, the request must also
contain a Connection header with the Upgrade option. If not, a
502-bad-gateway response is returned to the client. This way, a tunnel is
only established if both sides are agree.

It is closer to what the RFC says, but it remains a bit flexible because
there is no check on the Upgrade header itself. However, that's probably
enough to ensure a tunnel is not established when not requested.

This one is not tagged as a bug. But it may be backported, at least to
2.3. It relies on :

  * MINOR: htx/http-ana: Save info about Upgrade option in the Connection header

src/http_ana.c

index 96753c0ef6da27bedf97ac1546ec7b43d7789dc7..19b5fe5f78b86a9514fddb3c141486d2c2545127 100644 (file)
@@ -1610,6 +1610,15 @@ int http_wait_for_response(struct stream *s, struct channel *rep, int an_bit)
                goto next_one;
        }
 
+       /* A 101-switching-protocols must contains a Connection header with the
+        * "upgrade" option and the request too. It means both are agree to
+        * upgrade. It is not so strict because there is no test on the Upgrade
+        * header content. But it is probably stronger enough for now.
+        */
+       if (txn->status == 101 &&
+           (!(txn->req.flags & HTTP_MSGF_CONN_UPG) || !(txn->rsp.flags & HTTP_MSGF_CONN_UPG)))
+               goto return_bad_res;
+
        /*
         * 2: check for cacheability.
         */