- update to 7.4.2 (bsc#1216123, CVE-2023-44487):
  * The ``vcl_req_reset`` feature (controllable through the ``feature``
    parameter, see `varnishd(1)`) has been added and enabled by default
    to terminate client side VCL processing early when the client is
    gone.
    *req_reset* events trigger a VCL failure and are reported to
    `vsl(7)` as ``Timestamp: Reset`` and accounted to ``main.req_reset``
    in `vsc` as visible through ``varnishstat(1)``.
    In particular, this feature is used to reduce resource consumption
    of HTTP/2 "rapid reset" attacks (see below).
    Note that *req_reset* events may lead to client tasks for which no
    VCL is called ever. Presumably, this is thus the first time that
    valid `vcl(7)` client transactions may not contain any ``VCL_call``
    records.
  * Added mitigation options and visibility for HTTP/2 "rapid reset"
    attacks
    Global rate limit controls have been added as parameters, which can
    be overridden per HTTP/2 session from VCL using the new vmod ``h2``:
    * The ``h2_rapid_reset`` parameter and ``h2.rapid_reset()`` function
      define a threshold duration for an ``RST_STREAM`` to be classified
      as "rapid": If an ``RST_STREAM`` frame is parsed sooner than this
      duration after a ``HEADERS`` frame, it is accounted against the
      rate limit described below.
    * The ``h2_rapid_reset_limit`` parameter and
      ``h2.rapid_reset_limit()`` function define how many "rapid" resets
      may be received during the time span defined by the
      ``h2_rapid_reset_period`` parameter / ``h2.rapid_reset_period()``
      function before the HTTP/2 connection is forcibly closed with a
      ``GOAWAY`` and all ongoing VCL client tasks of the connection are
      aborted. (forwarded request 1130176 from dirkmueller)

• Files Changed
• Browse Source