Merge pull request #3770 from johanandren/akka-http-10.2.4

docs/src/main/paradox/release-notes/10.2.x.md

@@ -1,5 +1,23 @@
 # 10.2.x Release Notes
 
+## 10.2.4
+
+This release fixes [CVE-2021-23339](https://nvd.nist.gov/vuln/detail/CVE-2021-23339), a vulnerability regarding interpretation of `Transfer-Encoding` headers. See
+@ref:[Incorrect Handling Of Transfer-Encoding Header](../security/2021-02-24-incorrect-handling-of-Transfer-Encoding-header.md).
+
+The vulnerability cannot be exploited using just Akka HTTP itself. Instead, Akka HTTP must be use as a proxy and the downstream server must be vulnerable itself, so
+that the proxy and the downstream server disagree on how to interpret a malformed request containing both `Transfer-Encoding` and `Content-Length` headers potentially
+leading to a "Request Smuggling" vulnerability. If you are using Akka HTTP as a reverse proxy, make sure to upgrade to the latest version.
+
+Starting from this version, only a single `Transfer-Encoding: chunked` header is allowed. HTTP/1.1 specifies other encodings, however, those are not supported or
+implemented in Akka HTTP. Formerly, Akka HTTP would just pass on unsupported `Transfer-Encoding` headers to the user which lead to the above security issue. Since
+Akka HTTP implements the "Transfer" part of the protocol, it seems reasonable to lock down allowed values for `Transfer-Encoding` to prevent security issues like this.
+Please let us know if this leads to compatibility problems with your software.
+
+The release contains one other notable change:
+
+ * New option for handling conflicting Content-Type headers [#3727](https://github.com/akka/akka-http/pull/3727)
+
 ## 10.2.3
 
 This release includes a working preview HTTP/2 client. Please consider using this preview to provide early feedback in case you find issues in your use-case. The HTTP/2 client will soon be included as an opt-in backend for the Akka gRPC client.

docs/src/main/paradox/security.md

@@ -17,6 +17,10 @@ to ensure that a fix can be provided without delay.
 
 ## Fixed Security Vulnerabilities
 
+### Fixed in Akka HTTP 10.2.4 & 10.1.14
+
+* @ref:[Incorrect handling of Transfer-Encoding header](security/2021-02-24-incorrect-handling-of-Transfer-Encoding-header.md)
+
 ### Fixed in Akka HTTP 10.1.5 & 10.0.14
 
 * @ref:[Denial of Service via unlimited decoding with decodeRequest directive ("zip bomb")](security/2018-09-05-denial-of-service-via-decodeRequest.md)
@@ -36,6 +40,7 @@ to ensure that a fix can be provided without delay.
 
 @@@ index
 
+ * [2020](security/2021.md)
  * [2018](security/2018.md)
  * [2017](security/2017.md)
  * [2016](security/2016.md)

docs/src/main/paradox/security/2021-02-24-incorrect-handling-of-Transfer-Encoding-header.md

@@ -0,0 +1,58 @@
+# Incorrect Handling Of Transfer-Encoding Header
+
+## Date
+
+24 February 2021
+
+## Description of Vulnerability
+
+HTTP/1.1 defines rules which `Transfer-Encoding` headers are valid and how they should be interpreted. In particular, a `Transfer-Encoding: chunked` header and a `Content-Length` header
+are not allowed to appear in a single message at the same time. This is important to unambiguously delimit subsequent HTTP messages on a connection.
+
+In theory, HTTP/1.1 allows multiple encodings, although, in practice, only `chunked` is relevant. In the case that multiple encodings are present,
+vulnerable versions of Akka HTTP do not correctly validate the rules of the specification and effectively ignore the `Transfer-Encoding` header, use
+a `Content-Length` header if present for delimiting a message, and pass the message to the user unchanged.
+
+If users used Akka HTTP as a reverse proxy, such a message might be forwarded to a backend server. This can potentially lead to "Request Smuggling" if the backend server has a similar but
+different interpretation for that (invalid) set of headers.
+
+## Severity
+
+Based on our assessment, the CVSS score of this vulnerability is 4.2 (Medium), based on vector [(AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N/E:U/RL:O/RC:C)](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N/E:U/RL:O/RC:C&version=3.1).
+
+## Impact
+
+A vulnerable Akka HTTP server will accept a malformed message as described above and hand it over to the user. If the user application proxies this message to another server unchanged
+and that server also accepts that message but interprets it as two HTTP messages, the second message has reached the second server without having been inspected by the proxy.
+
+Note that Akka HTTP itself does currently not provide functionality to proxy requests to other servers (but it's easy to build).
+
+In summary, these conditions must be true for an application to be vulnerable:
+
+ * use a vulnerable version of Akka HTTP
+ * the application must proxy requests to a backend server
+ * the backend server must have another bug that accepts the message and interprets the malformed message as two messages
+
+## Resolution
+
+Akka HTTP will no longer accept multiple encodings in `Transfer-Encoding` but only a single `chunked` encoding is valid. HTTP message carrying a combination of `Transfer-Encoding` and
+`Content-Length` headers are rejected.
+
+## Affected versions
+
+- akka-http prior to `10.2.4` and  `10.1.14`
+
+## Fixed versions
+
+- akka-http `10.2.4`
+- akka-http `10.1.14`
+
+## Acknowledgements
+
+Thanks, Bastian Ike and Sebastian Rose of AOE for bringing this issue to our attention.
+
+## References
+
+ * [CVE-2021-23339](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-23339)
+ * [SNYK-JAVA-COMTYPESAFEAKKA-1075043](https://snyk.io/vuln/SNYK-JAVA-COMTYPESAFEAKKA-1075043)
+ * [#3754](https://github.com/akka/akka-http/pull/3754)

docs/src/main/paradox/security/2021.md

@@ -0,0 +1,9 @@
+# 2021
+
+@@ toc
+
+@@@ index
+
+* [Incorrect handling of Transfer-Encoding header](2021-02-24-incorrect-handling-of-Transfer-Encoding-header.md)
+
+@@@