TLS1.2 weak ciphers are accepted by webhook

[ghost]

Is your feature request related to a problem? Currently Webhook's min version is 1.2 which is good but still accepting week ciphers. e.g. TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA , TLS_RSA_WITH_3DES_EDE_CBC_SHA 64-bit block cipher 3DES vulnerable to SWEET32 attack and for production environments this will create vulnerability

Describe the solution you'd like List of accepted ciphers by the webhook to be configurable or more restrictive

[kishorj]

@ahvandf, thanks for reporting the issue, we will disable the weak ciphers.

[oliviassss]

/assign

[dalgibbard]

Just to add to this; testing with https://hub.docker.com/r/drwetter/testssl.sh on AWS LBC version v2.3.0 results in the following issues:

* TLS 1 offered (deprecated)
* TLS 1.1 offered (deprecated)
* Triple DES Ciphers / IDEA offered
* Obsoleted CBC ciphers (AES, ARIA etc.) offered
* Has server cipher order? no (NOT ok)
* Certificate Validity (UTC) 3624 >= 60 days (2022-02-09 11:23 --> 2032-02-07 11:23)
   >= 10 years is way too long
* SWEET32 (CVE-2016-2183, CVE-2016-6329) VULNERABLE, uses 64 bit block ciphers
* BEAST (CVE-2011-3389) TLS1: ECDHE-RSA-AES256-SHA AES256-SHA ECDHE-RSA-AES128-SHA AES128-SHA ECDHE-RSA-DES-CBC3-SHA DES-CBC3-SHA
   VULNERABLE -- but also supports higher protocols TLSv1.1 TLSv1.2 (likely mitigated)
* LUCKY13 (CVE-2013-0169), experimental potentially VULNERABLE, uses cipher block chaining (CBC) ciphers with TLS. Check patches

Admittedly it's possible that the backing SSL package AWS LBC is built against mitigates some of these; but ultimately there's no real need to support CBC/3DES or TLS1/1.1 -- TLS1.2 should be the minimum. Server-side cipher ordering should be enforced. Certificate validity duration is debatable.

[kishorj]

@dalgibbard, TLS 1.2 is the minimum version since v2.3.1 release.

[dalgibbard]

Thanks for the heads up @kishorj ! Will update tomorrow then :)

[kishorj]

Addressed in v2.4.1 patch release. Closing the issue.